https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17268
--- Comment #83 from Agustín Moyano <[email protected]> --- (In reply to Tomás Cohen Arazi from comment #80) > (In reply to Jonathan Druart from comment #76) > > (In reply to Tomás Cohen Arazi from comment #74) > > > The fact it relies on the API should be a good thing for everyone, no one > > > wants to add new CGI controller scripts that can only be tested with > > > selenium :-D > > > > The problem is having all the logic in Koha::REST, how do you do if you want > > to reuse this code outside of a REST API call? > > > Well, we try not to do that. In this case there's really no business logic > besides permission checking, which we traditionally do in the controllers. First of all, really great work Nick! * About the endpoint path, if we are talking about patron's macros, I believe it would make more sense to have something like GET /api/v1/patrons/{patron_id}/advancededitormacros GET /api/v1/patrons/{patron_id}/advancededitormacros/{advancededitormacro_id} etc... Meaning patron_id should be in the path * An idea for having OR conditions for resources access is to have it specified in x-koha-authorization, for example "x-koha-authorization": { "permissions": { "editcatalogue": "advanced_editor" }, "or-condition": { "shared": 1 } } and have object.search build that dbic query whit the patron_id it founds in the path.. permissions will always be checked before this in Auth.pm. Regards -- 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/
