[Koha-bugs] [Bug 18729] Librarian unable to update hold pickup library from patron pages without "modify_holds_priority" permission

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

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

Tomás Cohen Arazi <tomascohen at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick at bywatersolutions.com

--- Comment #19 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
Hi, I'd like to mention that:

- The idea of having a route to change the pickup location *only*, was meant so
we could have a more granular permission set. So I expect this route to require
something like "reserveforothers": "modify_pickup_location". That permission
should be set on an atomicupdate to all users having place_holds, as per bug
27117.

- I liked the idea of calling them 'pickup locations' instead of the already
used 'pickup_library' (see the hold objects definition). I like the fact that
we prepare for some future in which there could be other pickup locations
(shelves?  special lockers for sanitized materials on this new world?). With
this in mind, I have two other comments to make:

- The PUT verb is accepting (and returning) a string, that actually represents
what we already call pickup_library_id, but named generically 'pickup
location'. I suggest we drop this and in turn expect a JSON object, with a
'pickup_library_id' attribute, replicating the already used terminology. It
will also allow us to add new options for the future.

- I regret not proposing this before, but we should really have a class
abstracting pickup locations, that could initially just be a wrapper for
libraries, but with a ->to_api method that makes it return the
pickup_library_id and the name. If we need more things, we can solve that
through embedding (e.g. embed the library object altogether). This will allow
us to have simpler routes for dropdowns (right now we should take care of
'private' attributes for such dropdowns in the OPAC, for example).

About this last comment, I haven't polished the idea. But the main message is
'do not put any design constraint ourselves at this point'. And I'm willing to
have the full discussion when appropriate.

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