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.