Currently, if an item marked as lost is missed at checkin, the system does not alert the librarian that the item was lost when issuing the item to a patron. We should add an alert with an ok/cancel box similar to the one for checking out items that are already issued to another patron.
Created attachment 8927 [details] [review] Bug 7758 - Koha allowing LOST items to check out without alert Adds a confirmation alert when issuing an item that has been marked as lost.
patch looks good - one caveat, I suspect someone will propose that this should be a syspref.
Created attachment 8931 [details] [review] Bug 7758 - Koha allowing LOST items to check out without alert Adds a confirmation alert when issuing an item that has been marked as lost. Signed-off-by: Liz Rea <wizzyrea@gmail.com> passes tests, works as advertiesd Tested: - checking out an item that is marked lost performs all usual lost operations - checking out an item that is marked lost prompts for confirmation
In check-in we show a non-blocking message that something was lost. I'm curious why we should block check-out.
(In reply to comment #4) If the consensus is that this should be non-blocking, I can modify the patch. > In check-in we show a non-blocking message that something was lost. I'm > curious why we should block check-out.
(In reply to comment #2) > patch looks good - one caveat, I suspect someone will propose that this > should be a syspref. Let me be that guy, non blocking and a syspref that can turn the alert off altogether if wanted.
QA comment: tiny patch, nothing to say from QA point of view Pushing this patch before string-freeze because it contains a string !
Created attachment 9082 [details] [review] Bug 7758 - Followup - Make alert non-blocking
Created attachment 9087 [details] [review] Bug 7758 - Followup - Make alert non-blocking Signed-off-by: Liz Rea <wizzyrea@gmail.com> passes tests, works as expected. I prefer the original, but this will suffice for the purposes of the original bug.
Honestly, I prefer the original as well. Let's set this to in discussion for now. Maybe we can get some more people to weigh in on this.
If you did a syspref you could have all 3 ; no alert, non blocking alert, blocking alert. Seems easiest to me.
That sounds like a good plan, I'll write another followup to implement that. (In reply to comment #11) > If you did a syspref you could have all 3 ; no alert, non blocking alert, > blocking alert. Seems easiest to me.
Created attachment 9116 [details] [review] Bug 7758 - Followup - Add syspref allow a choice of blocking, non-blocking, or do nothing when issuing lost items.
The patch that was included in master will be included in the Koha 3.6.5 release.
This follow up patch works for all 3 scenarios. On a side note there is a conflict in the updatedatabase file, not really sure if that is noteworthy since it happens often.
Created attachment 9625 [details] [review] Bug 7758 - Followup - Add syspref allow a choice of blocking, non-blocking, or do nothing when issuing lost items. Signed-off-by: Liz Rea <wizzyrea@gmail.com> Works as advertised.
QA comment: * shouldn't this patch be in another bug ? I've pushed something for 7758 already, and can't push the follow-up/new patch in this branch without pain. Plus it's not really a follow-up, it's a 3.10 enhancement. * Adding an "alert" hash to CanBookBeIssued seems a good idea to me, must be advertised (i'll take care of this in my RM monthly newsletter when I'll push this patch) No other comment from QA point of view. Please create another bug, attach this patch to it (directly "signed-off", and i'll take care of pushing it
Done, bug 8167. Kyle (In reply to comment #17) > QA comment: > * shouldn't this patch be in another bug ? I've pushed something for 7758 > already, and can't push the follow-up/new patch in this branch without pain. > Plus it's not really a follow-up, it's a 3.10 enhancement. > * Adding an "alert" hash to CanBookBeIssued seems a good idea to me, must > be advertised (i'll take care of this in my RM monthly newsletter when I'll > push this patch) > > No other comment from QA point of view. > Please create another bug, attach this patch to it (directly "signed-off", > and i'll take care of pushing it