[Bug 43953] New: Holds API PATCH ignores AllowHoldDateInFuture when changing hold_date
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43953 Bug ID: 43953 Summary: Holds API PATCH ignores AllowHoldDateInFuture when changing hold_date Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: tomascohen@gmail.com CC: tomascohen@gmail.com Target Milestone: --- Creating a hold through the REST API refuses a hold_date when the AllowHoldDateInFuture system preference is off (Koha::REST::V1::Holds::add returns 400 "Hold date in future not allowed"). Changing the hold date of an existing hold through PATCH /api/v1/holds/{hold_id} (Koha::REST::V1::Holds::edit) has no such check: hold_date is passed straight to C4::Reserves::ModReserve. Since Bug 23269 the staff holds table (reserve/request.pl) saves each field as soon as it is changed using this PATCH endpoint. The hold date input is only shown when AllowHoldDateInFuture is on, so the interface hides the field, but nothing stops the same request being made by a script or another API client when the preference is off. Expected: PATCH should apply the same rule as POST and reject a changed hold_date with a 400 when AllowHoldDateInFuture is off. A hold_date that is unchanged (the client sends back the existing value) should still be accepted. To test: 1. Set AllowHoldDateInFuture to "Don't allow". 2. Find an existing hold, then send PATCH /api/v1/holds/<id> with {"hold_date": "2030-01-01"} (a user with the place_holds permission). 3. Note the request succeeds and the hold's reservedate changes. 4. Compare with POST /api/v1/holds with a hold_date, which returns 400. Expected after the fix: step 3 returns 400 and the hold is unchanged. Related: Bug 23269. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43953 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 210031 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=210031&action=edit Bug 43953: Holds API PATCH ignores AllowHoldDateInFuture when changing hold_date POST /api/v1/holds refuses a hold_date when AllowHoldDateInFuture is off, but PATCH/PUT /api/v1/holds/{hold_id} passed a changed hold_date straight to ModReserve. The staff holds table hides the hold date input when the preference is off, but the API did not enforce it. Return a 400 from edit() when the hold date would change and AllowHoldDateInFuture is off. Sending back the existing hold date is still accepted, so clients that send the whole object keep working. To test: 1. Set AllowHoldDateInFuture to "Don't allow" 2. prove t/db_dependent/api/v1/holds.t => FAIL without the patch, in the edit() tests 3. Apply the patch and run the test again => SUCCESS 4. Optionally, send PATCH /api/v1/holds/<id> with {"hold_date": "2030-01-01"} as a user with place_holds: a 400 is returned and the hold is unchanged. Turn the preference on and the same request succeeds. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43953 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43953 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #2 from David Nind <david@davidnind.com> --- I could not reproduce the failing tests before applying the patch (step 1 of the test plan) - doesn't matter what AllowHoldDateInFuture is set to. The tests pass for me both before and after the patches. Testing notes (using KTD): 1. The default for AllowHoldDateInFuture in KTD is "Don't allow". 2. After applying the patch, not sure if I needed to rebuild everything but did anyway: yarn build and a restart_all 3. Optional step 4: - I gave Henry Acevedo catalogue and place_holds permissions - Using this SQL I got the hold ID: . Access the database: koha-mysql kohadev . SQL: select * from reserves; - Before the patch, using Bruno to make the request, I got a 403 forbidden error unless I give all the "Place and modify holds for patrons (reserveforothers)" permissions. - Before the patch, if I give Henry borrowers permissions, then I can change the hold date with AllowHoldDateInFuture set to both "Don't allow" and "Allow" - After the patch, with Henry having borrowers permissions, things now work as expected: . With AllowHoldDateInFuture set to "Don't allow" - 400 Bad Request error: { "error": "Hold date in future not allowed" } . With AllowHoldDateInFuture set to "Allow", the request succeeds (200 OK). -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org