Summary: | Writer EDITING: add ability to delete or cut text which contains TOC | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | fenglich |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | CC: | sasha.libreoffice, xiscofauli |
Priority: | medium | ||
Version: | 3.6.0.4 release | ||
Hardware: | Other | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=62879 | ||
Whiteboard: | BSA | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 89606, 108018 | ||
Attachments: | Sample document |
Description
fenglich
2012-08-19 09:56:49 UTC
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 |