https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|REST API: Add POST route |REST API: Add POST route |for updating |for adding to |notices/message queue |notices/message queue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #1 from Shi Yao Wang <shi-yao.wang@inLibro.com> --- Created attachment 198650 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198650&action=edit Bug 39199: Add POST/GET route for notices/message queue Added api routes for list, get and add Test plan: 1- prove t/db_dependent/api/v1/notices.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- I'm not sure about some of this naming. I often think of a "notice" as the notice template rather than the notice message. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #3 from Shi Yao Wang <shi-yao.wang@inLibro.com> --- Created attachment 198668 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198668&action=edit Bug 39199: Add POST/GET route for notices/message queue Added api routes for list, get and add Test plan: 1- prove t/db_dependent/api/v1/notices.t -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Shi Yao Wang from comment #4)

I just added missing nullable fields on the definition.

(In reply to David Cook from comment #2)

...

I'm not sure about some of this naming. I often think of a "notice" as the notice template rather than the notice message.

What do you prefer the naming to be?

I'm not sure. Maybe the naming is OK. But I don't think the permissions in api/v1/swagger/paths/notices.yaml necessarily make sense. GET /notices requires all "tools" subpermissions. POST /notices requires only "tools > edit_notices" subpermission, so to add outbound email all you need to be able to do is edit notices. That can't be right. GET /notices/{message_id} requires all "tools" subpermissions -- We need to keep in mind that the API runs on the same domain as the OPAC and the staff interface. By adding GET /notices we've suddenly opened up all the emails to a user with the tools subpermissions, so they can look at all kinds of different user information. We've got some pretty fundamental authorization problems in Koha, especially with the API. We bypass our own permissions/authorizations. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #7 from Shi Yao Wang <shi-yao.wang@inLibro.com> --- What would be the appropriate permission or set of permissions for each route then? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #9 from Shi Yao Wang <shi-yao.wang@inLibro.com> --- (In reply to David Cook from comment #8)

@Shi Yao Wang, is your intention here to just allow an API user to view and send emails arbitrarily? I don't think there's a scenario where that's going to be a good idea. If you have a more specific scenario, I'd be happy to provide some advice.

Actually my initial intention was to just implement a GET route for notices to display similarly to koha/members/notices.pl This bug was the closest thing I could find and I thought adding a POST route as well wasn't too complicated. Should I open a separate bug for the GET route only? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Shi Yao Wang from comment #9)

(In reply to David Cook from comment #8)

...

@Shi Yao Wang, is your intention here to just allow an API user to view and send emails arbitrarily? I don't think there's a scenario where that's going to be a good idea. If you have a more specific scenario, I'd be happy to provide some advice.

Actually my initial intention was to just implement a GET route for notices to display similarly to koha/members/notices.pl

This bug was the closest thing I could find and I thought adding a POST route as well wasn't too complicated.

Should I open a separate bug for the GET route only?

Possibly yeah. Could you describe your use case more? It sounds to me that you're after something more like "GET /patrons/{patron_id}/notices" for an API endpoint? So the file would be api/v1/swagger/paths/patrons_notices.yaml. You'll have to remember to honour things like Library Groups (so using something like Koha::Patrons->search_limited(). We have to make sure that API endpoints mimic the behaviour of the .pl controllers. Of course, that's easier said than done for a lot of API scenarios... but yeah describe it a bit more. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #12 from Shi Yao Wang <shi-yao.wang@inLibro.com> --- (In reply to David Cook from comment #10)

Possibly yeah. Could you describe your use case more?

It sounds to me that you're after something more like "GET /patrons/{patron_id}/notices" for an API endpoint? So the file would be api/v1/swagger/paths/patrons_notices.yaml. You'll have to remember to honour things like Library Groups (so using something like Koha::Patrons->search_limited(). We have to make sure that API endpoints mimic the behaviour of the .pl controllers. Of course, that's easier said than done for a lot of API scenarios... but yeah describe it a bit more.

It's really just getting the data necessary to show a user it's notices like in notices.pl but with an api call instead so I think your intuition is correct. I think I'll create another bug specifically for GET route -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #13)

(In reply to Shi Yao Wang from comment #12)

...

It's really just getting the data necessary to show a user it's notices like in notices.pl but with an api call instead so I think your intuition is correct.

So that use case is interesting. I note that you said "to show a user its notices like in notices.pl". At the moment, Koha only supports the client credentials grant for OAuth (and the HTTP Basic Auth is basically the same thing).

At some point, we need to start thinking about an API path starting with something like "/my/" where the API is in the context of the user rather than an all powerful API user. I raised bug 41671 to talk about / explore this

And actually... notices.pl doesn't allow a user to see their own notices. It allows a staff user to see another user's messages. If you're wanting to show an OPAC user their own messages, I don't think the OPAC actually has an equivalent. At some point, I want to do a proof of concept for this... -- You are receiving this mail because: You are watching all bug changes.