Description
Kyle M Hall (khall)
2014-06-04 17:52:12 UTC
Hm, I am not sure we want to match the staff client behaviour to the script in all cases. I think a workflow for the library could be: don't automatically remove lost items from the account, but use a special lost value and let the staff check them, beore marking them lost and removing them from the account. It might be good to still allow to control them independently. Created attachment 68212 [details] [review] Bug 12363: Add new pref MarkLostItemsAsReturned Created attachment 68213 [details] [review] Bug 12363: Add a switch to mark|do not mark items as returned when lost There are several ways to mark an item an lost: - item list view (catalogue/moredetail.pl, "Items" tab) - cataloguing (cataloguing/additem.pl) - Batch item modification tools (tools/batchMod.pl) - The long overdue cronjob (misc/cronjobs/longoverdue.pl) So far only the cronjob is configurable, the others mark the item as returned (does the checkin). This behaviour should be controlable using a syspref, to let libraries choose what fit best for them. Test plan: Use the 2 options of the pref, mark checked out items as lost using the different possibilities, and confirm that the behaviours make sense to you Return is correctly done or blocked depending on the syspref. I tried to mark lost items using the pages (catalogue/moredetail.pl, "Items" tab) / (cataloguing/additem.pl) / (tools/batchMod.pl) but lost status is never saved. I don't know how to try with long overdue cronjob. I used Biblibre's sandbox#2. I set parameters by myself because there where no authorized value for the 'LOST' list and the field 995$2 was hidden and not linked to this list. Maybe I did something wrong... My bad, I forgot when I set the authorized values that only numbers were allowed and I used letters. Sorry. Behaviour is correct. Patch tested with a sandbox, by Séverine QUEUNE <severine.queune@bulac.fr> Created attachment 68256 [details] [review] Bug 12363: Add new pref MarkLostItemsAsReturned Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Created attachment 68257 [details] [review] Bug 12363: Add a switch to mark|do not mark items as returned when lost There are several ways to mark an item an lost: - item list view (catalogue/moredetail.pl, "Items" tab) - cataloguing (cataloguing/additem.pl) - Batch item modification tools (tools/batchMod.pl) - The long overdue cronjob (misc/cronjobs/longoverdue.pl) So far only the cronjob is configurable, the others mark the item as returned (does the checkin). This behaviour should be controlable using a syspref, to let libraries choose what fit best for them. Test plan: Use the 2 options of the pref, mark checked out items as lost using the different possibilities, and confirm that the behaviours make sense to you Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Created attachment 68684 [details] [review] Bug 12363: Add new pref MarkLostItemsAsReturned Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 68685 [details] [review] Bug 12363: Add a switch to mark|do not mark items as returned when lost There are several ways to mark an item an lost: - item list view (catalogue/moredetail.pl, "Items" tab) - cataloguing (cataloguing/additem.pl) - Batch item modification tools (tools/batchMod.pl) - The long overdue cronjob (misc/cronjobs/longoverdue.pl) So far only the cronjob is configurable, the others mark the item as returned (does the checkin). This behaviour should be controlable using a syspref, to let libraries choose what fit best for them. Test plan: Use the 2 options of the pref, mark checked out items as lost using the different possibilities, and confirm that the behaviours make sense to you Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Pushed to master for 17.11, thanks to everybody involved! *** Bug 13589 has been marked as a duplicate of this bug. *** I choose not to backport to 17.05.x since its getting old. |