Bug 84973 - "Date (fix)" fields must not update on copy
Summary: "Date (fix)" fields must not update on copy
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
Depends on:
Blocks: Fields
  Show dependency tree / graph
 
Reported: 2014-10-14 04:36 UTC by Bugcruncher
Modified: 2023-03-03 07:17 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Attachments
Sample Document (9.27 KB, application/vnd.oasis.opendocument.text)
2014-10-14 04:36 UTC, Bugcruncher 		Details
Screenshot showing strange Date Field Result (95.31 KB, image/png)
2023-03-02 15:42 UTC, Rainer Bielefeld Retired 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Bugcruncher 2014-10-14 04:36:13 UTC 
Created attachment 107799 [details]
Sample Document

Steps how to reproduce with
Version: 4.4.0.0.alpha0+
Build ID: 0b3b907e96a8bbc477b8755a5bcffc350c53ce2b
TinderBox: Win-x86@39, Branch:master, Time: 2014-09-16_05:01:30

1. open attached sample document with an installed LibreOffice of AOO version
2. Launch LibO  4.4.0.0.alpha0+
3. From LibO  4.4.0.0.alpha0+ browse for sample document and try to open
   by double click
   » Warning " ... is locked for editing by: ..." shown
4. [Open Copy]
   » "Untitled 1.odt" will be opened
   Expected: Date field shows 2014-10-13
   Actual: Date field shows current date.

This was ok until OOo 3.3.0 and is broken since very early AOO and LibO Versions
Comment 1 tommy27 2014-10-16 02:37:13 UTC 
reproducible under Win7x64 using 4.4.0.0.alpha0+
Build ID: 2d6dacc1c93bfd4a9086f8fde6b0edbfdeb573c9
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-13_23:44:09

status NEW
Comment 2 tommy27 2016-04-16 07:26:02 UTC Comment hidden (obsolete)
Comment 3 Aron Budea 2016-07-21 02:06:28 UTC 
Still reproducible in 5.1.4.2.

In 5.2 there's no Open Copy anymore, only Open that ignores file locking (apart from the usual Open Read-Only and Cancel).
Comment 4 QA Administrators 2018-07-05 02:49:02 UTC Comment hidden (obsolete)
Comment 5 Michael Stahl (allotropia) 2018-08-29 14:41:14 UTC 
in current master, the bug does not reproduce; Open loads the document but does not update the fixed fields.
Comment 6 Aron Budea 2018-09-24 04:25:47 UTC 
Still occurs for me in a recent 6.2 master build (4f45687426af9b6d18b590816eb902bb364a521b). Note that the test document has to be opened for writing in another Writer instance, and when the tested Writer shows Document in Use dialog, Open Copy need to be chosen.

This indeed worked with 3.3.0, but not with 3.5.0, perhaps could be worth a check with bibisect-43all oldest (unless it's really Win-only, but so far there's no indication it wouldn't occur on Linux).
Comment 7 Aron Budea 2018-09-24 22:57:11 UTC 
In Linux locking works differently, and the same steps can't be followed (there's no option to open a copy).
Comment 8 QA Administrators 2019-09-25 03:01:07 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2021-09-25 03:39:59 UTC Comment hidden (obsolete, spam)
Comment 10 Mike Kaganski 2022-05-05 06:22:02 UTC 
When you open as copy, the original document with fixed fields is used as a *template* for the new copy; and it's normal and expected that *for templates*, the fixed fields are updated (that is one of the reasons to use the fixed fields instead of inserting plain text).

IMO -> NOTABUG
Comment 11 Michael Stahl (allotropia) 2022-05-05 08:49:03 UTC 
> When you open as copy, the original document with fixed fields is used as a *template* for the new copy

not sure i agree with this ... is this really what users want? probably a question for UX.
Comment 12 Mike Kaganski 2022-05-05 09:02:46 UTC 
(In reply to Michael Stahl (allotropia) from comment #11)
> not sure i agree with this ... is this really what users want? probably a
> question for UX.

Then please consider the possibilities:
1. I want to continue working on the document as a next "version" of the original document (I want to use LibreOffice ~similar to "copy file" feature of a file manager);
2. I want to use the original file as a template (create a new file based on the old file).

Of course, both are possible; and I agree that users might expect more of #1. Just the differences wrt this feature should be clear to avoid surprises in the opposite direction.
Comment 13 Heiko Tietze 2022-05-12 12:50:47 UTC 
"Fix" fields are expected to show the same value on templates as well. At least the help does not state otherwise: "Inserts the current date into your slide as a fixed field. The date is not automatically updated." https://help.libreoffice.org/7.3/en-US/text/simpress/01/04990100.html
Comment 14 Heiko Tietze 2022-06-30 12:47:11 UTC 
The topic was on the agenda of the design meeting but didn't receive further input.

My take: "fixed" is expected to be fix also after copy. In case of a template I could imagine for example date of creation that should be constant. 

We should change the behavior.
Comment 15 Mike Kaganski 2022-06-30 15:29:12 UTC 
(In reply to Heiko Tietze from comment #14)
> In case of a template I could imagine for example date of creation that
> should be constant.

Could you please explain this specific bit? Do you tell that behavior of templates should also change (no-go)? The quoted sentence, and the last "We should change the behavior" that doesn't clarify if it applies to one or both aspects mentioned in your first paragraph (copy and template), are confusing.
Comment 16 Heiko Tietze 2022-07-01 07:04:24 UTC 
(In reply to Mike Kaganski from comment #15)
> Could you please explain this specific bit?

I'm referring to this comment.

(In reply to Mike Kaganski from comment #10)
> When you open as copy, the original document with fixed fields is used as a
> *template* for the new copy; and it's normal and expected that *for
> templates*, the fixed fields are updated (that is one of the reasons to use
> the fixed fields instead of inserting plain text).

The point of "Date (Fix)" is to have a non-volatile value. While the ticket is about Open Copy it consequently applies to templates as well. At least I don't see any other way.

If you have strong arguments to keep the behavior we should consider a different name for the variable. Something like "Date (at time of creation)". Sounds terrible, though.
Comment 17 Mike Kaganski 2022-07-01 07:28:17 UTC 
(In reply to Heiko Tietze from comment #16)
> If you have strong arguments to keep the behavior we should consider a
> different name for the variable. Something like "Date (at time of
> creation)". Sounds terrible, though.

The fixed date *field* is created *specifically* to be set at the moment when the document was created from a template. It makes *very* little sense to use it otherwise - you can instead just type a fixed date string, like what happens in Calc when you use Insert->Date. The whole point of the field is that. So if you want to change it for "Open Copy", that *by no means* can change this behavior of *templates*. You actually introduce a third way of opening a document - not from its file, nor using a template, but using another document "almost as template, but not exactly for the sake of fixed fields".
Comment 18 Mike Kaganski 2022-09-05 09:24:25 UTC 
Since 2014, when this was filed, there was no duplicates for this; the CC list only has developers, QA and triagers; so I would assume that this is unlikely to have much user demand.

I haven't actually looked how exactly the "open as copy" is implemented; but as shown in bug 150751, at least opening a document using '-n' command-line argument has a use case to *update* the fixed fields, which is what users might rightfully want.

(Just for some additional context)
Comment 19 Mike Kaganski 2022-09-05 09:56:23 UTC 
OTOH, I can see why "open copy" UI string may look inconsistent with use of the read-only document as a template for a new one. Maybe the issue could be resolved just by a rename: "open copy" -> "use as a template for a new document", or "create new based on this as a template" ... or some nicer string that would convey the "use as template" message.

The functionality to create a copy is always available when you open read-only: just save to another name. So having this "open copy" is actually redundant, unless you truly use it as a template.
Comment 20 Rainer Bielefeld Retired 2023-03-02 15:42:01 UTC 
Created attachment 185703 [details]
Screenshot showing strange Date Field Result

It seems that that problem vanished with LibO 7.5. Or has become replaced with other problems ...

👌 When I open the document with LibO 4 and check the date field, it will be 
   shown as "Date (fix)"
👌 Same with Version: 6.0.7.3 (x64)
👌 Same with Version: 7.0.0.1 (x64)
😥 But Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
  Build ID: 2a7fcaf582df3ada57ca519b50e29011973a1b6f
  CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; 
  VCL: win Locale: de-DE (de_DE); UI: en-US, Calc: threaded 
  shows "Date" instead or "Date (fixed) ?!?

The check result still is the same with 7.6.0.0 alpha+
Comment 21 Rainer Bielefeld Retired 2023-03-03 05:45:31 UTC 
(In reply to Rainer Bielefeld Retired from comment #20)
But Version: 7.5.0.0.alpha0+  ...

This probably is "Bug 152871 - Editing Date/Time fields have an inverted fixed/variable order", has nothing to do with Bug 84973

So I thin we can close this one.
Comment 22 Heiko Tietze 2023-03-03 07:17:48 UTC 
(In reply to Rainer Bielefeld Retired from comment #21)
> This probably is "Bug 152871 - Editing Date/Time fields...

My first patch failed and resulted in this bug asking to be reverted. However, with a little help the default of Date var/fix was inverted finally for bug 139141.

This ticket is about copying the fix date variable. Comment 10: "When you open as copy, the original document with fixed fields is used as a *template* for the new copy; and it's normal and expected that *for templates*, the fixed fields are updated (that is one of the reasons to use the fixed fields instead of inserting plain text)."