[Koha-bugs] [Bug 17390] Add REST API endpoint for Authorised Values

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |Failed QA

--- Comment #10 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
I see a design issue on this route. As authorised values belong to auth val
categories, we should really have that in the path:

POST /authorised_value_categories
GET  /authorised_value_categories
GET  /authorised_value_categories/:authorised_value_category_id
POST /authorised_value_categories/:authorised_value_category_id/values
GET  /authorised_value_categories/:authorised_value_category_id/values

if this routes would be used for CRUD operations we should probably contemplate
the idea of embedding the library limits on the response using x-koha-embed
(i.e. if you are going to edit an authorised value in a form, you will want the
library limits, and also some information about the category for rendering
purposes.

Usability and controller implementation:
If you are going to use the routes only for rendering a dropdown somewhere,
that form will have the field probably mapped to a specific auth val category.
In that case you would be doing:

GET /authorised_values?authorised_value_category_id=XX

but the controller would not be as simple as the patch suggests, as it should
consider library limits to start with. And as this is a general-purpose route,
we cannot put constraints on what can be passed on the query parameters or even
q=, and adding library limits to the combo, makes it a nightmare to implement,
with really no need.

And there's also permissions...

Lets fix it by design: if we want to have (still need to figure the use case) a
global search route for auth values, then make it require the the highest
possible permissions and implement no restrictions on it. Or skip that route
and implement:

a. POST /authorised_value_categories
b. GET  /authorised_value_categories
c. GET  /authorised_value_categories/:authorised_value_category_id
d. PUT  /authorised_value_categories/:authorised_value_category_id
e. DELETE /authorised_value_categories/:authorised_value_category_id
f. POST /authorised_value_categories/:authorised_value_category_id/values
g. GET  /authorised_value_categories/:authorised_value_category_id/values
h. GET 
/authorised_value_categories/:authorised_value_category_id/values/:authorised_value_id
i. DELETE
/authorised_value_categories/:authorised_value_category_id/values/:authorised_value_id

Then on bug 25728 you would use:
(g) for fetching the list
(f) for adding a new value

and the controller for (g) will just call
Koha::AuthorisedValues->search_with_library_limits using the
:authorised_value_category_id and passing the library_id that is read from then
stashed user. Unless it is a superlibrarian, in which case the resultset to be
passed to $c->objects->search would just be a regular ->search.

Those routes, can then have more granular permissions requirements than a
global one which would also be a nightmare to implement.

I hope it makes sense.

On of the things to consider, is just implementing the routes you need (i.e.
not all of them). That way you don't get dragged into a rabbit hole.

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