# Background # The "Fixed Date" (or time) fields make sense because often you don't want these fields to update every time you open an existing document. Sometimes however, these fields need to be updated, for example when basing a new document on an existing one. When this is a one-shot procedure, creating a template does not make sense, so the date field must be updated manually. Currently the only workaround is to change the field to non-fixed date, then back to fixed again. See also https://ask.libreoffice.org/t/manual-update-of-date-field/23879 for a discussion of this. # Proposed enhancement # There should be an action (maybe in the right-click menu) to update a specific "Fixed Date / Time" field to the current value.
I believe it's a WONTFIX. Even for a one-time creation of a new document based on an existing document, when you don't want to create a template, you can use an existing ODT as a template: just use LibreOffice's -n file open argument [1]. And that is really simple using shell integration: right-clicking on a document in e.g. Windows Explorer gives you a "New" item, along with "Open" and "Print". That treats the ODT as a template, and properly updates the respective fields. OTOH, the new UI can be implemented, nothing technical really blocks that. So - if UX thinks it's reasonable, and someone volunteers to implement that, no objections from myself. [1] https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html?DbPAR=SHARED#par_id20161204125123476
Bug 84973 requests the opposite, to keep a fix date unchanged even after open as copy. The function to be introduced could follow Tools > Update > Fields as Update > Fields (Fix), or the like.
Currently, the "fixed date" field implicitly actually means "Date of field insertion". What @Quazgar is asking for is more like a combination of a "Set variable" field with an anonymous variable and a certain Date format, plus a "Show variable" for that anonymous variable. Altering the semantics or the behavior of the Date field is one, but not the only, way to achieve this. Other ways would probably not clash with the request in 84973. Specifically: Adding a "Format value" or "Show formatted value" field type. That being said - @Quazgar can get the effect they're asking for by inserting the two fields. It's not that bad. Mike(In reply to Mike Kaganski from comment #1) > Even for a one-time creation of a new document based on an existing > document etc. You're addressing @Quazgar's example. Maybe it's not the best example, but it's not unreasonable to want to have LibreOffice format date values for you, and later change either the format or the value, separately.
(In reply to Eyal Rozenberg from comment #3) > Currently, the "fixed date" field implicitly actually means "Date of field > insertion". No, it means "date of field insertion *or* (much more importantly) document creation" - it is tightly coupled with template mechanism, and is independent of the file properties (when you can easily change file creation date). > What @Quazgar is asking for is more like a combination of a "Set variable" > field with an anonymous variable and a certain Date format, plus a "Show > variable" for that anonymous variable. Use F2 in Writer to insert a formula, which accepts any value. It only lacks an easy way to enter dates, but easily allows to format to any supported format. And no, this is different. Date (fixed) is more of "for-the-record" thing, not supposed to be edited by user. And what OP is asking is the same functionality - just with a wrong workflow *when creating a document* based on another document as a template. > Altering the semantics or the behavior of the Date field is ... not an option. > Mike(In reply to Mike Kaganski from comment #1) > You're addressing @Quazgar's example. Yes. And when you extend the request arbitrarily, you hijack the request to what was not requested.
I would suggest not to change this, indeed..
(In reply to Quazgar from comment #0) > Currently the only workaround is to change the field to non-fixed date, then > back to fixed again. This is really easy to do (at least in 7.5). Agree with WONTFIX.
(In reply to Mike Kaganski from comment #1) > And that is really simple using shell integration: right-clicking on a > document in e.g. Windows Explorer gives you a "New" item, along with "Open" > and "Print". That treats the ODT as a template, and properly updates the > respective fields. > This doesn't appear to exist on macOS though, so how would that be organized on that OS ? I don't see anything readily accessible via either the Dock applet menu, or the general Finder context menu. This is actually a functionality that would be very useful for us in our firm, as we regularly have documents with an initial fixed date that require updating to contain more recent information or changes to that initial information, yet need to have the date updated from the fixed date to the current date at which the changes are made. Having to go through the field definition menu and switch back again is neither very efficient nor user friendly. Having a context menu update function associated with the fixed field date to update it to current date would be very welcome and improve our workflow.
(In reply to Alex Thurgood from comment #7) > This doesn't appear to exist on macOS though, so how would that be organized > on that OS ? By creating an enhancement request to add that to the respective shell integration. Or by using the command line with -n command line parameter. Again: adding a "update" to something that is *designed* to be not updatable is not a proper solution. Also, it's totally incorrect to "update" a date/time field interactively, because it would set it to a random moment, not related to document creation time - either you need to be able to set it to a specific date/time (entered manually), or the timestamp of a click event has no value at all.
We discussed this topic in the design meeting. While the use case is clear (see comment 7) and the functionality has some benefit it's also pretty simple to overwrite the field. So balancing the convenience with the downsides we recommend to not implement it.
(In reply to Heiko Tietze from comment #9) > While the use case is clear (see comment 7) The comment 7 tells: > we regularly have documents with an initial fixed date that require > updating to contain more recent information or changes to that initial > information, yet need to have the date updated from the fixed date to the > current date at which the changes are made. The date/time of the changes is "Modified" filed from DocInformation category. So fixed date/time is using a wrong tool.
(In reply to Mike Kaganski from comment #10) > (In reply to Heiko Tietze from comment #9) > > While the use case is clear (see comment 7) > > > The date/time of the changes is "Modified" filed from DocInformation > category. So fixed date/time is using a wrong tool. So, if I have understood correctly, I would need to swap out all of the fixed date fields in our existing documents for the DocInfo "Modified" field ? Just trying to understand the new workflow with regard to the thousands of our existing documents which already have majoritarily fixed date fields in them. Of those, several hundred will require changing. I would posit that having Insert > Field > Date (which by default is fixed) as the default menu entry in Writer is probably not the wisest UI choice then ? At least I have learned something, and for that I am grateful. What seems to be the natural choice from the UI is not the one for the job.
(In reply to Alex Thurgood from comment #11) > I would posit that having Insert > Field > Date (which by default is fixed) > as the default menu entry in Writer is probably not the wisest UI choice > then ? If you imply that the wisest UI choice is the one that fits your use case, i.e. you know that your use case is the one users need most, then yes ;) This is a hint that there is always a way to change the UI, but it needs to be justified by the pros vs contras balance.
(In reply to Alex Thurgood from comment #11) > I would posit that having Insert > Field > Date (which by default is fixed) > as the default menu entry in Writer is probably not the wisest UI choice > then ? Resolved for bug 139141
*** Bug 81079 has been marked as a duplicate of this bug. ***
*** Bug 130992 has been marked as a duplicate of this bug. ***