Description: Tracked changes with no date in .doc(x) documents are no longer tracked when saved in ODF format. This is a serious problem for collaborations involving conversions between MS Word documents and ODF files since the tracking information is not passed through the document thread. As this bug is triggered by 0000-00-00 in the tracked-changes date field, one solution would be for LO Writer to replace it with the internal date stamp (File: Properties…). More generally, it would be most helpful if LO Writer would offer the same controls over date and time in tracked changes (and comments) that are offered in MS Word, including no date or time stamps. ("enhancement"). Steps to Reproduce: 1. Open MS Word document (.doc(x)) containing tracked changes with date 0000-00-00. 2. Save to ODF formatted file. 3. Close and re-open the file. Actual Results: The previously tracked changes are no longer tracked. Expected Results: Show the tracked changes as in the original .doc(x) file. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.7.2 Build: c6a4e3954236145e2acb0b65f… Environment: CPU threads: 4; OS: Mac OS X 10.13.6 User Interface: UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Misc: Calc: threaded (Note: this information is found under LibreOffice: About LibreOffice)
Thank you for reporting the bug. It seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
For v. 7.2.4.1, the problem is still present. Specifically, when a DOCX file is imported with 0000:00:00 in the date fields ("null date") of tracked changes, LibreOffice displays them with that date and saves them when exported to an ODF file. However, when the ODF file is then opened by LibreOffice, the null date seems to be ignored: the changes are no longer marked as tracked, and the date field is not retained when the file is saved (again to ODF). HOWEVER, I did see the report in the release notes: "In the Security Options dialog, choosing "Remove personal information on saving" now removes names and dates from comments and tracked changes. core commit 12da70. (László Németh, NISZ)". So upon importing the DOCX file with the null dates for tracked changes, I set the security option to "Remove personal information on saving", and upon saving to ODF format, the date was changed to 1970:01:01 and the changes were then successfully recognized as tracked with that date upon opening the ODF file. This is a step forward, but users cannot be expected to know to change this setting after importing DOCX files with null dates for tracked changes. So LibreOffice needs to *automatically* insert 1970:01:01 into the date fields of tracked changes when importing such DOCX files. Thank you for your help. (PS. I have donated to LibreOffice)
Hello, Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document. (Please note that the attachment will be public, remove any sensitive information before attaching it.) How can I eliminate confidential data from a sample document? https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F Thank you
Created attachment 177293 [details] Lists sample documents with comments Spreadsheet listing sample files that illustrate the bug as described in earlier comments.
Created attachment 177294 [details] Original DOX file containing tracked changes with dates zeroed out.
Created attachment 177295 [details] DOCX tracked changes retained when DOCX saved back to DOCX.
Created attachment 177296 [details] DOCX changes not marked as tracked. No date fields.
Created attachment 177297 [details] DOCX changes not marked as tracked. Date fields not saved to ODT.
I can confirm with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: c13db6e792cc347ffff4585f23866f195651f21f CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2c51746997478ad5d0e7cc64aa6489769c473d43 tdf#146171 DOCX: fix loss of change tracking, if no date 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.
@KevBurto@gmail.com and all: thanks for the bug report and feedback. Commit description: tdf#146171 DOCX: fix loss of change tracking, if no date was specified, or it was specified as zero date (e.g. in a LO DOCX export). DateTime attribute w:date is optional in w:ins/w:del according to the OOXML standard. Not specified w:date was imported as invalid zero date "0-00-00T00:00:00Z" resulting loss of change tracking data completely during an ODF roundtrip. Import this invalid zero date as Epoch time to avoid losing change tracking data.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/902e23d6e95f86a6ffbc642e57e35dcd27a6e83b tdf#146171 DOCX: fix loss of change tracking, if no date It will be available in 7.3.2. 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.
Verified in: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a3988b2d147a2442b348d58b79dbd6e71472b7af 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
Thank you for all your work on fixing this bug. I have tested LO v7.3.2.2 and find that when a .doc(x) file is imported into LO without dates and times for tracked changes, it places 2010/01/01 00:00:00 in the time and date fields and these are saved with the changes when exported to an .odt file. Author names are changed to Author1, -2, etc. However, when the tracked changes are examined in the tracked changes window (Edit/Changes/Manage…), LO locks up. This is true for .doc(x) files and .odt files derived from them. LO also locks up at other irregular times when these files are examined. This problem has existed ever since v7.2.4.1, when the option to "Remove personal information on saving" was introduced (Preferences/Security/Options…), but I had been hoping that it would be fixed along with the bug I reported. Since I used the tracked changes features in LO, including the manage changes window, I am unable to use versions of LO newer than v7.1.8.1.
(In reply to KevBurto from comment #14) > Thank you for all your work on fixing this bug. I have tested LO v7.3.2.2 > and find that when a .doc(x) file is imported into LO without dates and > times for tracked changes, it places 2010/01/01 00:00:00 in the time and > date fields and these are saved with the changes when exported to an .odt > file. Author names are changed to Author1, -2, etc. However, when the > tracked changes are examined in the tracked changes window > (Edit/Changes/Manage…), LO locks up. This is true for .doc(x) files and > .odt files derived from them. LO also locks up at other irregular times > when these files are examined. This problem has existed ever since > v7.2.4.1, when the option to "Remove personal information on saving" was > introduced (Preferences/Security/Options…), but I had been hoping that it > would be fixed along with the bug I reported. Since I used the tracked > changes features in LO, including the manage changes window, I am unable to > use versions of LO newer than v7.1.8.1. @KevBurto: Thanks for your feedback! Unfortunately, I don't understand the problem exactly: visualization of the fake date or crashing? Could you file the remaining problem with a test file to fix that, too, please?
The main problem is that LO becomes unresponsive ("spinning pinwheel of death") and has to be forced to quit. The fake dates and times appear in the manage changes window for imported .docx files, but generally do not for .odt files exported from the .docx files. This behavior occurs with the files that were uploaded previously ("Original DOX file …" and "DOCX changes not marked as tracked" [.docx saved to .odt]). The trigger is to use the manage tracked changes window accessed via the Edit menu.
KevBurto, if you're still experiencing an issue, please open a separate bug report on it.