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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected], [email protected],
[email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
