Bug 49361 - "Record changes" fails to record changes of and in draw elements
Summary: "Record changes" fails to record changes of and in draw elements
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.2 release
Hardware: Other All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 121801 125707 143040 143041 (view as bug list)
Depends on:
Blocks: Track-Changes-Shape 143042
  Show dependency tree / graph
 
Reported: 2012-05-01 20:55 UTC by Matthew Francis
Modified: 2023-08-17 03:17 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Attachments
Test file exhibiting "track changes" bug (37.25 KB, application/vnd.oasis.opendocument.text)
2012-05-01 20:55 UTC, Matthew Francis 		Details
Tracking_draw_elements.odt : track insertion of draw elements (12.95 KB, application/vnd.oasis.opendocument.text)
2012-09-13 10:44 UTC, stfhell 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2012-05-01 20:55:53 UTC 
Created attachment 60876 [details]
Test file exhibiting "track changes" bug

The attached ODT has some kind of table (drawing?) included in it (the file from which this example was extracted was originally a Word document of some time. I'm not sure how this could be created directly through Writer)

With tracked changes enabled, changes outside the "table"(?) are recorded, but text changes inside the table are not.

Possibly related issues:
- Navigator doesn't show any objects of any sort in the document (no frames, graphics, OLE objects...)
- Text inserted into the "table" cannot be searched for
Comment 1 Joel Madero 2012-09-11 20:37:11 UTC 
Confirmed, setting as NEW and prioritizing.

Minor - makes it harder but not impossible to make high quality work and/or makes user avoid using some features

Low - won't affect many users, only those who create a table in this manner and then wish to track changes.

Confirmed along with this that you cannot search for words in table. If a developer who is working on this thinks that this should be a separate bug, please let myself or Matthew know

@Matthew - thanks for the easy to understand bug with the attachment, we appreciate when things are so clear.
Comment 2 stfhell 2012-09-12 17:20:43 UTC 
I have always regarded that as a kind of built-in limitation rather than a bug. The element of the sample document is not a Writer text element (like tables or frames) but a draw element containing text (actually 2 grouped draw elements). However, at the moment not even inserting the draw element into the text itself is tracked as a change. The same goes for inserting pictures.

From a user's point of view this certainly looks like a bug even if there might be technical reasons behind it, making the issue rather an enhancement than a bug. It's not really consistant behaviour in LO: why should the "track changes" function not track insertion, deletion and even modification of drawings and pictures, when "undo" can handle them?
Comment 3 Joel Madero 2012-09-12 17:27:07 UTC 
Interesting point, I agree that this could easily go under enhancement. I'm torn between it being a bug (because it's not consistent behavior with other aspects of LO such as undo) and enhancement (because LibO is performing as designed, but this clearly would make it better).

I think for now we should leave it as a minor bug but feel free to change it if you're inclined to do so
Comment 4 stfhell 2012-09-13 10:44:03 UTC 
Created attachment 67095 [details]
Tracking_draw_elements.odt : track insertion of draw elements
Comment 5 stfhell 2012-09-13 10:46:19 UTC 
I think you are right in seeing it as a bug. The OpenDocument format specification allows track changes in all <text:p> elements, so both insertion and deletion of a <draw:*> element in a text paragraph can be tracked in the file (changes of attributes cannot, however), but text changes within a <text:p> element of any <draw:*> element can be tracked as well.

The reason why this does not happen must lie with how LO handles draw elements internally. But there is no good reason not to expect LO to record such changes. After all, adding or deleting images or changes text in squares and balloons are changes of the document. A user would expect such changes to be recorded.

I have noticed that inserting draw elements is indeed tracked by LO 3.4.4 if the draw element is anchored as a character.

Reproduce with the attached document Tracking_draw_elements.odt or any other ODT:

- Go to a passage with no tracked changes. Enable "track changes" and insert a rectangle. -> The insertion of the rectangle is not tracked.

- Enable "track changes", write some normal text and insert a rectangle which is anchored as a character. -> The insertion of the rectangle is tracked.

This behaviour cannot really be intentional, it makes no sense and probably isn't even a minor bug because you can't rely on LO tracking, showing and (in case of change rejection) undoing all changes to a document.

I have changed the bug summary to make it more precise.
Comment 6 QA Administrators 2015-01-05 17:51:14 UTC Comment hidden (obsolete)
Comment 7 Matthew Francis 2015-01-29 08:47:27 UTC 
Still occurs on OSX 10.10 / LO 4.4.0.2
Comment 8 QA Administrators 2016-02-21 08:34:56 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2017-03-06 15:05:22 UTC Comment hidden (obsolete)
Comment 10 Gabor Kelemen (allotropia) 2019-05-29 13:39:00 UTC 
*** Bug 121801 has been marked as a duplicate of this bug. ***
Comment 11 NISZ LibreOffice Team 2020-04-27 17:33:24 UTC 
*** Bug 125707 has been marked as a duplicate of this bug. ***
Comment 12 Heiko Tietze 2021-07-20 15:45:56 UTC 
*** Bug 143043 has been marked as a duplicate of this bug. ***
Comment 13 Aron Budea 2021-08-15 01:49:43 UTC 
*** Bug 143040 has been marked as a duplicate of this bug. ***
Comment 14 Aron Budea 2021-08-15 01:50:31 UTC 
*** Bug 143041 has been marked as a duplicate of this bug. ***
Comment 15 QA Administrators 2023-08-17 03:17:26 UTC 
Dear Matthew Francis,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug