|
Description
Hugh Rundle
2018-05-31 07:07:48 UTC
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. (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. Created attachment 79267 [details] [review] 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 Sponsored-By: Brimbank Library, Australia Any chance we can move this one along with testing? This seems to be working perfectly except for one thing: I can't cancel a hold from the add item screen. I get an error, Can't call method "cancel" on an undefined value at /home/vagrant/kohaclone/cataloguing/additem.pl line 741. The patch does need to be fixed up according to QA tool warnings. Created attachment 80760 [details] [review] 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 Sponsored-By: Brimbank Library, Australia Created attachment 80761 [details] [review] 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 Hi Owen Thanks for testing. I have corrected the commit message in the first patch, and have just attached a second path which corrects the issue you saw trying to cancel a hold on the cataloguing/additem.pl interface. This second patch also corrects the qa warning on C4/Circulation.pm Can you please test again? Cheers, Alex Created attachment 80890 [details] [review] 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 Created attachment 80891 [details] [review] 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 Hi all I've added unit tests for the two new subroutines I added to C4/Reserves.pm which were RevertWaitingStatus() and RevertItemLevelHoldToBibLevelHold(). Also all three patches pass the QA test tool now. Hi, on kohadevbox I get: kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ prove t/db_dependent/Holds/RevertWaitingStatus.t t/db_dependent/Holds/RevertWaitingStatus.t .. DBD::mysql::st execute failed: Unknown column 'originalholdtype' in 'field list' [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `expirationdate`, `found`, `itemnumber`, `itemtype`, `originalholdtype`, `priority`, `reservedate`, `reservenotes`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0='439', 1='53', 2='YbGPVdI', 3=undef, 4=undef, 5=undef, 6=undef, 7='B', 8=undef, 9='2018-10-19', 10='', 11=undef] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. Can't locate object method "rethrow" via package "DBD::mysql::st execute failed: Unknown column 'originalholdtype' in 'field list' [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `expirationdate`, `found`, `itemnumber`, `itemtype`, `originalholdtype`, `priority`, `reservedate`, `reservenotes`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0='439', 1='53', 2='YbGPVdI', 3=undef, 4=undef, 5=undef, 6=undef, 7='B', 8=undef, 9='2018-10-19', 10='', 11=undef] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. " (perhaps you forgot to load "DBD::mysql::st execute failed: Unknown column 'originalholdtype' in 'field list' [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `expirationdate`, `found`, `itemnumber`, `itemtype`, `originalholdtype`, `priority`, `reservedate`, `reservenotes`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0='439', 1='53', 2='YbGPVdI', 3=undef, 4=undef, 5=undef, 6=undef, 7='B', 8=undef, 9='2018-10-19', 10='', 11=undef] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. "?) at /home/vagrant/kohaclone/Koha/Object.pm line 148. # Looks like your test exited with 11 before it could output anything. t/db_dependent/Holds/RevertWaitingStatus.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 12/12 subtests Created attachment 81045 [details] [review] 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 Hi Michael Thanks for testing. Can you please try testing now using the test plan in the patch I have just attached. Apologies that should be 'Hi Michal' With the feature freeze coming up very soon are we able to get this moving along with testing? Created attachment 81531 [details] [review] 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 Created attachment 81623 [details] [review] 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> Created attachment 81624 [details] [review] 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. Created attachment 81640 [details] [review] 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> Thanks Owen for testing my patch I have tested your follow-up and the dialogs look correct so I have signed off on it. Created attachment 81697 [details] [review] 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> Created attachment 81698 [details] [review] 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> 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. Created attachment 81710 [details] [review] 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> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 81711 [details] [review] 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> Created attachment 81712 [details] [review] Bug 20884: (QA follow-up) Remove Data::Dumper Signed-off-by: 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. 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 (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. 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? Comment on attachment 81710 [details] [review] Bug 20844: Revert hold when setting an item to lost Review of attachment 81710 [details] [review]: ----------------------------------------------------------------- ::: C4/Circulation.pm @@ +3688,5 @@ > + my $LostItemLevelHold; > + if ( $restype eq "Waiting" || $restype eq "Reserved" ) { > + if ( $res->{originalholdtype} eq "B" ) { > + #originalholdtype equalling "B" means this is a bib level hold > + C4::Reserves::RevertWaitingStatus({itemnumber => $itemnumber}); This line appears to be buggy. I haven't fully investigated, but if the hold type is B, the itemnumber can't be used to look up the reserve, and eventually causes a fatal error in _FixPriority (due to a lack of error handling in RevertWaitingStatus, _FixPriority, etc.) Ran into this problem as it was causing /usr/share/koha/bin/cronjobs/longoverdue.pl to seemingly randomly die when this patch is applied. The code has moved on a bit since these patches were originally written. Will see if I can revive. Created attachment 102334 [details] [review] 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 Created attachment 102335 [details] [review] 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 Created attachment 102336 [details] [review] 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 Patch doesn't apply. Created attachment 113208 [details] [review] 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 Created attachment 113209 [details] [review] 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 Created attachment 113210 [details] [review] 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 Created attachment 118264 [details] [review] 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 Created attachment 118265 [details] [review] 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 Created attachment 118266 [details] [review] 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 Created attachment 125437 [details] [review] 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 Created attachment 125438 [details] [review] 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 Created attachment 125439 [details] [review] 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 On initial testing, this technically works, but is severely hampered by bug 21729 -- when a hold goes to Waiting, the expiration date is set based on ReservesMaxPickUpDelay. When the hold is reverted, that expiration date remains. Without patching 21729, this feature will leave most libraries with a bunch of bib-level holds that expire within a week or so. 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 (In reply to Aleisha Amohia from comment #49) > 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're absolutely correct! I didn't add 21729 as a blocker here as it doesn't technically break this feature. Does this apply to setting a status to "missing" as well as lost? Created attachment 140214 [details] [review] 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 Created attachment 140215 [details] [review] 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 Created attachment 140216 [details] [review] 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 (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. Patch doesn't apply Merge conflicts in: koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/moredetail.tt koha-tmpl/intranet-tmpl/prog/en/modules/admin/prefrences/circulation.pref catalogue/moredetail.pl Created attachment 150348 [details] [review] 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 Created attachment 150349 [details] [review] 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 Created attachment 150350 [details] [review] 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 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
Created attachment 150480 [details] [review] Bug 20844: (follow-up) Fixes for lists, objects, templates, tests The majority of the test plan works - just a few more bugs to be worked out:
- If RevertLostBibLevelHolds is set to "Revert" and later switched back to "Don't Revert", the holds continue to automatically revert even after the syspref is disabled. And yes, I did double-check that I actually clicked "Save" and that the syspref was still set to "Don't Revert" if I navigated away from the System Preferences page and then back ;)
- When RevertLostBibLevelHolds is disabled, if a waiting item on an item-level hold is marked as lost, the alert asking whether to revert or cancel the hold still appears, but the "Revert" and "Cancel" buttons have no effect.
In combination with the previous bug, the effect is this:
* If RevertLostBibLevelHolds has never been enabled, the effect just
described occurs.
* If RevertLostBibLevelHolds was enabled and then disabled, the alert
appears and the buttons revert/cancel the hold, as would be expected if
the pref was still enabled
A thought: the preference is called RevertLostBibLevelHolds, but if I'm understanding correctly it affects the behavior of both bib level and item level holds. It seems to me that it could more accurately be called RevertLostHolds, and maybe add a note to the description explaining that item-level holds will ask whether they should be reverted or cancelled.
Finally, I just want to clarify something from the test plan:
> 41) Confirm that both Items are included in the alert box on page when
> editing items (cataloguing/additem.pl)
As far as I know, additem.pl can only edit one item at a time - is there a way to edit two at once from that page? (When I edited them one at a time they each got an alert as expected, so may not be an issue - just wanted to check.)
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"?
Created attachment 159062 [details] [review] 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 Created attachment 159063 [details] [review] 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 Created attachment 159064 [details] [review] 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 Created attachment 159065 [details] [review] Bug 20844: (follow-up) Fixes for lists, objects, templates, tests Created attachment 159111 [details] [review] 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 Thanks for the fixes!
I added a follow-up with a couple of trivial fixes to the alerts. :)
The notice is sent twice when reverting or cancelling an item-level hold from the prompt (sorry for missing that the last time I tested). Is there a reason LostItem needs to be called a second time when the user responds to the prompt of whether to revert or cancel an item-level hold? Couldn't the prompt cancel/revert the hold directly at that point, and avoid re-doing all the lost item processing (including the second notice)?
Also, tests are failing:
# Subtest: Waiting item is marked as lost
1..17
ok 1 - Biblio-level hold placed
not ok 70 - Waiting item is marked as lost
# Looks like you planned 17 tests but ran 1.
# Failed test 'Waiting item is marked as lost'
# at t/db_dependent/Reserves.t line 1546.
Can't call method "effective_itemtype" on an undefined value at /kohadevbox/koha/Koha/Hold.pm line 234.
# Looks like your test exited with 11 just after 70.
Dubious, test returned 11 (wstat 2816, 0xb00)
Failed 9/78 subtests
*** Bug 30208 has been marked as a duplicate of this bug. *** Created attachment 170263 [details] [review] 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 Created attachment 170264 [details] [review] 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 |