[Koha-bugs] [Bug 34024] REST API should not allow changing the pickup location on found holds

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34024

--- Comment #10 from Emily Lamancusa <emily.lamancusa at montgomerycountymd.gov> ---
Is changing the pickup location on a hold that's in transit truly an unhandled
situation? 

Looking at bug 30500 and bug 14783, if the syspref is set to allow it,
opac-modrequest.pl calls $hold->set_pickup_location without extra handling,
because AddReturn already has logic to handle a situation where a transfer
completes and a new transfer needs to be initiated based on hold pickup
location. 

It's true the functionality to directly change the pickup location on an
in-transit hold wasn't added to the staff interface when it was added to the
OPAC, but is there a practical reason it shouldn't be permitted, or more just
that there hasn't been a need to add it yet (in part because staff have the
capability to revert the transit status on a hold in order to make those types
of changes, while the OPAC and API do not)?

I'm not sure I fully understand the implications of a privileged API endpoint
being able to change the pickup location on an in-transit hold, versus allowing
the OPAC to do it, versus allowing a person in the staff interface to revert
the transit status, change the pickup location, and then put the hold back in
transit. (though actually I'd say the existing behavior allowing a staff member
to mess with transit data as a workaround is riskier than adding the ability
for them to change the pickup location directly, but that's beyond the scope of
this bug) If there's a true risk to allowing the API to change the pickup
location on an in-transit hold without an override, then it makes sense to be
cautious. But if that's the case, please open a follow-up bug to add such an
override route and restore the functionality.

-- 
You are receiving this mail because:
You are watching all bug changes.