feat: Introduce route to change group permission#4847
Open
zatteo wants to merge 1 commit into
Open
Conversation
Similar to route to change member permission. On existing member or group add, it is forbidden to add a member or a group that contains a member with a different permissions than an existing member. I kept this behavior when changing permissions to avoid any secondary effect.
3ffe388 to
49ae8e4
Compare
This file contains hidden or 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
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.
We want to be able to change a group permission in a sharing. New routes are similar to routes to change member permission.
Behavior
On existing member or group add, it is forbidden to add a member or a group that contains a member with a different permissions than an existing member. So if you have User 1 as readwrite and you try to add Group A that includes User 1 as readonly it is currently blocked by the stack.
I kept this behavior when changing permissions to avoid any secondary effects and complications.
In the long term, we want to be able to set different permission per members and per groups and compute for members the highest permission. But it requires a new attribute to track the initial permission of a member for the following scenario:
=> should we set User 1 to readwrite or readonly?
Related: linagora/cozy-client#1696
Usecase tested manually
One team
Two team
One team + one member
At the end here, Bob’s "only_in_groups" attribute is true (existing behavior).
One member + one team
At the end here, Bob’s "only_in_groups" attribute is false (existing behavior).