Restrict setting privileges on groups #8511
Conversation
tylerjmchugh
force-pushed
the
main.restrict-privileges-on-groups
branch
from
d0fbcc9 to
b05f8d7
Compare
|
@tylerjmchugh I started testing the pull request, but I'm getting some results that seem not correct. Let me add my test case:
EditorA creates a metadata and shares full privileges with Group B.
EditorA adds edit privileges to Group A.
Group A: Minimum user profile allowed to set privileges:
Group A: Minimum user profile allowed to set privileges:
Group B: Minimum user profile allowed to set privileges:
Something I don't have clear in this case, which setting should affect as the metadata is in GroupA, but the user is in GroupB. This should be clearly explained. About the help text for the field
It needs clarification also about the difference between the values No Restrictions and Editor as apparently seem the same. Also if the setting affects to users in that group or users that can edit metadata in owned by that group. Please also execute
|
The difference here should have been that with Looks like one of my commits did not get pushed. My latest push fixes this. This is that EditorB sees:
Same situation here. My latest push should fix the issue where GroupA privileges can be managed if the record owner group is GroupA. EditorA1 now sees the UI like in the above screenshot. But so does EditorA as they are not a reviewer for GroupA. For consistency of behaviour I have it working this way however I could include an exception for the record owner if you recommend that behaviour is better. (In our desired use case there would be no records owned by our restricted groups anyways)
This should now be consistent as well. With
The idea here is that the setting is not meant to prevent setting privileges for certain records but to prevent setting privileges for certain groups on all records. And this setting affects all users unless they have the minimum profile on the group they want to change privileges for. My missed commit made this confusing as the logic changed depending on whether the group to have privileges changed was also the record's owner group. This should not be the case. It should be consistent for all users and all groups. I have updated the help text to the following:
Hopefully this is more clear now with the consistent behaviour and updated help text. Let me know if anything else could be better explained. Updated results for test cases (See bold for relevant changes):
EditorA creates a metadata and shares full privileges with Group B.
EditorA adds edit privileges to Group A.
Group A: Minimum user profile allowed to set privileges: Editor
Group A: Minimum user profile allowed to set privileges: Reviewer
Group B: Minimum user profile allowed to set privileges: Reviewer
|
|
|
|
@tylerjmchugh I got this error in this case, when changing any privilege with
It only happens if the metadata is published. But I think is not related to the changes in the pull request as the related code throwing the error hasn't been changed. I'll check in a vanilla version of GeoNetwork to confirm this. |
|
@tylerjmchugh I've confirmed the previous error is not due to your changes. I've created the following issue to track it: #8551 |
|
The backport to stderrstdoutTo backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.2.x 4.2.x
# Navigate to the new working tree
cd .worktrees/backport-4.2.x
# Create a new branch
git switch --create backport-8511-to-4.2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick e1545f359973437fe80fbd13e25502ddb0160a97,fefe4d9bbc4f0c3ccbbee7bb7626c19351cf8da8,505733fbf200cfe53875d49c25441de133113e6c,b05f8d709d75a63d077f2a24e628ed81b7825628,4a137c2a733ae52ba0c95f57a64675cee4a477bc,b1a0c7b2825b76fe5a48d2d7ca7ad1f9533c28bc,c5f9dbd2d3168f462209c359c353114ebc691959,2851ea2174e3492d4469107713d3cdf37819ebdb,de5a00c1282f819ba4c84549e0162ae86cf512f8
# Push it to GitHub
git push --set-upstream origin backport-8511-to-4.2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.2.xThen, create a pull request where the |
* Add new minimumProfileForPrivileges property to groups * Disable the group in privileges UI if missing required profile * Restrict setting permissions for groups with a minimumProfileForPrivileges * Documentation * Update documentation * retrigger checks * Remove special case for groups that own the record * Update help text for clarity * Update formatting
* Add new minimumProfileForPrivileges property to groups * Disable the group in privileges UI if missing required profile * Restrict setting permissions for groups with a minimumProfileForPrivileges * Documentation * Update documentation * retrigger checks * Remove special case for groups that own the record * Update help text for clarity * Update formatting
* Add new minimumProfileForPrivileges property to groups * Disable the group in privileges UI if missing required profile * Restrict setting permissions for groups with a minimumProfileForPrivileges * Documentation * Update documentation * retrigger checks * Remove special case for groups that own the record * Update help text for clarity * Update formatting Co-authored-by: tylerjmchugh <163562062+tylerjmchugh@users.noreply.github.com>
Related to issue: #8283
Currently, users with access to the privileges interface can assign privileges (e.g., "publishing") to any group without restrictions. There is no built-in way to prevent users from assigning privileges to specific groups based on their profiles for that group. This pull request addresses this issue by introducing a
minimumProfileForPrivilegesfor groups. This field specifies the minimum user profile on a group required to assign privileges for that group.Changes
minimumProfileForPrivilegesproperty to theGroupclass to define the minimum profile required to set privileges for the group.minimumProfileForPrivilegesrequirement, preventing unauthorized privilege assignments. (See group 'b' below)Example Use Case
Consider two groups:
minimumProfileForPrivilegesset.minimumProfileForPrivilegesset to Reviewer.We want Group B to be used exclusively for access permissions, and we need to control who can assign privileges to it.
Workflow:
This setup ensures that only users with at least the Reviewer profile on Group B can assign privileges to Group B, providing better control over who can publish records to that group. It prevents users with lower profiles from inadvertently or intentionally assigning privileges to Group B, which could expose sensitive information or violate access policies.
If the default option of "No restrictions" is set for a group then the functionality remains the same as before these changes were implemented.
Checklist
mainbranch, backports managed with labelREADME.mdfilespom.xmldependency management. Update build documentation with intended library use and library tutorials or documentation