https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Hugh Rundle <hughr@brimbank.vic.gov.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=15679 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #2 from Hugh Rundle <hughr@brimbank.vic.gov.au> --- (In reply to Katrin Fischer from comment #1)

Hi Hugh, so this woudl be to 'reset' a hold that has been waiting already? Does this happen often? It sounds like someone would be stealing from the waiting holds shelf.

Hi Katrin Yes, this is specifically for holds that are waiting already. It could be missing because someone has stolen it (rare, but certainly happens sometimes in libraries that have open shelves for waiting holds), or it may simply have been mislaid by staff between returning it and putting it on a waiting holds shelf (possible in a busy library). It's certainly more common that may initially seem likely. The other thing I've just realised would need to be either part of this enhancement, or paired with it perhaps as a different bug, is holds that go missing when they're in transit. i.e. the hold 'allocates' to a specific item when returned, but the pickup is at a different library. The notification won't be sent until it is returned at the pickup point, but it might go missing whilst in transit: in that case (which is more common) much the same process is needed, in that there needs to be a simple way to reverse the allocation since that item has gone missing, but there's probably no need to send a notification saying it got lost since there never would have been one saying it was ready to collect. -- 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=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexbuckley@catalyst.net.nz Status|NEW |Needs Signoff -- 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=20844 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |master Assignee|koha-bugs@lists.koha-commun |alexbuckley@catalyst.net.nz |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79267|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=20844 --- Comment #7 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Created attachment 80761 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80761&action=edit Bug 20844: Fixed error when cancelling hold from cataloguing/additem.pl Also fixed qa test tool failure on C4/Circulation.pm Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80761|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=20844 --- Comment #10 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Created attachment 80891 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80891&action=edit Bug 20844: Added tests of the RevertWaitingStatus and RevertItemLevelHoldToBibLevelHold subroutines in C4/Reserves.pm I have added unit tests for the two aforementioned subroutines which I added in the previous patches on bug 20844, to the t/db_dependent/Holds/RevertWaitingStatus.t test. Test plan: 1. Apply the patches on bug 20844 2. Go into koha-shell from the Koha home dir: sudo koha-shell <instancename> 3. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oleonard@myacpl.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80760|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=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80891|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=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #14 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Hi Michael Thanks for testing. Can you please try testing now using the test plan in the patch I have just attached. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #16 from Alex Buckley <alexbuckley@catalyst.net.nz> --- With the feature freeze coming up very soon are we able to get this moving along with testing? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #17 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Created attachment 81531 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81531&action=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell <instancename> 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81531|0 |1 is obsolete| | --- Comment #18 from Owen Leonard <oleonard@myacpl.org> --- Created attachment 81623 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81623&action=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell <instancename> 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard <oleonard@myacpl.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #20 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Created attachment 81640 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81640&action=edit Bug 20844: (follow-up) Fix style of dialogs This patch modifies the add item and item detail templates so that the hold cancellation dialogs match other similar dialogs in Koha. To test, apply the patch and perform step 10 or the original test plan. Confirm that the confirmation dialogs look correct. Confirmation dialogs look correct Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This enhancement gives release notes| |librarians easier control | |over waiting holds when | |items are marked as lost. | | | |When an item with a waiting | |item-level hold on it is | |marked as lost the | |librarian is given the | |option to retain the hold | |or to cancel it. | | | |When a | |lost item has an allocated | |waiting bib-level hold on | |it then if the | |'LostBibLevelHoldsRevert' | |syspref is enabled then the | |allocated hold is reverted | |to an unallocated bib-level | |hold. | | | |If the | |'LostItemCancelOutstandingT | |ransfers' syspref is | |enabled then any | |outstanding holds on the | |lost item are cancelled. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81623|0 |1 is obsolete| | --- Comment #22 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 81697 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81697&action=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell <instancename> 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard <oleonard@myacpl.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com QA Contact|testopia@bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com --- Comment #24 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I've split this into two distinct bugs.. one for the enhancement details here and another for the included LostItem change which cleans up transfers as I count that as it's own bug. -- You are receiving this mail because: You are watching all bug changes.

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81698|0 |1 is obsolete| | --- Comment #26 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 81711 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81711&action=edit Bug 20844: (follow-up) Fix style of dialogs This patch modifies the add item and item detail templates so that the hold cancellation dialogs match other similar dialogs in Koha. To test, apply the patch and perform step 10 or the original test plan. Confirm that the confirmation dialogs look correct. Confirmation dialogs look correct 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=20844 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #28 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I'm afraid I'm not confident enough thought has been given to this regarding all the different ways an item can be marked as lost. /tools/batchMod.pl, circ/pendingreserves.pl and mist/cronjobs/longoverdue.pl all call LostItem and would need some level of handling for the new workflow which require user input. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #29 from Alex Buckley <alexbuckley@catalyst.net.nz> --- Hi Martin Thanks for your feedback. I have tested and looked through the code calls in /circ/pendingreserves.pl, /tools/batchMod.pl and misc/cronjobs/longoverdue.pl I have noticed they are not consistent in their current handling of the reserves on lost items. * /circ/pendingreserves.pl - This cancels non-waiting item level reserves when item is marked as lost. Doesn't show allocated (waiting) holds. * /tools/batchMod.pl - Doesn’t cancel item-level or allocated bib-level reserves. * /misc/cronjob/longoverdue.pl - Doesn't cancel non-waiting (un-allocated) reserves It would be good to have a consistent approach throughout Koha for dealing with reserves on lost items. A question do you think it would be best to split this patch up so it is only dealing with allocated (waiting) holds. This would alter the behavior of the patches on the bug report which check for reserve type of 'waiting' or 'reserved'. Then we would only need to add reserve handling to /tools/batchMod.pl as longoverdue.pl and pendingreserves.pl don't touch waiting reserves. Amending longoverdue.pl and pendingreserves.pl could go in another bug report building on this to handle un-allocated holds, just to prevent too much scope creep on this bug report? Cheers, Alex -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug 20844 depends on bug 21732, which changed state. Bug 21732 Summary: If an item is marked as lost, any outstanding transfers upon it should be cancelled https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21732 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug 20844 depends on bug 21754, which changed state. Bug 21754 Summary: If an item is marked as lost, any outstanding transfers upon it should be automatically cancelled https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21754 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |In Discussion CC| |aleisha@catalyst.net.nz --- Comment #30 from Aleisha Amohia <aleisha@catalyst.net.nz> --- (In reply to Alex Buckley from comment #29)

It would be good to have a consistent approach throughout Koha for dealing with reserves on lost items.

A question do you think it would be best to split this patch up so it is only dealing with allocated (waiting) holds. This would alter the behavior of the patches on the bug report which check for reserve type of 'waiting' or 'reserved'.

Then we would only need to add reserve handling to /tools/batchMod.pl as longoverdue.pl and pendingreserves.pl don't touch waiting reserves.

Amending longoverdue.pl and pendingreserves.pl could go in another bug report building on this to handle un-allocated holds, just to prevent too much scope creep on this bug report?

It would be great to have some feedback on this so we know what the next steps are. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com Depends on| |9834 --- Comment #31 from Nick Clemens <nick@bywatersolutions.com> --- 9834 allows for manual reversion of hold to take original state of hold (item level vs next available) This should be adapted to use that code, or maybe that fix satisfies the requirements here? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9834 [Bug 9834] Reverting a waiting hold should lead to the former hold type (item or biblio level) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #33 from David Cook <dcook@prosentient.com.au> --- Ran into this problem as it was causing /usr/share/koha/bin/cronjobs/longoverdue.pl to seemingly randomly die when this patch is applied. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81710|0 |1 is obsolete| | Attachment #81711|0 |1 is obsolete| | Attachment #81712|0 |1 is obsolete| | --- Comment #35 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 102334 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102334&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t 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=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Sally <sally.healey@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk Status|Needs Signoff |Patch doesn't apply --- Comment #38 from Sally <sally.healey@cheshiresharedservices.gov.uk> --- Patch doesn't apply. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #102334|0 |1 is obsolete| | --- Comment #39 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 113208 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113208&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t 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=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #102336|0 |1 is obsolete| | --- Comment #41 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 113210 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113210&action=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #113208|0 |1 is obsolete| | --- Comment #42 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 118264 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118264&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t 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=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #113210|0 |1 is obsolete| | --- Comment #44 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 118266 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118266&action=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #118264|0 |1 is obsolete| | --- Comment #45 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 125437 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125437&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t 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=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #118266|0 |1 is obsolete| | --- Comment #47 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 125439 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125439&action=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 --- Comment #49 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Hi Andrew, it seems that bug exists regardless of this new work. I can work on Bug 21729 but waiting on that patch shouldn't hold up the signoff for this enhancement. Thanks -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Felicity Brown <felicity.brown@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felicity.brown@montgomeryco | |untymd.gov --- Comment #51 from Felicity Brown <felicity.brown@montgomerycountymd.gov> --- Does this apply to setting a status to "missing" as well as lost? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #125438|0 |1 is obsolete| | --- Comment #53 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 140215 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140215&action=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold 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=20844 --- Comment #55 from Aleisha Amohia <aleisha@catalyst.net.nz> --- (In reply to Felicity Brown from comment #51)

Does this apply to setting a status to "missing" as well as lost?

The short answer is Yes. The long answer: this uses items.itemlost value in the database to determine if the item is lost. By default, this is usually linked to the LOST authorised value. So, any selected value of LOST (which might be Lost, or Missing, or Long Overdue) will flag items.itemlost in the database as true. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #140215|0 |1 is obsolete| | --- Comment #58 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 150349 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150349&action=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold 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=20844 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #60 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Hi Aleisha, I encountered a few errors while trying to test this patchset. #1 After changing RevertLostBibLevelHolds to "Revert", I get the following error on cataloguing/additem.pl: The method Koha::Items->holds is not covered by tests! Trace begun at /kohadevbox/koha/Koha/Objects.pm line 572 Koha::Objects::AUTOLOAD('Koha::Items=HASH(0x564bf159f540)', 'HASH(0x564bf1743f18)') called at /kohadevbox/koha/cataloguing/additem.pl line 757 eval {...} at /kohadevbox/koha/cataloguing/additem.pl line 2 The error persists even if I change RevertLostBibLevelHolds to "Don't Revert" and restart all. (It does not occur before I change the syspref, and does not persist if I reset all.) --------------------------------------------------------------------------------- #2 I get the following error on moredetail.pl: Can't call method "holds" on an undefined value at /kohadevbox/koha/catalogue/moredetail.pl line 251 The line in question is: $item_info->{waiting_holds} = $item->{object}->holds({ found => [ 'W', 'T' ], item_level_hold => { '!=' => 0 } })->count; I tried replacing "$item->{object}->holds" with "$item->holds" and that seemed to fix it (and had no effect on error #1). --------------------------------------------------------------------------------- #3 Tests don't pass: t/db_dependent/Reserves.t .. "my" variable $item masks earlier declaration in same scope at /kohadevbox/koha/C4/Circulation.pm line 4029. t/db_dependent/Reserves.t .. 24/78 No reserves HOLD_CANCELLATION letter transported by email at /kohadevbox/koha/C4/Letters.pm line 588. t/db_dependent/Reserves.t .. 73/78 # Looks like you planned 17 tests but ran 13. # Failed test 'Waiting item is marked as lost' # at t/db_dependent/Reserves.t line 1563. Can't call method "notice_email_address" on unblessed reference at /kohadevbox/koha/C4/Message.pm line 185. # Looks like your test exited with 11 just after 73. t/db_dependent/Reserves.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 6/78 subtests -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #61 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 150480 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150480&action=edit Bug 20844: (follow-up) Fixes for lists, objects, templates, tests -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Patch doesn't apply --- Comment #63 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- I'd love to see this move forward soon! It needs a minor rebase and fixes for the two issues I noticed the last time I tested, but then I think I'll be able to sign off on it. I was able to fix the first issue locally by making the following change in circulation.pref: - 690 yes: Revert - 691 no: "Don't revert" + 690 1: Revert + 691 0: "Don't revert" The issue was that the code in most places checked the syspref as follows: if ( C4::Context->preference('RevertLostBibLevelHolds') ) which evaluates to true for both "yes" and "no". (The default was put into the database as 0, so the odd behavior only occurs after the pref has been changed.) -------- For the second issue - do moredetail.tt and additem.tt have access to the syspref value in any way? It's not clear to me whether either of the template files is taking the value of the syspref into account when determining whether to display the confirmation alert for handling a lost item-level hold. However, all of the .pl files in the patches perform the actual handling of lost item-level holds inside of a conditional that checks the syspref. I assume the templates should be checking that data somehow as well, so as to display the alert only if the syspref is set to "revert"? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=22221 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #150348|0 |1 is obsolete| | --- Comment #64 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 159062 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159062&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t 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=20844 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #150350|0 |1 is obsolete| | --- Comment #66 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 159064 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159064&action=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 --- Comment #68 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 159111 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159111&action=edit Bug 20844: (follow-up) Fix alert boxes for item-level holds Fix styling on the alert in additem.tt Don't show alert in moredetail page if RevertBibLevelHolds is disabled -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #70 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- *** Bug 30208 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #159062|0 |1 is obsolete| | --- Comment #71 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 170263 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170263&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Test SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Test with transferred holds To test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #159063|0 |1 is obsolete| | Attachment #159064|0 |1 is obsolete| | Attachment #159065|0 |1 is obsolete| | Attachment #159111|0 |1 is obsolete| | Attachment #170263|0 |1 is obsolete| | --- Comment #72 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 170264 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170264&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Test SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Test with transferred holds To test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hdunne-howrie@westminster.g | |ov.uk --- Comment #73 from Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> --- We would like to see this functionality as well as this is something we used to have in our old library system before switching to Koha. In addition to seeing this trigger for when the reserves.found = W, we would want to see this for reserves.found = T as well as we are seeing a problem in which items are lost while on transit to satisfy a hold. Additionally, as well as the trigger being on in the value is not 0 on items.itemlost, we would also want to see the option for this to be if not 0 on damaged, notforloan or withdrawn for any reserves.found IN ('W','T'). It would be great to see see as a configurable preference so libraries could set what is included in the trigger. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #170264|0 |1 is obsolete| | --- Comment #74 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 189623 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189623&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Test SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Test with transferred holds To test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #77 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Updated but not tested yet ;-) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #79 from Chris Cormack <chris@bigballofwax.co.nz> --- Automatic patch test results: â ï¸ The patch applies with fuzzy option (ignoring whitespace). This may indicate minor conflicts that need to be resolved. Details: Patch applies with fuzzy option (ignoring whitespace) This is an automated message from the patch testing system. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #81 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- (In reply to Nick Clemens (kidclamp) from comment #80) This alll

Test SendLostHoldNotices 8) Confirm notice enqueues as expected for a bib-level hold

I do not get a notice when marking the item lost and reverting a bib-level hold. I did get a notice with an item-level hold.

Test with transferred holds To test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold

With an in-transit item I again did not get a notice for a bib-level hold, did get one for an item-level hold. But why send this notice at all? If the item is in-transit for fill a hold, the patron has not yet been notified that the item is ready for pickup. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aleisha@catalyst.net.nz |nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #84 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- (In reply to Andrew Fuerste-Henry from comment #81)

(In reply to Nick Clemens (kidclamp) from comment #80)

This alll

...

Test SendLostHoldNotices 8) Confirm notice enqueues as expected for a bib-level hold

I do not get a notice when marking the item lost and reverting a bib-level hold. I did get a notice with an item-level hold.

It works for me

...

Test with transferred holds With an in-transit item I again did not get a notice for a bib-level hold, did get one for an item-level hold. But why send this notice at all? If the item is in-transit for fill a hold, the patron has not yet been notified that the item is ready for pickup.

I think we are erring on the side of caution here - it can be likely that if an item is lost there may not be another to fill the hold, so having them check in with the library is desired -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #189648|0 |1 is obsolete| | Attachment #189688|0 |1 is obsolete| | Attachment #189973|0 |1 is obsolete| | --- Comment #85 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 191958 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191958&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Test SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Test with transferred holds To test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 --- Comment #87 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 191960 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191960&action=edit Bug 20844: (follow-up) Address moredetail.tt as well -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #89 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 191966 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191966&action=edit Bug 20844: Prevent double notices and ensure notice sent from additem.pl for additem.pl we need to mark the item as lost before we call lost item To prevent double messages we don't send a notice when cancelling or reverting an item level hold, we send on the initial mark lost -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191958|0 |1 is obsolete| | --- Comment #90 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 191981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191981&action=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Test SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Test with transferred holds To test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold 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=20844 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191960|0 |1 is obsolete| | --- Comment #92 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 191983 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191983&action=edit Bug 20844: (follow-up) Address moredetail.tt as well -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #94 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- The implementation of patron messaging here needs work. The notice this enhancement creates generates as soon as the item is marked lost, before the staff member indicates whether the hold should be reverted or cancelled. As such, the notice cannot tell the patron specifically what happened to their hold. Additionally, the same notice sends when an item in-transit to fill a hold is marked lost. This is confusing as the notice says "Your hold awaiting pickup is no longer available." but when an item is in-transit Koha has not yet sent a hold waiting notification. This feature should be reworked such that the library can create and assign a hold_cancellation reason to be applied when a hold is cancelled due to a lost item, both when the hold is waiting and when the hold is in-transit. That will generate the existing Hold Cancellation notice, which can be customized to specify to the patron why the hold was cancelled. We should implement a new notice to be sent to the patron when a hold's waiting status is reverted. We should not send a notice to the patron when their in-transit hold is reverted. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191981|0 |1 is obsolete| | Attachment #191982|0 |1 is obsolete| | Attachment #191983|0 |1 is obsolete| | Attachment #191984|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=20844 --- Comment #96 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198369 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198369&action=edit Bug 20844: (follow-up) Use js form submit and add cud- ops Patch from commit 41e6bbb -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #98 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198371 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198371&action=edit Bug 20844: Prevent double notices and ensure notice sent from additem.pl for additem.pl we need to mark the item as lost before we call lost item To prevent double messages we don't send a notice when cancelling or reverting an item level hold, we send on the initial mark lost -- You are receiving this mail because: You are watching all bug changes.