https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34024
--- Comment #7 from Tomás Cohen Arazi <tomasco...@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. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/