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.)
+1! Also relevant for SIP2 users.
+1 This would be very helpful.
Oh self-checkout as well! I've had people break that by accidentally deleting the autologin user.
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.)
Adding a see also on bug 14708 - Anonymouspatron would be another candidate.
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.