|Summary:||Create "system" patrons that cannot be (easily) deleted via the web UI|
|Product:||Koha||Reporter:||David Cook <dcook>|
|Component:||Patrons||Assignee:||Bugs List <koha-bugs>|
|Status:||NEW ---||QA Contact:||Testopia <testopia>|
|Priority:||P5 - low||CC:||gmcharlt, kyle.m.hall, lisetteslatah, magnus, martin.renvoize|
|Change sponsored?:||---||Patch complexity:||---|
|Text to go in the release notes:||Version(s) released in:|
Description David Cook 2020-08-07 07:30:56 UTC
At the moment, the only way to create OAuth2 or Basic Auth credentials is to generate a user. This user can be deleted by a librarian by accident, which will break your API integration with Koha. I propose that we make some system users that cannot be deleted from the Web UI. (Or users that can be deleted by a superlibrarian, but need to be "unlocked" first or maybe have their category changed, and a warning splashed that this will likely break integrations with other systems.)
Comment 1 Magnus Enger 2020-08-07 08:27:25 UTC
+1! Also relevant for SIP2 users.
Comment 2 Lisette Scheer 2020-08-07 16:32:27 UTC
+1 This would be very helpful.
Comment 3 David Cook 2020-08-09 23:38:11 UTC
Oh self-checkout as well! I've had people break that by accidentally deleting the autologin user.
Comment 4 David Cook 2020-08-09 23:39:00 UTC
My boss pointed out that we'd also want to "lock" password changes, as that would have consequences for integrations too. (Not to say you can't change the password, but that it would need to be harder and have a warning that it could break integrations.)
Comment 5 Katrin Fischer 2020-08-16 11:09:55 UTC
Adding a see also on bug 14708 - Anonymouspatron would be another candidate.
Comment 6 David Cook 2020-09-01 00:03:34 UTC
Bug 23634 provides similar logic to what will be needed here. But instead of "$patron->is_superlibrarian && ! $user->is_superlibrarian", it'll be "$patron->is_system_user && ! $user->is_superlibrarian". Now I just need to decide how to denote a system user. On Bug 23634, Martin mentions that we don't have role based access control (RBAC) and that's true, but maybe that should change. Although RBAC can get complicated. While you could calculate and cache the permissions for a logged in user session, that could get more challenging for the $patron that isn't logged in... I suppose maybe it wouldn't be too hard to do $patron->has_role('system'), especially leveraging a L1 cache.