Add granular permissions to the realm tree #1097
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
LukasKalbertodt
requested changes
Feb 5, 2024
LukasKalbertodt
requested changes
Feb 5, 2024
There was a problem hiding this comment.
Ok now I tested this on the test deployment, but also some general comments.
- I like that
ROLE_TOBIRA_MODERATORis not used anymore. If you want the old behavior, you can just add that known group and then add it to the root realm. - DB dump should have some realm permissions already set. Doesn't need to happen in this PR, rather a reminder.
- I like the UI a lot. The separator with the note is good. I think everything is clearly communicated.
- When editing permissions and the current user only gets permission do to that from a parent realm, then trying to save something without yourself explicitly added will cause warning "remove own write access?". So I guess for that check, the flattened roles have to be checked as well.
- And confirming that, the spinner (which is left aligned for some reason) spins forever, never finishing. But the request went through and the permissions were saved.
- When a user that only has moderate permissions adds a page, but immediately wants to remove it again, they can't. What do you think about adding "manage" permissions to new pages for the user that creates it?
LukasKalbertodt
requested changes
Feb 5, 2024
owi92
force-pushed
the
realm-tree-permissions
branch
from
90a140b
to
0e87185
Compare
owi92
force-pushed
the
realm-tree-permissions
branch
from
0e87185
to
b805d33
Compare
LukasKalbertodt
requested changes
Feb 12, 2024
This adds two fields for different permission levels and two additions fields to hold inherited permission levels of parent realms. `Moderators` enables users to edit content while `admin` enables everything, including "danger zone" things. Roles are inherited in an additive manner, meaning a child realm will inherit the `roles` and `inherited roles` of their respective parent realm.
owi92
force-pushed
the
realm-tree-permissions
branch
from
96e9385
to
9d4d8ec
Compare
LukasKalbertodt
requested changes
Feb 13, 2024
LukasKalbertodt
requested changes
Feb 13, 2024
owi92
force-pushed
the
realm-tree-permissions
branch
from
9d4d8ec
to
cc5f42b
Compare
LukasKalbertodt
requested changes
Feb 13, 2024
This moves the save and reset button group into the general ui/Access.tsx file to be reused in other contexts. It also adds additional action types that can be passed as a prop.
We previously showed `Administrators` in the user column when logged in as such, so this didn't need the `no entries` display. This moved to the groups column but I forgot to adjust the condition. Also removes an empty `css` prop.
With this, realm editing permissions are initially restricted to admins. They can add permissions for users and groups to either `moderate` (i.e. edit content, add subpages and edit non-critical realm settings) or `manage` (do everything including deleting realms and editing their permissions). Permissions are inherited to children realms, which the ui does not reflect with this commit. That is added in a following commit.
This shows the permissions that are inherited from all ancestor realms as immutable entries in the current realm's acl selectors. Entries that are already being inherited can still be added to allow "upgrading" permission levels, i.e. from "moderate" to "manage". However it is worth noting that adding an entry with "moderate" level while the inherited permissions already contain that entry with "manage" permission, that permissions will not be "downgraded". Basically the permission level of doubled entries will resolve to the highest level between both entries.
With this, the current user's user role gets included implicitly in their own user realm. This allows for easier handling of already existing user realms, immutability and "inheritance" of that role.
This is only done for subrealms that aren't descendants of the current user's user realm, since we don't want/need to add it explicitly in that case.
Since the realm owner is already implicitly included with an immutable entry in an owner realm's acl, it should be excluded as an addable option to prevent duplication.
owi92
force-pushed
the
realm-tree-permissions
branch
from
cc5f42b
to
4031ae8
Compare
Anonymous users should never be allowed to modify realm content or settings, so it's safest to just exclude the option from the realm ACL selectors.
owi92
force-pushed
the
realm-tree-permissions
branch
from
4031ae8
to
146ebb2
Compare
LukasKalbertodt
approved these changes
Feb 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows restricting editing permissions to users and groups of users as discussed in #1049.
There are two "levels" of access:
moderate: Users can add subpages and edit content and page settings (excluding permissions and so called "danger zone" things like deleting the page or renaming its path)admin: Everything a moderator can do, but including editing permissions and danger zone thingsPermissions are inherited down to every subrealm of a specific realm but can be expanded on in these subrealms. It is however not possible to remove or "downgrade" the access level of an inherited entry, so any user included in a parent realm's access list has at least the same access level for that parent realm's children.
Closes #1049
(Can be reviewed commit by commit)