I have a problem withe the way the group permissions seem to work.
To simplify my problem lets assume I have two main groups.
Architects and Developers.
Architects have full access to project A and partial access to Project B while developers have partial access to Project A and unique partial access to Project B (i.e. not the same as the Architects access).
If a user is an Architect and a developer then usually the developer permissions are applied (as the developer restrictions appear to be closer to the folder in use) and the user is blocked from performing actions he should be allowed to do as an Architect in Project A.
Is this the correct behaviour?
We expected to have the full set of both permissions applied and be able to be a Developer Architect with the total full permissions of each.
Currently we seem to be able to only be a developer or an architect. This means that we have to add a new group called ArchitectDeveloper with the intersects all worked out.
As this is a simplified example and I really have quite a few groups (to handle all those nasty little surprises you get day to day) it gets quite complex quite fast.
Please advise. It used to work as expected (perhaps erroneously - but it worked).
Group permission behaviour
Moderator: SourceGear
In essence security on a particular item is calculated in the following manner:
1) Is there a "user" right assigned to a folder or an ancestor? The user right (grant/deny)on the folder or closest ancestor is the designated right (grant/deny).
2) If no user right was assigned, is there a "group" right assigned to a folder or an ancestor? The group right (grant/deny) on the folder or closest ancestor is the designated right (grant/deny).
3) If no user or group right was found in 1 & 2, then the user's default right (grant/deny).
If you are only using group rights what is the "closest" folder's permission setting for any group the user belongs?
1) Is there a "user" right assigned to a folder or an ancestor? The user right (grant/deny)on the folder or closest ancestor is the designated right (grant/deny).
2) If no user right was assigned, is there a "group" right assigned to a folder or an ancestor? The group right (grant/deny) on the folder or closest ancestor is the designated right (grant/deny).
3) If no user or group right was found in 1 & 2, then the user's default right (grant/deny).
If you are only using group rights what is the "closest" folder's permission setting for any group the user belongs?
Jeff Clausius
SourceGear
SourceGear
That's really the problem I guess.
The developer restriction would be the closest ancestor but if the architect is not a developer then full access is granted because of the greater permissions granted at the root of the project for Architects.
I would have expected the Developer restriction to be ignored because of the Architect group is not restricted at that point.
I guess I'm saying the current permissions do not work well (for us anyway) as the effects of belonging to multiple groups is difficult to assess without knowing all the permissions a user already has. Indeed it is likely that each user will have to be assigned a unique group to cater for all the combinations of access they may have - making groups not particularly helpful.
The developer restriction would be the closest ancestor but if the architect is not a developer then full access is granted because of the greater permissions granted at the root of the project for Architects.
I would have expected the Developer restriction to be ignored because of the Architect group is not restricted at that point.
I guess I'm saying the current permissions do not work well (for us anyway) as the effects of belonging to multiple groups is difficult to assess without knowing all the permissions a user already has. Indeed it is likely that each user will have to be assigned a unique group to cater for all the combinations of access they may have - making groups not particularly helpful.
Folder security has been molded over the years based on customer feedback. The current implementation is what most customers have asked for - the ability to restrict rights lower in the tree.
About the only work around would be to make a direct right assignment on the same folder which would cause a conflict. In the case of a group conflict, the higher rights win.
For example (groups Architecht and Developer):
$/A - Architecht (R, C, A)
$/A/Sub1 - Developer (R)
$/B - Developer (R, C, A)
$/B/Sub2 - Architecht (R)
In the case of a user in both groups, they would be denied rights in either SubX project. To allow access on the SubX projects, Architect would be granted R,C,A for $/A/Sub1 and Developer would be granted R,C,A for $/B/Sub2
About the only work around would be to make a direct right assignment on the same folder which would cause a conflict. In the case of a group conflict, the higher rights win.
For example (groups Architecht and Developer):
$/A - Architecht (R, C, A)
$/A/Sub1 - Developer (R)
$/B - Developer (R, C, A)
$/B/Sub2 - Architecht (R)
In the case of a user in both groups, they would be denied rights in either SubX project. To allow access on the SubX projects, Architect would be granted R,C,A for $/A/Sub1 and Developer would be granted R,C,A for $/B/Sub2
Jeff Clausius
SourceGear
SourceGear