| Summary: | Transfer/next hold modals not triggered automatically when cancelling a hold by checking item in | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Heather Rommens <heather> |
| Component: | Circulation | Assignee: | Kyle M Hall (khall) <kyle> |
| Status: | Needs documenting --- | QA Contact: | Emily Lamancusa (emlam) <emily.lamancusa> |
| Severity: | major | ||
| Priority: | P5 - low | CC: | andrew, david, emily.lamancusa, fridolin.somers, gmcharlt, holly, kebliss, kyle.m.hall, kyle, lucas, sbrown |
| Version: | Main | Keywords: | RM_priority |
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: |
This fixes an issue when checking in an item to cancel a waiting hold - if a transfer to the originating library is required, the pop-up window notifying that a transfer is required was not automatically generated. (This is related to the CSRF changes added in Koha 24.05 to improve form security.)
|
Version(s) released in: |
24.11.00,24.05.02
|
| Circulation function: | |||
| Bug Depends on: | |||
| Bug Blocks: | 36192 | ||
| Attachments: |
Bug 37385: Transfer not triggered automatically when cancelling a hold by checking item in (edit)
Bug 37385: Transfer not triggered automatically when cancelling a hold by checking item in (edit) Bug 37385: Fix Transfer not triggering automatically when cancelling a hold by checking in an item Bug 37385: Fix Transfer not triggering automatically when cancelling a hold by checking in an item |
||
|
Description
Heather Rommens
2024-07-16 20:58:36 UTC
Created attachment 169132 [details] [review] Bug 37385: Transfer not triggered automatically when cancelling a hold by checking item in (edit) Upadates for CSRF are inadvertently stopping AddReturn from being trigger when a hold is canceled. This is necessary to generate the transfer back to the originating library. Test Plan: 1) Find item with a waiting hold, and check it in 2) In the popup notifying me of the waiting hold, select 'Cancel hold' 3) Note no second popup appears notifying you of the need to transfer the item to its home library 4) Apply this patch 5) Restart all the things! 6) Repeat steps 1-2 7) Second popup appears! Created attachment 169134 [details] [review] Bug 37385: Transfer not triggered automatically when cancelling a hold by checking item in (edit) Upadates for CSRF are inadvertently stopping AddReturn from being trigger when a hold is canceled. This is necessary to generate the transfer back to the originating library. Test Plan: 1) Find item with a waiting hold, and check it in 2) In the popup notifying me of the waiting hold, select 'Cancel hold' 3) Note no second popup appears notifying you of the need to transfer the item to its home library 4) Apply this patch 5) Restart all the things! 6) Repeat steps 1-2 7) Second popup appears! Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> This fix also fixes a similar issue reported in Bug 37347. I have changed this bug title to reflect that and will resolve 37347 as a duplicate of this one. Thank you, Kyle! *** Bug 37347 has been marked as a duplicate of this bug. *** Created attachment 169161 [details] [review] Bug 37385: Fix Transfer not triggering automatically when cancelling a hold by checking in an item Upadates for CSRF are inadvertently stopping AddReturn from being trigger when a hold is canceled. This is necessary to generate the transfer back to the originating library. Test Plan: 1) Find item with a waiting hold, and check it in 2) In the popup notifying me of the waiting hold, select 'Cancel hold' 3) Note no second popup appears notifying you of the need to transfer the item to its home library 4) Apply this patch 5) Restart all the things! 6) Repeat steps 1-2 7) Second popup appears! Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Created attachment 169166 [details] [review] Bug 37385: Fix Transfer not triggering automatically when cancelling a hold by checking in an item Upadates for CSRF are inadvertently stopping AddReturn from being trigger when a hold is canceled. This is necessary to generate the transfer back to the originating library. Test Plan: 1) Find item with a waiting hold, and check it in 2) In the popup notifying me of the waiting hold, select 'Cancel hold' 3) Note no second popup appears notifying you of the need to transfer the item to its home library 4) Apply this patch 5) Restart all the things! 6) Repeat steps 1-2 7) Second popup appears! Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> The patch makes sense and fixes the regression, and QA tool passes. Passing QA As a side note, I don't love that we call AddReturn again to initiate the next action after canceling a hold. At the very least, in inflates the local use count if RecordLocalUseOnReturn is on - not sure if it introduces other side effects in that situation as well. That's a separate issue that has been there for a while, though. Thanks for all the hard work! Pushed to main for the next 24.11.00 release as RM Assistant Backported to 24.05.x for upcoming 24.05.02 Full CSRF not in 23.11.x |