https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43954 Bug ID: 43954 Summary: Add a permission to control editing of hold dates in the holds table Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, lisette@bywatersolutions.com, tomascohen@gmail.com Target Milestone: --- Since Bug 23269 the holds table on reserve/request.pl saves each field as soon as it is changed, using PATCH /api/v1/holds/{hold_id}. Before that, the fields were edited in a form and only saved when the "Update hold(s)" button was clicked. Staff who can place holds (reserveforothers: place_holds) can therefore change the hold date, the expiration date and the pickup library of any hold in the table with a single click on a date picker, and the change is saved immediately. There is no way for a library to let some staff do this and not others, or to stop it for everyone: - The hold date input is shown whenever AllowHoldDateInFuture is on. There is no permission for it. - The expiration date input is always shown. - The API PATCH only needs place_holds, whatever fields are sent. (Bug 43953 makes the API respect AllowHoldDateInFuture for hold_date.) Libraries have reported that the date of a hold (date placed) is something staff should not normally change, as it affects the order of the holds queue, and that with saving on change it is now easy to alter by accident. Proposal: add a new sub-permission under reserveforothers (as alter_hold_targets was added by Bug 31698), for example modify_hold_dates, "Modify the dates of holds". - On reserve/request.pl, and on the patron holds table which uses the same code, show the hold date (and optionally the expiration date) as plain text unless the user has the permission. - In PATCH /api/v1/holds/{hold_id}, return 403 if the request changes hold_date and the user does not have the permission. Sending back the existing value stays allowed. - Existing users who have place_holds keep their current behaviour on upgrade (the atomic update grants the new permission to users who have reserveforothers or place_holds), so nothing changes until a library chooses to remove it. Open questions: - Should the permission cover only the hold date, or the expiration date too? Staff often adjust expiration dates, so a single permission for both may be too wide. Two permissions are also possible. - Should it apply to the pickup library as well? Related: Bug 23269 (introduced saving on change), Bug 43953 (API check for AllowHoldDateInFuture). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.