Bug 53700 - Writer EDITING: add ability to delete or cut text which contains TOC
Summary: Writer EDITING: add ability to delete or cut text which contains TOC
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: 3.6.0.4 release
Hardware: Other All
: medium enhancement
Assignee: Rainer Bielefeld Retired
QA Contact:
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-19 09:56 UTC by fenglich
Modified: 2012-11-23 12:18 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Sample document (19.56 KB, application/vnd.oasis.opendocument.text)
2012-09-27 17:47 UTC, Rainer Bielefeld Retired
Details

Description fenglich 2012-08-19 09:56:49 UTC
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
Comment 1 Rainer Bielefeld Retired 2012-09-27 17:47:48 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.
Comment 2 fenglich 2012-09-30 06:55:50 UTC
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.
Comment 3 pierre-yves samyn 2012-09-30 13:36:44 UTC
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
Comment 4 fenglich 2012-10-01 14:52:41 UTC
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.
Comment 5 sasha.libreoffice 2012-11-23 12:17:17 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.