Hello there! I'm constructing a website which heavily uses the Auth package, and mainly the Ormauth driver. It's excellent! Very easy to use and understand. However, now it's time to write a (admin) user interface to edit groups. Each group has [0..n] roles ans [0..n] permissions associated with it, but how do you properly write such interface? Basically you want to switch roles and permissions on/off, like a Yes/No switch, but what I want too, is that if you select a role, it also shows the permissions associated with that role. So the permissions looks like a tristate, Off/On by a role/On by a permission. Does anyone have ideas how to properly display this (don't worry about the backend, I can figure that out myself :))?
It depends a bit on your use case, but in most cases, permissions are there to be tested in the code. Which implies that the list of possible permissions are fixed, created as the code is written.
We add permissions as lang-strings using migrations, and add translations for these lang-strings to lang files, since our apps are multi-lingual.
Our admin panel has entries for users, groups and roles, with an action_index that shows a paginated list. Every entry on that list has an action menu, containing actions to assign a user to a group or a role, to assign roles to a group, or to assign permissions to a user, role or group.
The permission screen just shows the list of the permissions available in the database, if needed with underlying actions, with a checkbox. So you can check which permissions should be assigned to the user, role or group you selected. When you save it, the checkboxes will indicate which relations need to be created.
So there is no tristate, the UI has user->permissions, role->permissions and group->permissions, and all three screens look completely identical.
Yeah sure, the permissions itself are hard-coded, and inserted in the database using migrations as well, that ain't the problem.
The problem I'm still seeing is this: when you assign a user to a role (or group), you can't see the permissions (or roles->permissions in case of a group), so basically you give them "blind" permissions (I mean, you certainly know which permissions are associated with a role or group, but if you have lots of roles, it becomes impractical). That's why I asked to do a "live update" when assigning a role to a user, to immediately show which permissions the user has, since that's the basics of the application.
Sure, it is possible to do only basic updates, what you suggest, but I still some disadvantages with it ;)
I understand that, but that should not be relevant.
If you have a group or role "HR", to which the permissions for all HR staff are assigned, that either a user works for HR, or doesn't. If at the point of user->group/role assignment you need to know what rights are assigned to the group or role, I'd hazard a guess that you've assigned your rights incorrectly (or have used non-descriptive names)
Calculating the users effective rights is complex business, if you want to know how that works, or have access to the calculated result, you need to check the code.
Donate
