Which things do overwrite the "access group" when restricting work item access?
I have included the "Restricted Access" attribute of kind "Access Control" in my work item editor. I also created an access group named "Test team" which I am not a member of.
I created a new work item, saved it, and then changed the "Restricted Access" to "Test team", but I am still able to see the work item. Which is the real reason of still seeing the work item? Is it because...
a) I created the work item
b) I am the project area administrator
c) I am a Jazz admin
d) combination of previous options, or none of them?
I would like to know which scenarios may overwrite the restriction I defined for my work item. Thanks in advance!
--Claudia
2 answers
I am pretty sure it is (c) being a JazzAdmin. Users in the JazzAdmins repository group have read access to everything in the repository. (Therefore, JazzAdmin rights should be handed out only to very trustworthy people.)
It might also be (b), but I don't think so. Being a project area administrator allows you to read and to change the project area, but I don't think it gives you read access to all of the project area's work items.
I am pretty sure it is not (a). The creator of a work item does not have any special read access to the work item.
Thanks Dave.
After executing some scenarios, I can confirm it is only option c). So, with JazzAdmin privileges you are able to see any work item, even the restricted ones.
Being a Program Admin or even the creator of the work item is not enough to see a work item that has been restriced to a group that you are not in.
After executing some scenarios, I can confirm it is only option c). So, with JazzAdmin privileges you are able to see any work item, even the restricted ones.
Being a Program Admin or even the creator of the work item is not enough to see a work item that has been restriced to a group that you are not in.