Bug 146171 - Tracked changes with no date (0000-00-00) in .doc(x) documents are no longer tracked when converted to ODF format.
Summary: Tracked changes with no date (0000-00-00) in .doc(x) documents are no longer ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0 target:7.3.2
Keywords:
Depends on:
Blocks: Track-Changes MSO-Formats 147760
  Show dependency treegraph
 
Reported: 2021-12-10 19:01 UTC by KevBurto
Modified: 2022-04-13 01:21 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Lists sample documents with comments (22.89 KB, application/pdf)
2022-01-03 20:35 UTC, KevBurto
Details
Original DOX file containing tracked changes with dates zeroed out. (11.44 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-01-03 20:37 UTC, KevBurto
Details
DOCX tracked changes retained when DOCX saved back to DOCX. (233.38 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-01-03 20:39 UTC, KevBurto
Details
DOCX changes not marked as tracked. No date fields. (12.65 KB, application/vnd.oasis.opendocument.text)
2022-01-03 20:40 UTC, KevBurto
Details
DOCX changes not marked as tracked. Date fields not saved to ODT. (13.25 KB, application/vnd.oasis.opendocument.text)
2022-01-03 20:42 UTC, KevBurto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description KevBurto 2021-12-10 19:01:20 UTC
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)
Comment 1 Dieter 2021-12-25 13:26:45 UTC
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.
Comment 2 KevBurto 2021-12-25 18:56:21 UTC
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)
Comment 3 zcrhonek 2021-12-31 11:06:16 UTC
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
Comment 4 KevBurto 2022-01-03 20:35:10 UTC
Created attachment 177293 [details]
Lists sample documents with comments

Spreadsheet listing sample files that illustrate the bug as described in earlier comments.
Comment 5 KevBurto 2022-01-03 20:37:18 UTC
Created attachment 177294 [details]
Original DOX file containing tracked changes with dates zeroed out.
Comment 6 KevBurto 2022-01-03 20:39:05 UTC
Created attachment 177295 [details]
DOCX tracked changes retained when DOCX saved back to DOCX.
Comment 7 KevBurto 2022-01-03 20:40:18 UTC
Created attachment 177296 [details]
DOCX changes not marked as tracked.  No date fields.
Comment 8 KevBurto 2022-01-03 20:42:37 UTC
Created attachment 177297 [details]
DOCX changes not marked as tracked. Date fields not saved to ODT.
Comment 9 raal 2022-01-04 20:08:08 UTC
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
Comment 10 Commit Notification 2022-03-02 20:21:23 UTC
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.
Comment 11 László Németh 2022-03-02 20:24:09 UTC
@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.
Comment 12 Commit Notification 2022-03-03 16:19:06 UTC
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.
Comment 13 NISZ LibreOffice Team 2022-03-31 06:45:07 UTC
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
Comment 14 KevBurto 2022-04-10 01:10:18 UTC
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.
Comment 15 László Németh 2022-04-10 09:39:35 UTC
(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?
Comment 16 KevBurto 2022-04-10 19:08:40 UTC
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.
Comment 17 Aron Budea 2022-04-13 01:21:14 UTC
KevBurto, if you're still experiencing an issue, please open a separate bug report on it.