[Koha-bugs] [Bug 17314] REST API: Add API route to create, list and delete a purchase suggestion

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

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

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

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

--- Comment #34 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
Hi all, since this got written we made some design decisions that affect this
patches. They are easy to address, though :-D

- Request validation is done using the spec, by Mojolicious::Plugin::OpenAPI
- We decided not to mix 'public' endpoints (that don't require privileged
access) from the ones restricted to privileged access users.
- The above decision implies that endpoints that have 'allow_owner' or
'allow_guarantor' permissions, need to be separated, and moved to /public. In
this case, I'd say:

GET /public/patrons/:patron_id/suggestions <- list of suggestions
POST /public/patrons/:patron_id/suggestions { object with required attributes }
<- add

This change should simplify the logic inside the controller (i.e. a separate
controller method for the public one)

I haven't checked if we allow cancelling a request and in which cases it
is/should be allowed. In that case a DELETE verb could be allowed in the
/public namespace.

- Using C4::Context::user_env is forbidden here. It relies on Cookie auth,
which is not obvious to assume is the case (we have several auth mechanisms for
the API). So you have two options: (a) make the parameter mandatory (why not?
and just return 400 bad request) or (b) use the stashed Koha::Patron object
(i.e. the one guessed from the authentication mechanism, accessible through
$c->stash('koha.user') (yes, it is the Koha::Patron object for the patron that
was granted the access). Keep in mind this use case: do we allow anonymous
purchase suggestions? Only authenticated users get the Koha::Patron stashed of
course :-D

- This should be better handled by the separation of concerns (public vs
privileged), and relaying on the spec for validation:
+            unless (any { /^$param$/ } @allowed_fields) {
+                # Ouch ! User trying to edit field he has no rights to edit!

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