When receiving serial issues the 952$d (Date acquired) field should be pre-populated with the current date.
Created attachment 129126 [details] [review] Bug 29815: Pre-fill 952$d (Date acquired) when receiving serial items Test plan: 1. Create a subscription - Select the 'Create an item record when receiving this serial' 2. Receive the serial 3. After changing the status from 'Expected' to 'Arrived' notice that the 'd - Date acquired' is not set until you click on that field 4. Apply patch and restart services 5. Receive the serial again and notice this time today's date is pre-populated in 'd - Date acquired' Sponsored-By: Brimbank Library, Australia
Ready for testing
Created attachment 129127 [details] [review] Bug 29815: Pre-fill 952$d (Date acquired) when receiving serial items Test plan: 1. Create a subscription - Select the 'Create an item record when receiving this serial' 2. Receive the serial 3. After changing the status from 'Expected' to 'Arrived' notice that the 'd - Date acquired' is not set until you click on that field 4. Apply patch and restart services 5. Receive the serial again and notice this time today's date is pre-populated in 'd - Date acquired' Sponsored-By: Brimbank Library, Australia
Created attachment 129204 [details] [review] Bug 29815: Pre-fill 952$d (Date acquired) when receiving serial items Test plan: 1. Create a subscription - Select the 'Create an item record when receiving this serial' 2. Receive the serial 3. After changing the status from 'Expected' to 'Arrived' notice that the 'd - Date acquired' is not set until you click on that field 4. Apply patch and restart services 5. Receive the serial again and notice this time today's date is pre-populated in 'd - Date acquired' Sponsored-By: Brimbank Library, Australia Signed-off-by: Samu Heiskanen <samu.heiskanen@hypernova.fi>
I am not sure about this one as it changes the behavior of one item form making it inconsistent with the others in cataloguing and acq. Also, if you leave the date accessioned empty, it is automatically set to today's date without any interaction needed. It's here: https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/Item.pm#L117 On the other hand that's not obvious to the user. Maybe we should change the behavior of the other forms as well? Add a hint?
Created attachment 129237 [details] [review] Bug 29815: Pre-populate 'Date acquired' field when adding/editing items This patch pre-fills the 952$d (Date acquired) item subfield on page load. Users can still click on the field to fill this subfield. Test plan: 1. Visit a biblio. Add an item, observe on page load the 'Date acquired' subfield is empty 2. Visit a subscription. Receive a serial, observe after setting the serial status to 'Arrived' the item form loads with an empty 'Date acquired' subfield 3. Apply patch and restart services 4. Repeat step 1 and confirm now on page load the 'Date acquired' subfield populates with today's date 5. Delete the populated 'Date acquired' subfield value. Click in the field and confirm the field is populated and the calendar input displays 6. Delete the 'Date acquired' subfield value again. Confirm that tabbing from a different field into the date acquired field behaves the same as click 7. Repeat step 2. This time confirm on page load the 'Date acquired' subfield contains the current date 8. Delete the populated 'Date acquired' subfield value. Click in the field and confirm it is populated 9. Delete the populated 'Date acquired' subfield value. Tab to the field from another field and confirm it behaves the same as click 10. Visit a biblio. Edit an item with a date acquired value in the past. Confirm the date acquired value is unchanged after saving. Sponsored-By: Brimbank Library, Australia
Hi Samu and Katrin, Thank you for your testing and QA. Katrin, I have gone with your suggestion of changing the other forms to work the same as the serial edit one. To do this I have edited the dateaccessioned plugin itself. I think this one is ready to test again now. Thanks! Alex
This patchset still applies cleanly to master and is ready for testing if someone is available :)
Created attachment 133221 [details] [review] Bug 29815: Pre-populate 'Date acquired' field when adding/editing items This patch pre-fills the 952$d (Date acquired) item subfield on page load. Users can still click on the field to fill this subfield. Test plan: 1. Visit a biblio. Add an item, observe on page load the 'Date acquired' subfield is empty 2. Visit a subscription. Receive a serial, observe after setting the serial status to 'Arrived' the item form loads with an empty 'Date acquired' subfield 3. Apply patch and restart services 4. Repeat step 1 and confirm now on page load the 'Date acquired' subfield populates with today's date 5. Delete the populated 'Date acquired' subfield value. Click in the field and confirm the field is populated and the calendar input displays 6. Delete the 'Date acquired' subfield value again. Confirm that tabbing from a different field into the date acquired field behaves the same as click 7. Repeat step 2. This time confirm on page load the 'Date acquired' subfield contains the current date 8. Delete the populated 'Date acquired' subfield value. Click in the field and confirm it is populated 9. Delete the populated 'Date acquired' subfield value. Tab to the field from another field and confirm it behaves the same as click 10. Visit a biblio. Edit an item with a date acquired value in the past. Confirm the date acquired value is unchanged after saving. Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Thanks for testing Owen!
Created attachment 133343 [details] [review] Bug 29815: Pre-populate 'Date acquired' field when adding/editing items This patch pre-fills the 952$d (Date acquired) item subfield on page load. Users can still click on the field to fill this subfield. Test plan: 1. Visit a biblio. Add an item, observe on page load the 'Date acquired' subfield is empty 2. Visit a subscription. Receive a serial, observe after setting the serial status to 'Arrived' the item form loads with an empty 'Date acquired' subfield 3. Apply patch and restart services 4. Repeat step 1 and confirm now on page load the 'Date acquired' subfield populates with today's date 5. Delete the populated 'Date acquired' subfield value. Click in the field and confirm the field is populated and the calendar input displays 6. Delete the 'Date acquired' subfield value again. Confirm that tabbing from a different field into the date acquired field behaves the same as click 7. Repeat step 2. This time confirm on page load the 'Date acquired' subfield contains the current date 8. Delete the populated 'Date acquired' subfield value. Click in the field and confirm it is populated 9. Delete the populated 'Date acquired' subfield value. Tab to the field from another field and confirm it behaves the same as click 10. Visit a biblio. Edit an item with a date acquired value in the past. Confirm the date acquired value is unchanged after saving. Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Makes sens. For a total free input, one must not use this value builder.
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
Thank you all for your testing and QA!
Jumping in here regarding Bug 29963, but I think prepopulating date acquired when editing items is an undesirable behavior. It would need to be cleared more often than it would be useful. Makes sense when receiving serials or adding new items, but modification and batch modification it's just an annoyance.
(In reply to Benjamin Daeuber from comment #15) > Jumping in here regarding Bug 29963, but I think prepopulating date acquired > when editing items is an undesirable behavior. It would need to be cleared > more often than it would be useful. Makes sense when receiving serials or > adding new items, but modification and batch modification it's just an > annoyance. How easy is it to have the plugin know in which context it works?
"Pre-populate 'Date acquired'" was the target, but not the plugin in general. So because of this it covers much more, and those extras are not expected nor desirable: 1. this code in the ticket prepopulates ANY field to which the plugin added. Wrong behavior. This plugin is not aimed to be ONLY for the 'Date acquired' field. 2. It also silenltly prepopulates the field in edit mode when it is expected to be empty by the wish of the librarian. 3. It also prepopulates fields for item batch edit form, which is even more undesired to be so. These ticket changes need to be reverted. Maybe re-thought for the solution needed later, but now it makes problems. For example, I released a quick patch for all productions which went to Koha 22.05 because of the above 3 bad effects. Later - this might be, but the more complicated solution, as Marcel de Rooy said: the plugin should be aware in which context it is executed, but even with this, this requires to be with some preferences at least: after checking on production libraries most said this is not their wish to have this autofill, they ok to press "..." (three dots on the right to call plugin's 'today date fill' feature).
I think the original patch attached here is the better approach.. the one that changes PrepareItemForDisplay in C4::Items