This is a request to correct the regression caused by Bug 139141 - "Make Field > Date (variable) the default and rename". Although originally raised in Dec 2020, Bug 139141 was only actioned in the latest release LO v7.6 (Sep 2023). I've just been bitten by the 'defect' it has introduced, but luckily reopened a document edited the previous day and saw the recently inserted Date and Time field values had changed as they were actually Present values - not the Fixed I intended. My request is to revert the default Date and Time fields assigned via Tools > Customise > Keyboard tab > Category= Insert > Function= 'Date' or 'Time' to FIXED, but offer additional selection options for Date-current and Time-current fields for anyone wishing to create shortcuts to them. RATIONAL: The time-honoured method to quickly insert Date and Time (fixed) fields is via Writer Keyboard Shortcuts Ctrl+; and Ctrl+: respectively. However in LO v7.6, the "Data" and "Time" fields offered via Keyboard Shortcuts have changed to current values. Note the field names are unchanged. Also there is presently no possibility via Keyboard Shortcuts to select 'Date (fixed)' or 'Time (fixed)'. I'd question the original Bug 139141 assumption that current-date should the default. I use current-date very occasionally in a template to display a document's 'Print-date'. However I use fixed-date and fixed-time on 100's of occasions across many documents which record date & time of e.g. medicine dispensing or logging network and computer faults - these fields should never change after initial insertion. I anticipate there will be many unhappy users over the next few weeks/months as they discover recently added data becoming 'corrupted'.
I understand that the bug 139141 fix has two issues: - it made the UNO command change, which wasn't planned - and therefore the Fixed value can't be assigned a shortcut So moving forward I suggest: - revert the bug 139141 commit so existing macros are unaffected - have 2 distinct UNO commands for the two distinct fields - make Variable the menu and dialog default as requested in bug 139141 Did I miss something?
I believe we should not revert, because the fix of old UNO would likely be in different files / functions. The new UNO for non-fixed date/time should IMO be discussed first. Let us limit this to the regression part, and not introduce anything new here.
A further inconsistency observed is that Menu Insert > Field > DATE now produces different results between Writer and Calc: - Writer: Date Current (changed with Bug 139141) - Calc: Date Fixed (as always) I believe the default for both should be Date Fixed. [In Calc, Date Current is achieved with Function NOW()]
What if there were drop down menus, or tic boxes for fixed, non-fixed in Options > Language?
(In reply to bugzilla from comment #3) > A further inconsistency observed is that Menu Insert > Field > DATE now > produces different results between Writer and Calc: > - Writer: Date Current (changed with Bug 139141) > - Calc: Date Fixed (as always) > > I believe the default for both should be Date Fixed. > [In Calc, Date Current is achieved with Function NOW()] That's a good point, thanks for raising that. Consistency across components is important. In 7.6, we have as defaults: - .uno:InsertTimeField in Writer, which now inserts a variable time field, and - .uno:InsertCurrentTime in Calc, which inserts a fixed time. (In reply to Mike Kaganski from comment #2) > I believe we should not revert, because the fix of old UNO would likely be > in different files / functions. The new UNO for non-fixed date/time should > IMO be discussed first. Let us limit this to the regression part, and not > introduce anything new here. Sorry Mike, can you clarify what you think needs to be done to resolve the issue? Would be good to have a clear plan agreed on with Heiko. I'm still confused about what is the best course of action. My main concern is that a macro using uno.InsertTimeField does something different if executed with 7.5 vs 7.6. I assume this breaks many users' programs. Please see the attached macro in next comment.
Created attachment 190247 [details] sample macro in ODT 1. Open attachment in LO 7.5 2. Tools > Macros > Run macros... > (document's macros) > Standard > ticktock > Main > Run 3. Do the same in LO 7.6
*** Bug 157800 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #5) > Mike, can you clarify what you think needs to be done to resolve the > issue? Would be good to have a clear plan agreed on with Heiko. I'm still > confused about what is the best course of action. Since Heiko didn't change the InsertTimeField UNO, it is clear that that UNO has a flaw, because it obviously takes whatever is the "default". There are twi approaches to fix this issue: 1. Revert the change that caused the problem. Then it would also undo the fix to bug 139141. This is technically the easiest option. 2. Alternatively, look into the InsertTimeField UNO code (entry point is at https://opengrok.libreoffice.org/xref/core/sw/source/uibase/shells/textfld.cxx?r=fca39498#707), and try to fix its implementation (likely nInsertSubType should be defined there). This would be my suggestion here: to check which nInsertSubType is needed there to fix it.
(In reply to Mike Kaganski from comment #8) > There are two approaches to fix this issue: > > 1. Revert the change that caused the problem. Then it would also undo the > fix to bug 139141. This is technically the easiest option. > 2. Alternatively, look into the InsertTimeField UNO code (entry point is at > https://opengrok.libreoffice.org/xref/core/sw/source/uibase/shells/textfld. > cxx?r=fca39498#707), and try to fix its implementation (likely > nInsertSubType should be defined there). This would be my suggestion here: > to check which nInsertSubType is needed there to fix it. OK, I agree with you that we should go with the sturdier solution 2. And I assume something similar needs to be done for FN_INSERT_FLD_DATE ? Heiko, OK with that?
The patch switched the sequence of variable and fixed date/time. And the commands .uno:InsertTimeField and .uno:InsertDateField obviously just pick the first item from the list. Users expect a) to easily insert either variable or fixed values per shortcut, and b) want macros to behave consistently. The UNO command needs a) to default to what the user chose recently (see also bug 157420) and b) to take a parameter for independent macros. But it still keeps UI and internal processing coupled. So we perhaps have to bloat the API and add .uno:InsertVariableTimeField (same for Date) with keeping/reverting uno:InsertTimeField to the fixed values.
(In reply to Heiko Tietze from comment #10) > b) want macros to behave consistently Cosistent behavior of API means its behavior should not change without a great need. No one ever asked .uno:InsertDateField to change its behavior; the *only* request was in the dialog. And your change must not extend to the UNO. > The UNO command needs > a) to default to what the user chose recently (see also bug 157420) and b) > to take a parameter for independent macros. No. It's very unusual to say, but it's you who is now trying to bloat it without even a request from users ;) > But it still keeps UI and > internal processing coupled. So we perhaps have to bloat the API and add > .uno:InsertVariableTimeField (same for Date) with keeping/reverting > uno:InsertTimeField to the fixed values. No. Just make it simple. Fix the old UNO, and do not introduce anything else. If users need more flexibility, the API has the means, that were working for ages.
(In reply to Mike Kaganski from comment #11) > (In reply to Heiko Tietze from comment #10) > > a) to default to what the user chose recently (see also bug 157420) I stand corrected. The new UNO might be needed. But it's still a different task. The old one must not follow the last choice, it needs to stay fixed, as it was.
OK, let's focus this ticket on fixing the regression then, which is the most urgent thing. Changing the summary accordingly. We can move to other, less urgent tasks, in other tickets later on. Setting importance to "high" because it breaks existing macros.
https://gerrit.libreoffice.org/c/core/+/158041 reverts the regression. Perhaps we better reopen the old ticket.
Just to confirm that this bug report has been resolved/fixed in LO 7.6.3.2 on. Thanks.
thanks for reporting and verifying! :)