Add permission exists but is denied by server
Moderator: SourceGear
Add permission exists but is denied by server
Client + Server: 2.06
User X wants to check in a file in $/Projec /Folder1/Folder2/Folder3
He has RC permission (by inheritance through a group) on Folder 1 and RCA on Folder2. Folder2 has several subfolders.
The check in is failed with the following error message:
"Item $/Projec /Folder1/Folder2/Folder3/Images/abc.gif caused the transaction to fail: You do not have the permission to perform the operation."
Can you please advise what was wrong? Thanks in advance.
User X wants to check in a file in $/Projec /Folder1/Folder2/Folder3
He has RC permission (by inheritance through a group) on Folder 1 and RCA on Folder2. Folder2 has several subfolders.
The check in is failed with the following error message:
"Item $/Projec /Folder1/Folder2/Folder3/Images/abc.gif caused the transaction to fail: You do not have the permission to perform the operation."
Can you please advise what was wrong? Thanks in advance.
You will first need to identify the user / repository.
SELECT userid, login, name FROM sgvault.dbo.tblusers
SELECT repid, name FROM sgvault.dbo.tblrepositories
with userid / repid in hand, run the following query:
SELECT * FROM sgvault.dbo.ufngetusersecurityrights(@@repid, @@userid)
I'm interested in the results from this last query.
SELECT userid, login, name FROM sgvault.dbo.tblusers
SELECT repid, name FROM sgvault.dbo.tblrepositories
with userid / repid in hand, run the following query:
SELECT * FROM sgvault.dbo.ufngetusersecurityrights(@@repid, @@userid)
I'm interested in the results from this last query.
Jeff Clausius
SourceGear
SourceGear
Tri:
Thanks for sending the information. Your configuration follows:
$/projects/A = USER r,c
$/projects/A/subproj = GROUP_1 - r,c
$/projects/A/subproj/src/files = GROUP_1 - r,c,a
...
From the Admin Tool Help about group rights:
User access rights always take precedent over group access rights regardless of where in the tree the group rights are applied. For example, a user access right at root takes precedence over a group access right on the folder itself.
( Note, there is a typo in the first sentence - the word precedent should be precedence. )
Anyway, the user X cannot add because there is a USER assigned right of RC that overrides all other group rights set below. Removing the user right on $/projects/A should allow user X to add the files.
Thanks for sending the information. Your configuration follows:
$/projects/A = USER r,c
$/projects/A/subproj = GROUP_1 - r,c
$/projects/A/subproj/src/files = GROUP_1 - r,c,a
...
From the Admin Tool Help about group rights:
User access rights always take precedent over group access rights regardless of where in the tree the group rights are applied. For example, a user access right at root takes precedence over a group access right on the folder itself.
( Note, there is a typo in the first sentence - the word precedent should be precedence. )
Anyway, the user X cannot add because there is a USER assigned right of RC that overrides all other group rights set below. Removing the user right on $/projects/A should allow user X to add the files.
Jeff Clausius
SourceGear
SourceGear
Instead of counter-intuitive, I would rather say security rights require a different way of thinking.
Allowing user assigned rights to trump any group rights allows a much finer control. This comes in handy when a group has been granted certain access to a part of the tree, and an admin still wants to deny a specific user access to that folder. In this case, assigning a "deny" right for a user denies the user that part of the tree.
Allowing user assigned rights to trump any group rights allows a much finer control. This comes in handy when a group has been granted certain access to a part of the tree, and an admin still wants to deny a specific user access to that folder. In this case, assigning a "deny" right for a user denies the user that part of the tree.
Jeff Clausius
SourceGear
SourceGear