https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Andrew Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nugged@gmail.com --- Comment #1 from Andrew Nugged <nugged@gmail.com> --- this same bad UX experience we have from our customers libraries too. Confirming this ticket. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #3 from Andrew Nugged <nugged@gmail.com> --- it's still questionable is it needed or not auto-filled on the "new item addition" screen. Maybe or maybe not, I'll check with our librarians too. But seems for sure it makes noise and mistakes in batch modification screens. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #5 from Andrew Nugged <nugged@gmail.com> --- Tested, and found more inconvenience, yes: when you EDIT an old item that has for example empty 952w (on which this plugin assigned for our customers) and you want this field to STAY empty after editing - you always need to clean up that field manually, it really makes very BAD UX! Should be removed, definitely. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Peter Vashchuk <stalkernoid@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Peter Vashchuk <stalkernoid@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #135581|0 |1 is obsolete| | --- Comment #7 from Peter Vashchuk <stalkernoid@gmail.com> --- Created attachment 135582 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135582&action=edit Bug 29963: remove set_to_today function from dateaccessioned.pl Removed the function that wasn't used anywhere outside of dateaccessioned.pl, as it was causing inconveniences when user was trying to edit items in batch, it would constantly set Date Acquired field to today's date which created the need for user to constantly manually clear the field, so that it doesn't overwrite the original Acquired date. When you add item without specifying any date for Date Acquired it automatically sets the today's date for it so this change doesn't seem to break any logic there. And when you try to edit item with already set Date Acquired before it will show the previously defined date, not disrupting anything here as well. To reproduce: 1. Edit items in batch for any biblio, see that "d - Date acquired" field is automatically set to current day's date. 2. Apply the patch 3. "d - Date acquired" should be empty after that. 4. Additionally, go to the additem.pl to edit single item and check that it correctly shows Date acquired in that field. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|slavashishkin@gmail.com |stalkernoid@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #10 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- (In reply to Jonathan Druart from comment #8)

You are then reverting commit bd197c64567fba6899f12e4897d786adf52384d8 Bug 29815: Pre-populate 'Date acquired' field when adding/editing items

I can't imagine why you would want date acquired field prepopulated when you are editing items. Adding items makes sense to me, but not editing. We would need to clear the field every time we made a small change or batch modified shelf locations or really any other daily activity. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Peter Vashchuk <stalkernoid@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #135683|0 |1 is obsolete| | --- Comment #12 from Peter Vashchuk <stalkernoid@gmail.com> --- Created attachment 135684 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135684&action=edit Bug 29963: do not prefill empty date fields with today's date Revert "Bug 29815: Pre-populate 'Date acquired' field when adding/editing items" commit bd197c64567fba6899f12e4897d786adf52384d8 Items date fields in MARC framework with dateaccessioned.pl assigned as plugin automatically prefilled by it with today's date if empty on page load. This becomes big problem because it silently changes empty date fields in single item edit form with today's date. This drastically degrades UX because user won't noitce that fields were filled. Also, even when user aware about this problem, user is forced to clean the field manually each time they edit items with empty fields. Also in item batch edit tool the probability heavily increases to make mistake and leave those fields prefilled on mass. To reproduce problem with single item edit: 1. Edit single item that doesn't have a date set in any of the date fields where dateaccessioned.pl in MARC framework assigned as plugin, see that the field got prefilled with today's date. 2. Save the item. See that it overwrote the previously empty date. 3. Apply the patch. 4. Edit single item again, and ensure that the empty date fields don't get overwriten like it happened previously. To reproduce problem with bath edit: 1. Edit items in batch for any biblio, see that the date fields where dateaccessioned.pl in MARC framework assigned as plugin is automatically set to current day's date. 2. Apply the patch. 3. Check the fields again, they should be empty after that. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #13 from Andrew Nugged <nugged@gmail.com> --- Benjamin Daeuber: I also support your problem - we have the same issues and very concerned customers :). So this patch (reverting) is needed. I suspect Jonathan just said that the ticket patch should be just a reversal of the previous commit, not a standalone commit. to Jonathan: please hint Petro on how to make a "reversal". -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|date picker automatically |Date picker automatically |fills todays date on |fills today's date on |cataloging screens |cataloging screens -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #16 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 135744 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135744&action=edit Bug 29963: Do not prefill empty date fields with today's date Revert "Bug 29815: Pre-populate 'Date acquired' field when adding/editing items" commit bd197c64567fba6899f12e4897d786adf52384d8 Items date fields in MARC framework with dateaccessioned.pl assigned as plugin automatically prefilled by it with today's date if empty on page load. This becomes big problem because it silently changes empty date fields in single item edit form with today's date. This drastically degrades UX because user won't noitce that fields were filled. Also, even when user aware about this problem, user is forced to clean the field manually each time they edit items with empty fields. Also in item batch edit tool the probability heavily increases to make mistake and leave those fields prefilled on mass. To reproduce problem with single item edit: 1. Edit single item that doesn't have a date set in any of the date fields where dateaccessioned.pl in MARC framework assigned as plugin, see that the field got prefilled with today's date. 2. Save the item. See that it overwrote the previously empty date. 3. Apply the patch. 4. Edit single item again, and ensure that the empty date fields don't get overwriten like it happened previously. To reproduce problem with bath edit: 1. Edit items in batch for any biblio, see that the date fields where dateaccessioned.pl in MARC framework assigned as plugin is automatically set to current day's date. 2. Apply the patch. 3. Check the fields again, they should be empty after that. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Attachment #135684|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #18 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I'm a little torn here.. I've grabbed the original patch from bug 29815 that accomplished the goal in a different manner, but failed QA by Katrin as it doesn't affect all data entry locations. I have renamed the bug, as this is directly related to the dateaccessioned plugin, not all date fields.. it's only date field where end users have explicitly set the field to use dateaccessioned.. should there be a simple datepicker plugin to go along with dateaccessioned as an alternative to these patches.. it highlights a flaw that people are re-using that plugin for non-accession fields in my opinion. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #20 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Martin: Thank you for attaching the original patch from bug 29815 to this bug report. I agree with you Martin that the problem is compounded if libraries have linked multiple MARC subfields, not just the 952$d (date acquired) subfield, to the dateaccessioned.pl plugin. --- Andrew: I am sorry that my patch on 29815 has caused these unintended problems for people! You’re right the intention of 29815 was to populate the 952$d (Date acquired) field to the current date when adding a new item or receiving a new serial issue. --- Jonathan: You said it would be useful to have feedback from people involved in 29815 so everyone's needs were met. So here is the background context and needs that 29815 was intended to address: We added the 29815 patch because it was thought that Koha did not previously make it clear to cataloguers that if they save the ‘Add item’ page (or receive serial issue page) without setting anything in the 952$d subfield, Koha would still populate the 952$d with today's date. Pre-populating the 952$d on page load was intended to show that a value would be set for that subfield. --- Going forward if there are concerns with the original patch changing the behavior of one item form making it inconsistent with others in cataloguing and acq. Then I think, instead of a behavior change, it should be sufficient to add a hint saying that if you save the 952$d with nothing in it Koha will still auto-populate the 952$d with today's date. Perhaps this is the most straight forward solution? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #22 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Created attachment 135755 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135755&action=edit Bug 29963: Display a hint that the 952$d will be filled with current date if blank This hint will show when: - Adding an item - Editing an item - Receiving a serial issue Test plan: 1. Apply patch 2. Add an item to a biblio record, notice there is a hint message for the 952$d (date acquired) subfield 3. Edit an item, notice there is a hint message displaying for the 952$d subfield 4. Receive a serial (The subscription must be setup to create an item upon receival to test this). 5. Notice there is a hint message displaying for the 952$d (Date acquired) subfield in both the main issue you are receiving and the supplemental issue form as well Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #24 from Benjamin Daeuber <bdaeuber@cityoffargo.com> ---

Going forward if there are concerns with the original patch changing the behavior of one item form making it inconsistent with others in cataloguing and acq. Then I think, instead of a behavior change, it should be sufficient to add a hint saying that if you save the 952$d with nothing in it Koha will still auto-populate the 952$d with today's date. Perhaps this is the most straight forward solution?

I'm not sure I agree with this. I don't really see an issue with being context aware. Hints get missed with potentially far reaching consequences in the case of a batch edit. Logical, context aware behavior seems more user friendly. It makes sense to populate that field in the case of serials and new items, but not in the case of item edits. I don't really find that to be an inconsistent behavior. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #26 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi, the inconsistency that we discussed was that the same field should show the same behaviour in all places where we can add items. These are: * Adding items in serials * Adding items in cataloguing * Adding items in acquisitions I believe that serials and acq use similar code, but the code for cataloguing is different. The issue as I understand it was the 'hidden' behaviour. People assumed that leaving the field empty would mean 'no dateaccessioned' while Koha would _always_ use today's date if left empty. Or they would feel a need to fill out the field, when it was not necessary, adding extra steps. I think reverting and adding a hint would actually be a good start. Being context aware only pre-filling when the item is added/new would also be a good compromise. I just wonder if it might upset people that do a lot of cataloguing of items with past accession dates where it might feel like an issue having to change the pre-filled value. Also another thought pro hint: if we pre-fill, setting date-accessioned to mandatory will have no effect/the warning will never trigger. This might be an issue for libraries that want to make sure the date is verified manually. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29958 --- Comment #28 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think there is 2 sides to this bug or even 2 separate bugs: 1) Handling in the item editor with the field being filled in 2) Adding the dateeaccessioned on editing even when emptied out. 2) is actually this bug and was not caused by the pre-fill change, but bug 23463: Bug 29958 - Missing dateaccessioned is set to today when storing an item I believe we might want to treat them separately to not have things even more confusing. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #30 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Sounds good to me Alex. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30931 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30931 [Bug 30931] Handling of items.dateaccessioned in the item editor -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #135746|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 --- Comment #33 from Alex Buckley <alexbuckley@catalyst.net.nz> --- (In reply to Alex Buckley from comment #32)

I have shifted Martin's and my patches to bug 30931 to keep this bug report, hopefully, focused on reverting bug 29815 as quickly as possible.

Discussion around how the community would like the item editor to handle the dateaccessioned field is very welcome on bug 30931 :)

Hi Katrin, Martin and others who may know, As I wrote the original patch 29815 am I allowed to sign off the patch on this ticket - which is reverting 29815? I had assumed not, but I just wanted to check :) Alex -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #135744|0 |1 is obsolete| | --- Comment #35 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 136153 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=136153&action=edit Bug 29963: Do not prefill empty date fields with today's date Revert "Bug 29815: Pre-populate 'Date acquired' field when adding/editing items" commit bd197c64567fba6899f12e4897d786adf52384d8 Items date fields in MARC framework with dateaccessioned.pl assigned as plugin automatically prefilled by it with today's date if empty on page load. This becomes big problem because it silently changes empty date fields in single item edit form with today's date. This drastically degrades UX because user won't noitce that fields were filled. Also, even when user aware about this problem, user is forced to clean the field manually each time they edit items with empty fields. Also in item batch edit tool the probability heavily increases to make mistake and leave those fields prefilled on mass. To reproduce problem with single item edit: 1. Edit single item that doesn't have a date set in any of the date fields where dateaccessioned.pl in MARC framework assigned as plugin, see that the field got prefilled with today's date. 2. Save the item. See that it overwrote the previously empty date. 3. Apply the patch. 4. Edit single item again, and ensure that the empty date fields don't get overwriten like it happened previously. To reproduce problem with bath edit: 1. Edit items in batch for any biblio, see that the date fields where dateaccessioned.pl in MARC framework assigned as plugin is automatically set to current day's date. 2. Apply the patch. 3. Check the fields again, they should be empty after that. Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |22.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|22.11.00 |22.11.00, 22.05.03 released in| | CC| |lucas@bywatersolutions.com Status|Pushed to master |Pushed to stable --- Comment #38 from Lucas Gass <lucas@bywatersolutions.com> --- Backported to 22.05.x for 22.05.03 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29963 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31665 -- You are receiving this mail because: You are watching all bug changes.