https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34024 --- Comment #7 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Emily Lamancusa from comment #6)
I'm not sure which API endpoint Aspen uses, so it's very possible I used the wrong one in my steps to reproduce (my current understanding of the API doesn't go very far beyond looking up an endpoint at https://api.koha-community.org/ and sending a query to KTD by command line). My concern is indeed the Aspen behavior, though, so please double-check me if I have the wrong endpoint!
My main point was that the fix here shouldn't block changing the pickup location on an in-transit hold entirely, but rather should be consistent with the OPAC setting, so that Koha/Aspen libraries (or, presumably, libraries with other discovery layers?) can still use the feature.
I asked about Aspen in particular because I know it connects to Koha as a privileged user (as opposed to doing it with the patron's credentials). So, as a general rule, such system will be using a privileged set of endpoints and needs the right permissions. And the endpoint's behavior should respect the permissions/configurations limitations the UI has for such permissions/configurations. I've read holds_table.inc lines 134-161, to identify what's the underlying logic for (not) allowing the pickup location change (on the staff interface). And that's what my patch implements at this time. As I mention on the commit message: we can add 'overrides' to some situations, with a more evolved design. But, as you said, the current implementation leaves Koha in unhandled situations that need to be avoided. Best regards -- You are receiving this mail because: You are watching all bug changes.