I'm using Vault 3.1.2. I can't get group level security to work.
The behavior I'm observing seems to differ from the behavior described in the help file in two ways:
1) The help file says that in the Folder Security screen, the rights checkboxes can be "Checked", "Intermediate Checked", or "Unchecked". I have found no way, however, to make a checkbox "Intermediate Checked".
2) The help file says that group rights apply only when there are no user rights, and there are no user rights when the rights checkbox is unchecked. When I uncheck a rights checkbox, however, the user is always denied the corresponding privilege; group rights seem never to be considered.
I suspect that part of the problem is imprecise syntax in the help file. I think it is using the word "rights" in some cases to mean "grants of privileges" and in other cases to mean "grants and denials of privileges". Beyond the terminology problem, however, I think there is a real problem in the way the application works, because despite considerable experimentation I simply can't get groups to work at all.
-TC
Group Security Doesn't Work
Moderator: SourceGear
Re: Group Security Doesn't Work
TC:TC wrote:1) The help file says that in the Folder Security screen, the rights checkboxes can be "Checked", "Intermediate Checked", or "Unchecked". I have found no way, however, to make a checkbox "Intermediate Checked".
The help file describes the "state" of the checkboxes - checked (or granted or assigned), unchecked (or denied or unassigned), and intermediate (inherited).
You can only do two operations on a security right grant/deny. If you check on an inherited security check box, you will be replacing that setting with a directly assigned grant/deny priviledge.
The only way to clear a setting is to view security rights for the specific group or user.
I believe there is a bit of confusion about directly denying rights and rights not assigned at all. When the help mentions "no user rights or no group rights" take that to mean there have been no grant/deny rights set whatsoever on the folder.TC wrote:2) The help file says that group rights apply only when there are no user rights, and there are no user rights when the rights checkbox is unchecked. When I uncheck a rights checkbox, however, the user is always denied the corresponding privilege; group rights seem never to be considered.
So when the rights check box is unchecked for a user/group on a given folder a "deny" right is being assigned to the folder.
Perhaps you could describe what you would like to achive with a small sample repository / user / group description, and we could provide you with the steps to make the configuration work.TC wrote:Beyond the terminology problem, however, I think there is a real problem in the way the application works, because despite considerable experimentation I simply can't get groups to work at all.
Jeff Clausius
SourceGear
SourceGear
Re: Group Security Doesn't Work
Jeff,
Thank you for the reply. Following your tip, I found that I could remove rights assignments by viewing the security rights for specific users, and I was thereby able to get group security to function as desired. Thanks.
I understand the system now, and I agree that it works. I contend, however, that the documentation does a poor job of describing its behavior. Beyond the semantically inconsistent use of the word "right", I think there is at least one factual error: On the page called "Group Rights", the help file explains
-TC
Thank you for the reply. Following your tip, I found that I could remove rights assignments by viewing the security rights for specific users, and I was thereby able to get group security to function as desired. Thanks.
I understand the system now, and I agree that it works. I contend, however, that the documentation does a poor job of describing its behavior. Beyond the semantically inconsistent use of the word "right", I think there is at least one factual error: On the page called "Group Rights", the help file explains
My testing suggests that folder proximity is more important than permissiveness, and that a more accurate explanation would be: "Precedence goes to the most permissive security setting among all group settings assigned at the closest ancestor folder." In fact, the example quoted does not work.If only group access rights exist, the most permissive group takes precedence. For example, if Group A allows R C at root and Group B allows R at $/foo/bar, then group A’s access rights take precedence at $/foo/bar.
-TC
Yes. I do think that is an error. I will log a bug to have the documentation updated.
The way I think about things is "closest" folder wins. In essence security on a particular item could be calculated as follows:
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).
The way I think about things is "closest" folder wins. In essence security on a particular item could be calculated as follows:
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).
Jeff Clausius
SourceGear
SourceGear