[feat] Role and Permission system#2737
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #2737 +/- ##
==========================================
- Coverage 2.29% 2.18% -0.11%
==========================================
Files 171 176 +5
Lines 10287 10799 +512
==========================================
Hits 236 236
- Misses 10051 10563 +512
🚀 New features to boost your workflow:
|
|
Just a small note, temporary bans are implemented - this is done by adding a metadata property to the ban noting its expiration date. |
| action TEXT NOT NULL, | ||
|
|
||
| UNIQUE (resource_type, action) | ||
| ); |
There was a problem hiding this comment.
So the idea here is that permissions like page:read and page:edit will be in this table? I suppose that actions would be implemented in code (e.g. edit) vs the whole permission?
I suppose the reason for that would be that some permissions may be more finely-tuned, like for page categories?
Also if it is platform-wide, keep in mind that permission descriptions need to be localizable, which wouldn't really work with a single description column. (This would be fine if they were per-site, since then it would site admins setting the description, which would then be localized/customized to their site's audience.)
Additionally, if we want to have the concepts of platform permissions and custom site permissions, we can add a nullable site_id column (NULL = platform, otherwise = for that site). Though I'm undecided about this given the localization issue.
There was a problem hiding this comment.
Fair concern - putting page category aside, I think one way to solve the localization problem is using the [resource:action] pair as the key to look up in the locale file. Then we don't have to bake the description inside the entry. That would still not work with the custom site permissions though.
I suppose that actions would be implemented in code (e.g. edit) vs the whole permission?
I think for most actions, just calling a lookup to see if user has permission for a resource would suffice. Checks needing additional logic can have a wrapper over the lookup function to allow for more granular checking.
There was a problem hiding this comment.
To explore this a bit more, what exactly do you have in mind for custom site permissions? Any illustrative examples?
There was a problem hiding this comment.
Only use case that I can think of right now is per PageCategory permissions - since each site may have a different list of page categories, the permissions will also have to be scoped per site like how Wikidot currently does it.
| implicit BOOLEAN NOT NULL DEFAULT false, | ||
| -- Virtual roles are visible to admins where they can select the role's permissions. | ||
| -- Virtual roles cannot be manually assigned. | ||
| is_virtual BOOLEAN NOT NULL DEFAULT false, |
There was a problem hiding this comment.
Design question:
Would it be better for virtual roles to be in the database (and automatically added by jobs or code logic)? This would mean we can just query roles and get all of them.
Or should virtual roles be added automatically in the future RoleService when querying for a user? This way they're always up-to-date but it requires that callers go through this code path to ensure they're getting both all the real roles and the virtual ones.
I'm leaning more towards the latter but I'm curious as to your thoughts.
3 participants
Implemented a simple RBAC-style role/permission system. Took some heavy inspiration from Discord's role system.
Planned improvements:
As a proof-of-concept, I've added a permission check for page edits. Currently only the admin account is allowed to edit pages.