https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36024 Bug ID: 36024 Summary: Cancellation requests for waiting holds - errors caused by duplicate requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: emily.lamancusa@montgomerycountymd.gov QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com The Koha OPAC prevents duplicate waiting hold cancellation requests at the interface level, but if a duplicate request is sent through the API (e.g. from a discovery layer), it is not prevented. This causes the cancellation request to display twice on the Holds With Cancellation Requests table on the staff interface. When the item is checked in, the cancellation request and checkin logic are (at least partially) processed, but the page displays a 500 error, which is confusing to staff and prevents any modals from displaying. To reproduce on KTD: 1. Circulation Rules: add a Default waiting hold cancellation policy of all / all / yes (i.e. cancellation allowed for all patron categories and item types) 2. System preferences: Enable RESTBasicAuth 3. Place a hold and check the item in to set the hold to Waiting 4. In a kshell, send an API hold cancellation request from the command line: curl -u koha:koha --request DELETE 'http://127.0.0.1:8081/api/v1/holds/1' --header "Content-type: application/json" --header "x-koha-override: cancellation-request-flow" (if the hold ID is not 1, change the hold ID at the end of the request path accordingly) 5. Repeat step 4 6. Go to the Holds Waiting page and view the Holds With Cancellation Requests tab --> Note that two identical cancellation requests appear for that hold 7. Check in the item --> Note the error message 8. Confirm that the item state has been modified: --> Hold is gone from the Holds Waiting page --> Hold is gone from the bib record --> Item shows as available on the bib record and last seen date has been updated --> If RecordLocalUseOnReturn is enabled, a local use entry has been added to the statistics table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.