https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34024 --- Comment #10 from Emily Lamancusa <emily.lamancusa@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.