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.
Created attachment 160010 [details] file exhibiting reported problem
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
Paul, 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.
Hello, Dieter. Thanks for the follow up. You're correct that I'm not running the latest version. I'm running what seems to be the latest version of LibreOffice from the Canonical archive (under Ubuntu 18.04.03). I am reluctant to update LibreOffice at the moment for a couple of reasons. One, I came across this reported issue, https://www.linuxquestions.org/questions/linux-newbie-8/libreoffice-update-1-6-4-2-oubuntu0-18-04-3-problem-4175672240/ from about a month ago. It does not seem to be resolved. Two, I do have a workaround--maintain the files in .odt format--and that satisfies my needs for now. Three, I'm rather new to Linux and quite busy at the moment, so I'd rather not chase the rabbit down that hole at the moment. I can come back to it in a couple of weeks, but not at the moment. Apologies.
[Automated Action] NeedInfo-To-Unconfirmed
Dear Paul Villani, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Created attachment 166981 [details] test doc in .docx format .docx version of test document
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
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.
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.
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
repro 7.4+
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.
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 }},
I encounter the converse problem (i.e., saving an .odt file with a "fixed" date as .docx results in the date (field) being dynamically updated, even though shown as "fixed" (using 'Edit Field'). Found this ticket, when checking if it was already reported. Should I make a new ticket or does this case seem related?
(In reply to sdc.blanco from comment #15) > I encounter the converse problem (i.e., saving an .odt file with a "fixed" > date as .docx results in the date (field) being dynamically updated, even > though shown as "fixed" (using 'Edit Field'). Found this ticket, when > checking if it was already reported. Should I make a new ticket or does > this case seem related? It should be a separate ticket. This ticket is talking specifically about "properties of the document" variables, while it sounds like you are just inserting a general date field (that is only tied to the current time/insert time/load time? In any case, it will need to be handled with different code, so it might as well be a separate bug report.
(In reply to Justin L from comment #16) > It should be a separate ticket. Thanks. Bug 148052
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.
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.
(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.
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.
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.
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.
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.
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!