Problem description: Cut text is disabled when a TOC is selected. Sometimes you want to cut all text, and I don't see why you shouldn't be able to. Even when looking at a TOC isolated, one should be able to cut it, perhaps one is moving it. Sometimes cut & paste is also used as a way to try out things, which is in a reversible manner. Steps to reproduce: 1. Create a paragraph 2. Create a toc 3. Select all. 4. Cut Text is disabled. Current behavior: Expected behavior: Platform (if different from the browser): Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.79 Safari/537.1
Created attachment 67798 [details] Sample document @Reporter: I am not sure whether I understood the problem. Steps to reproduce: 1. open Sample document 2. Menu 'Edit -> Select All' > All document will be selected 3. Menu 'Edit -> Cut' > Not Possible, greyed out, so close menu 4. <Del> key Not possible, message "Readonly content cannot be changed. No modifications will be accepted This is expected, because in TOC -> Rightclick -> Context menu -> Edit Index -> Index/Table' "Protect against manual Changes" is checked. Unchecking that will enable deletion in stps 3 or 4.
But it's not changes, it is removal. There's a difference between modification and removal. And I neither think it's of interest to mix those two. Just because you want to be able to cut or remove a TOC, doesn't mean you want to modify it. I think it would be sensible to allow removal and cutting (as long as it isn't part of the TOC, since that would imply modification) even if the "Protect against manual Changes" is checked, since it's not changes.
Hello This is not specific to tables of contents. This is the expected behavior for all protected sections (index or sections inserted by the user) It is not a bug to me: as Rainer reminds, functionality exists to unprotect an index and a "user" section . Set indexes unprotected by default could be an enhancement request. However, I would not support it because indexes are generated, based on the content. Regards Pierre-Yves
I think it's quite obviously a bug. 1. Removing the TOC is not changing iy. Agreed? 2. "Protect against manual Changes" says "changes". Agreed? 1. and 2. doesn't combine. I think the TOC and other fields shouldn't be modifiable by default, but removing or cutting them (if done in whole) should be allowed. That would be natural, and doesn't go against the idea that data generated from user data shouldn't be changed.
reproduced in 3.6.3 on RFR 17 64 bit If I select TOC with surrounding text, it becomes impossible to delete. It is correct behaviour, but may be unhandy. Another observation: Calligra Wrods and msWrod 2007 deletes TOC with surrounding text without problem (used first attachment). IMHO this bugreport is Request for enhacement
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
It is not clear what is exactly expected, but this looks like a duplicate of a solution to make error specific, so that we know why we get it. *** This bug has been marked as a duplicate of bug 62879 ***