https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17390
Tomás Cohen Arazi <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #10 from Tomás Cohen Arazi <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] 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/
