When you use revision marks (track/record changes) in ODT, Writer does not always correctly save the revision history of the document and, consequently, some insertions made and tracked are accepted instead of rejected when you reject all changes. This happens when 2 or more users edit a document under revision control in separate edit sessions, and one user deletes text inserted by another user. Reproduce: (1) Take an ODT document. Ensure that a valid user name is defined under Tools/Options/User Data. (User 1) (2) Enable "Record changes". Insert 3 or more words of text. (Optionally save to file.) (3) Let another user open the file. Or: change your user name under Tools/Options/User Data. (User 2) (4) Delete the 2nd word inserted in step (2). Open "Accept/reject all changes" dialogue: the edits are displayed in a tree structure reflecting their "nested" character. Close dialogue without doing anything. (5) Save and close the file. Reload it. Open "Accept/reject all changes" dialogue: the edits are displayed in a flat list - information about their "nestedness" is lost. (6) Reject all changes made. The complete insertion in step (2) should be deleted. Instead, the part deleted by user 2 in step (4) is kept in the document plus the text inserted by User 1 following the word deleted by User 2. Interdependentant edits (deletions inside insertions) are correctly kept in LO's internal data structures, but not properly saved to file and lost on reload of the document. By the way: If you reject all changes after step 4, you cannot do it in 1 step as I would expect. You have to press the same button twice. But I'm not sure if there is some logic behind that. Tested with LO 3.5.4.2 and 3.6.2.2 (Ubuntu 12.04).
Created attachment 68891 [details] document with revision marks by user 1 (steps 1/2) ODT with some text by User 1. Go on with step 3 and delete some of the inserted text.
(In reply to comment #0) > (6) Reject all changes made. The complete insertion in step (2) should be > deleted. Instead, the part deleted by user 2 in step (4) is kept in the > document plus the text inserted by User 1 following the word deleted by User > 2. Confirmed with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit > Interdependentant edits (deletions inside insertions) are correctly kept in > LO's internal data structures, but not properly saved to file and lost on > reload of the document. Could not reproduce. Added 1 2 3 as user 1, saved document, opened and deleted 2 as user 2, saved document, opened as user 1 and deletion by user 2 is visible.
Setting status to NEW after confirmation in comment 2. (In reply to comment #2) > > Interdependentant edits (deletions inside insertions) are correctly kept in > > LO's internal data structures, but not properly saved to file and lost on > > reload of the document. > > Could not reproduce. Added 1 2 3 as user 1, saved document, opened and > deleted 2 as user 2, saved document, opened as user 1 and deletion by user 2 > is visible. This is not a separate issue but rather the explanation why "reject all changes" does not work properly. Saving a file to ODT "flattens" the multi-level structure of tracked changes. While LO has the doc still in memory, it records 2 levels of changes: | change 1: inserted text (1 word) | change 2: inserted text (user 1) + deleted text (user 2) (1 word) | change 3: inserted text (1 word) When LO saves the file to ODT, the 2 edits are flattened to 3 simple changes: | change 1: inserted text (user 1) | change 2: deleted text (user 2) | change 3: inserted text (user 3) The 2nd word is treated as if it already had been in the document before track changes was enabled. It is correctly marked as deletion by user 2, but no longer as an insertion by user 1. Note that exporting the file to DOC preserves the 2-level nature of the changes.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-16
Reproduced using attachment 68891 [details]. Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+ Build ID: 8c3cf9dd48e40604867d3a28bddaccd65142df17 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-27_15:15:18 Locale: fi_FI
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Dear stfhell, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear stfhell, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still happens in Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 91330c503b7eb91d777978018b66890af87cf8f5 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL
Hi Timur, why was it set to High/Highest ?
Repro 7.4+. This is dataLoss or it's opposite in step (6).
It seems, this is a regression from commit a9019e76812a947eb54cfa8d728c19361c929458 "INTEGRATION: CWS oasis (1.3.276); FILE MERGED 2004/05/12 11:00:37 mib 1.3.276.1: - #i20153#: changed <office:annotation> and <office:change-info>"
Commit description: tdf#56266 sw xmloff: fix tracked deletions in insertions RedlineSuccessorData export, i.e. tracked deletions within tracked insertions were loaded as plain tracked deletions during an ODF roundtrip. After that, e.g. rejecting all changes couldn't reject the lost tracked insertion, keeping the text of the tracked deletion as part of the original text by mistake. Regression from commit a9019e76812a947eb54cfa8d728c19361c929458 "INTEGRATION: CWS oasis (1.3.276); FILE MERGED 2004/05/12 11:00:37 mib 1.3.276.1: - #i20153#: changed <office:annotation> and <office:change-info>" Note: RedlineSuccessorData is still stored in an extra text:insertion within text:changed-region, only the not ODF-compatible office:chg-author and office:chg-date-time attributes were changed to dc:creator and dc:date elements in RedlineSuccessorData export: <text:changed-region> <text:deletion/> <text:insertion/> </text:changed-region> Because this structure still causes a bootstrap ODF validation error in the odfexport and layout tests, check the export with uitest. See also SetChangeInfo()/RedlineAdd().
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2682828f73a6c759735613ec924357424baeae24 tdf#56266 sw xmloff: fix tracked deletions in insertions It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The problem is fixed. But the "Reject All" is not working the same in the bellow two option: 1. Edit -> Track Changes -> Reject All 2. Edit -> Track Changes -> Manage... -> Reject All The first one is reject all the changes independently which user changed the document. The second one deletes only the last changes so if one user create something (change the document) and other user changes that only the last change will be rejected.
Verified in: Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: dfd5081ff3973d5d0f216b06dda6360fa490cc9c CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded