https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40023 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #4)
My interpretation was 'borrowers: 1' means the top-level permission, thus all borrower related permisions, so maybe too restrictive, even. That's why I proposed this.
Yeah, I originally thought "borrowers: 1" meant top-level permission too when I wrote the original endpoint, but I am quite confident that it doesn't. I need to work on a re-vamped permission (and probably review all other API endpoints to be honest...)
That said, I like the idea of a configuration patron profile endpoint.
In the meantime... what permissions would you require to allow having access to the full patron object?
edit_borrowers and list_borrowers can lookup the full patron object via /patrons/{patron_id}, so in the controller you could check for those permissions for the user before embedding the patron object. That would keep it consistent with the /patrons/{patron_id} endpoint. But I'm curious what's the use case you have in mind? I could understand wanting to return something like the user's names, because a third-party self-service kiosk or third-party digital service website might want to login a person using their Koha credentials and display their name without doing a full borrower lookup using /patrons/{patron_id}. (Of course, I'd also argue that third-parties should not have access to /patrons/{patron_id} because that's a personal information disclosure security issue.) Consider the ILSDI API. It has AuthenticatePatron which takes a username/password and returns an ID. The REST API needed that same functionality, so I added it via this endpoint. Then consider "GetPatronInfo" from ILSDI. It hides a lot of personal information. It should probably hide more than it does, but it hides a lot (in a good way). -- You are receiving this mail because: You are watching all bug changes.