Groups wont work after Update to V3.1.2
Moderator: SourceGear
Groups wont work after Update to V3.1.2
Hi there,
today I updated from 3.1.1 to 3.1.2
A couple of minutes ago a user told me that he isn't able to check out files anymore.
After testing around I figured out that the rights given to a group won't work anymore.
e.g.
The user FRED is member of a group DEV.
The group DEV has been given R/C/A to a repository PROJECT.
Before the update everything worked well. Today I've got a bunch of users which aren't able to checkout files.
Now I have assigned rights on a per user basis.
But I'd like the groups thing working.
Have you got any suggestions ?
Regards,
John
today I updated from 3.1.1 to 3.1.2
A couple of minutes ago a user told me that he isn't able to check out files anymore.
After testing around I figured out that the rights given to a group won't work anymore.
e.g.
The user FRED is member of a group DEV.
The group DEV has been given R/C/A to a repository PROJECT.
Before the update everything worked well. Today I've got a bunch of users which aren't able to checkout files.
Now I have assigned rights on a per user basis.
But I'd like the groups thing working.
Have you got any suggestions ?
Regards,
John
John:
Vault 3.1.1 and less was incorrectly calculating security rights in certain cases. Here is how the Vault 3.1.2 Server determines rights:
1) Does the user have rights assigned to the folder or any folder ancestor? If so, the closest folder assignment (moving up the ancestor list) is used.
2) If no user right is assigned from step 1, does any group have an assignment to the folder or folder ancestor(s)? If so, the closest folder assignment (moving up the ancestor list) is used.
3) If no user or group rights are assigned from step 1 and step 2, use the user's default rights.
So in your case, can you look at user rights assigned to FRED, rights assigned to ALL of FRED's groups (including DEV), and FRED's default rights. Do you see a conflict where FRED may have a USER right denied along PROJECT's ancestors? This user right may be over-riding the group right.
Vault 3.1.1 and less was incorrectly calculating security rights in certain cases. Here is how the Vault 3.1.2 Server determines rights:
1) Does the user have rights assigned to the folder or any folder ancestor? If so, the closest folder assignment (moving up the ancestor list) is used.
2) If no user right is assigned from step 1, does any group have an assignment to the folder or folder ancestor(s)? If so, the closest folder assignment (moving up the ancestor list) is used.
3) If no user or group rights are assigned from step 1 and step 2, use the user's default rights.
So in your case, can you look at user rights assigned to FRED, rights assigned to ALL of FRED's groups (including DEV), and FRED's default rights. Do you see a conflict where FRED may have a USER right denied along PROJECT's ancestors? This user right may be over-riding the group right.
Jeff Clausius
SourceGear
SourceGear
No, I don't see a conflict.
The only objects given permissions to the repository are the groups DEV and the project manager (PM)
1) No single user has rights assigned anywhere in the repository except PM who has full access everywhere inside the repository.
2)The group DEV has got rights assigned to it and is the only group FRED is a member of.
3)Default rights for Fred are no rights.
FRED isn't able to check out any file. Regarding the rights given to his group DEV, he should be able to.
I've got much expertise with groups, nested groups and rights.
But I don't understand the way Vault 3.1.2 acts.
Any other ideas ?
Regards, John
The only objects given permissions to the repository are the groups DEV and the project manager (PM)
1) No single user has rights assigned anywhere in the repository except PM who has full access everywhere inside the repository.
2)The group DEV has got rights assigned to it and is the only group FRED is a member of.
3)Default rights for Fred are no rights.
FRED isn't able to check out any file. Regarding the rights given to his group DEV, he should be able to.
I've got much expertise with groups, nested groups and rights.
But I don't understand the way Vault 3.1.2 acts.
Any other ideas ?
Regards, John
Yes, got the same problem:
Reproduce like this:
Create group "testgroup"
"testgroup" has R rights to "$"
"testgroup" has RCA rights to "$/Testproject"
Create user "testuser"
"testuser" is only part of "testgroup", no other rights (Default rights dont matter)
-> check out in "$/Testproject/Subfolder/fileA.txt" not possible
Reproduced in Vault 3.1.2.3511
Ciao,
Herbert.
Reproduce like this:
Create group "testgroup"
"testgroup" has R rights to "$"
"testgroup" has RCA rights to "$/Testproject"
Create user "testuser"
"testuser" is only part of "testgroup", no other rights (Default rights dont matter)
-> check out in "$/Testproject/Subfolder/fileA.txt" not possible
Reproduced in Vault 3.1.2.3511
Ciao,
Herbert.
Herbert / John:
I'm still not able to recreate this problem. I've outlined my steps w/ screenshots against a Vault 3.1.2.3511 server (about.png).
1) Brand new Vault 3.1.2 install. Enabled Default Repository's Folder security.
2) Using the Admin account create the folowing tree structure
3) Created group testgroup. Assigned R to $/ and RCA to $/Testproject/ - see screenshot (group_assignment.png)
4) Created user testuser w/ No default rights, and assigned them to testgroup. (testuser_1.png & testuser_2.png)
5) Logged in as testuser and then set working folder for $/ to c:\test\1
6) Checked out $/Testproject/Subfolder/fileA.txt with no errors. (testuser_checkout.png)
Is this the case you described above? Did I miss a step?
If you look at the security rights for users which cannot checkout, what does the security settings look like? See my testuser_2.png for an example.
I'm still not able to recreate this problem. I've outlined my steps w/ screenshots against a Vault 3.1.2.3511 server (about.png).
1) Brand new Vault 3.1.2 install. Enabled Default Repository's Folder security.
2) Using the Admin account create the folowing tree structure
Code: Select all
$/
$/Testproject/
$/Testproject/Subfolder/
$/Testproject/Subfolder/fileA.txt
4) Created user testuser w/ No default rights, and assigned them to testgroup. (testuser_1.png & testuser_2.png)
5) Logged in as testuser and then set working folder for $/ to c:\test\1
6) Checked out $/Testproject/Subfolder/fileA.txt with no errors. (testuser_checkout.png)
Is this the case you described above? Did I miss a step?
If you look at the security rights for users which cannot checkout, what does the security settings look like? See my testuser_2.png for an example.
- Attachments
-
- checkout of testuser
- testuser_checkout.png (37.66 KiB) Viewed 11918 times
-
- security rights of testuser
- testuser_2.png (19.68 KiB) Viewed 11918 times
-
- edit screen of testuser
- testuser_1.png (20.85 KiB) Viewed 11918 times
-
- testgroup assignments
- group_assignment.png (13.9 KiB) Viewed 11918 times
-
- Help -> About
- about.png (10.62 KiB) Viewed 11918 times
Jeff Clausius
SourceGear
SourceGear
John:PACEGMBH wrote:No, I don't see a conflict.
1) No single user has rights assigned anywhere in the repository except PM who has full access everywhere inside the repository.
2)The group DEV has got rights assigned to it and is the only group FRED is a member of.
3)Default rights for Fred are no rights.
From within the Admin tool, can you move to the Users tab, highlight FRED, and then click the Security Rights button. What rights are assigned to Fred?
Jeff Clausius
SourceGear
SourceGear
Herbert:
I'm scratching my head here.
Were my steps "exactly" the same steps you used? If you follow the steps (for a new group / user) in the same order as I outlined above, do you still see the problem?
Perhaps there is something weird if the user is created first, and the group created second? Anything else that you can think of that looks different from my example?
I'm scratching my head here.
Were my steps "exactly" the same steps you used? If you follow the steps (for a new group / user) in the same order as I outlined above, do you still see the problem?
Perhaps there is something weird if the user is created first, and the group created second? Anything else that you can think of that looks different from my example?
Jeff Clausius
SourceGear
SourceGear