Bug 132475 - FILEOPEN DOCX: Dynamic field (last modified) reverts to static text
Summary: FILEOPEN DOCX: Dynamic field (last modified) reverts to static text
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Justin L
URL:
Whiteboard: target:7.4.0
Keywords: filter:docx
Depends on: 148380
Blocks: DOCX-Fields
  Show dependency treegraph
 
Reported: 2020-04-27 19:41 UTC by Paul Villani
Modified: 2022-05-13 13:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
file exhibiting reported problem (5.48 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-04-27 19:50 UTC, Paul Villani
Details
test doc in .docx format (6.53 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-11-03 20:18 UTC, Paul Villani
Details
test doc in .odt format (17.64 KB, application/vnd.oasis.opendocument.text)
2020-11-03 20:22 UTC, Paul Villani
Details
Example file from Word with similarly functioning field (11.49 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-12-02 10:26 UTC, NISZ LibreOffice Team
Details
The example file with SaveDate field in Word 2013 and current Writer 7.2master (115.78 KB, image/png)
2020-12-02 10:27 UTC, NISZ LibreOffice Team
Details
132475_lastPrinted.docx: tricky SAVEDATE and print field (9.18 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-04-08 07:29 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Villani 2020-04-27 19:41:17 UTC
Description:
The document information fields 'Modified' and 'Last Printed' get converted to static text when the document is saved in .docx format. Maintaining it in .odt retains the fields' dynamic feature.

Steps to Reproduce:
1. In a new or existing document, add 'Modified' and/or 'Last Printed' fields via Fields>More Fields>DocInformation pallet.
2. Save and close the document with the filetype .docx
3. Re-open the file. 

Actual Results:
Fields are static text of whatever their content was.

Expected Results:
Fields remain dynamic.


Reproducible: Always


User Profile Reset: No



Additional Info:
Sample document attached.
Comment 1 Paul Villani 2020-04-27 19:50:23 UTC
Created attachment 160010 [details]
file exhibiting reported problem
Comment 2 Durgapriyanka 2020-04-28 00:43:04 UTC
Thank you for reporting the bug. I can reproduce the bug in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4


But, not in 
Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 3 Dieter 2020-05-02 15:01:04 UTC Comment hidden (obsolete)
Comment 4 Paul Villani 2020-05-04 18:47:30 UTC Comment hidden (no-value)
Comment 5 QA Administrators 2020-05-05 03:44:55 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2020-11-02 04:36:29 UTC Comment hidden (obsolete, osolete)
Comment 7 Paul Villani 2020-11-03 20:18:19 UTC
Created attachment 166981 [details]
test doc in .docx format

.docx version of test document
Comment 8 Paul Villani 2020-11-03 20:22:22 UTC
Created attachment 166982 [details]
test doc in .odt format

test doc in .odt format.

Hi QA Folks,

Problem seems to persist in v. 7.0.0.2

See contents of either attachments for env descr, steps to reproduce.

Thanks muchly!
PDV
Comment 9 Dieter 2020-11-03 20:32:39 UTC
I confirm it with

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

Steps to reproduce (from attachment)
1.  Add dynamic fields to document footer: Insert > Field > More Fields > [DocInformation Tab]
2. Select Type: Modified	Select: Time or Date	Format: any
3. Click Insert
4. Result: field is inserted.
5. Save document in .odt format and close. Result: doc is saved and closed.

6. Reopen .odt document (you can use attachment) to confirm dynamic fields still in place
7. Save document as MS Word .docx and close.    
8. Reopen .docx document and check doc info fields in footer.
9. Result: fields for doc modification date and time are now static text, and no longer updated with successive saves. (See companion document.)

Additional information: Problem is not footer related.
Comment 10 NISZ LibreOffice Team 2020-12-02 10:26:23 UTC
Created attachment 167748 [details]
Example file from Word with similarly functioning field

Word does not have a DocProperty field with similar date and time format customizability: there is LastSavedTime but that generates a fixed YYYY. MMM DD. HH:MM formatted field (at least in Hungarian; this is probably language dependent too).
However, the normal field named SaveDate offers wide range of date and time formats to format the save time of the file. Maybe this could be used to map the DocInformation - Modified field when exporting to docx.
Comment 11 NISZ LibreOffice Team 2020-12-02 10:27:45 UTC
Created attachment 167749 [details]
The example file with SaveDate field in Word 2013 and current Writer 7.2master

Unfortunately importing of this field does not work yet either in:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 4e63ec27b69fa01ff610c894c9fbf05c377a6179
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL
Comment 12 Justin L 2022-03-14 06:34:29 UTC
repro 7.4+
Comment 13 Justin L 2022-03-15 17:38:41 UTC
Actually, it looks like FILESAVE is working. In Word 2010, I see these as fields, already as far back as a DOCX saved from LO 3.5.
So then it becomes a FILEOPEN problem, inherited from OOo.
Comment 14 Justin L 2022-03-17 09:22:50 UTC
In terms of the last printed date: I checked back to LO 6.0 and that one is not just static text. Yes, you could modify the text, but it was still a field (or at least a control of some kind). However, it doesn't show the field name when I toggle on View - Field Names, and doesn't seem to be tied to last-printed date when loaded as a DOCX.

It became an uneditable something likely with LO 7.0's
commit 27b6c82b79f4af2ab16d53de3b2065df0acebdb8
Author: Michael Stahl on Wed Dec 18 18:08:23 2019 +0100
    tdf#129247 writerfilter,sw: improve handling of CONTROL fields


It looks like we can fix the lost connection to the field with
+     {"PRINTDATE",       {"DocInfo.PrintDateTime",   FIELD_TIME          }},
Comment 15 sdc.blanco 2022-03-17 09:56:22 UTC Comment hidden (off-topic)
Comment 16 Justin L 2022-03-17 10:04:50 UTC Comment hidden (off-topic)
Comment 17 sdc.blanco 2022-03-17 11:52:28 UTC Comment hidden (off-topic)
Comment 18 Justin L 2022-04-08 06:58:47 UTC
The big problem here is that in theory, MS Word can show something completely different in the field than what is contained in the variable (if the user modified it by hand, or if the document was printed/saved again). In MS Word, fields are generally only updated manually via F9, but in LO it always reflects the underlying variable immediately.

So, if we "fix" the loss of the field, we will "break" having consistent text between the two.

(Hmmm, it seems that for SAVEDATE, MS Word does update the field at FILEOPEN, and Print is updated at print time [even though save is not updated at save time].)

So this means that ChangeDate should be able to be locked/FIELDFLD since it always updates on FILEOPEN. (Of course, that means that LO users can't manually update while the document is open, but that seems to be a trivial concern in comparison.)

PrintDate is a bit more challenging because it could be hand-modified to something else (which will stick around until it is printed again), but that seems like a bit of a stretch, and so this could relatively safely be imported as a non-locked field.
Comment 19 Justin L 2022-04-08 07:29:21 UTC
Created attachment 179402 [details]
132475_lastPrinted.docx: tricky SAVEDATE and print field

SAVEDATE has no formatting parameters. Should be "08/04/2022 09:10:00"
PRINTDATE has no formatting parameters, and was also hand-modified. Should be "8 o'clock-ish" until re-printed.
Comment 20 Justin L 2022-04-11 13:17:14 UTC
(In reply to Justin L from comment #18)
> So this means that ChangeDate should be able to be locked/FIXEDFLD since it
> always updates on FILEOPEN.
Actually, just the opposite is true. Since it is updated on FILEOPEN, it must remain unlocked (i.e. not dependent on the as-last-seen plain text).

If the format is unspecified (as in comment 9's example), it is supposed to be left up to the application to display it however the app wants to. But of course end users would tend to disagree with that, and call it a regression if it doesn't match THEIR app's output.


Also worth noting is that LASTCHANGEDBY (the author who last saved) is NOT updated - either at save time, or at FILEOPEN. So that one CAN be locked.
Comment 21 Commit Notification 2022-04-22 11:33:48 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/58cd67e096ca14123a85f8542c728b07645df705

tdf#132475 writerfilter: connect PRINTDATE with DocInfo.PrintDateTime

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 22 Commit Notification 2022-04-25 16:58:19 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/115599cc3478e37879cd2fa0b6c6c9dabde7dfd1

tdf#132475 writerfilter: use proper date-field defaults

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 23 Commit Notification 2022-04-26 06:34:17 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4529690cf65f621554f3c829c04b579bd11989c9

tdf#132475 sw ms: import/export DI_CHANGE as field

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 24 Justin L 2022-04-28 05:21:56 UTC
Note that the fixes here depend on some work done for bug 148380.

(In reply to Justin L from comment #19)
> PRINTDATE has no formatting parameters, and was also hand-modified. Should
> be "8 o'clock-ish" until re-printed.
I decided this was too much of an edge case to be considered. PRINTDATE will match the variable and ignore the as-last-seen text.
Comment 25 Dieter 2022-05-13 13:05:24 UTC
VERIFIED with

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 83d0f2eebae41d431d9a5bfd1a918523977752d0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Justin, thanks for fixing it!