DOORs Next Permissions Issue
I have a project with DOORs Next 7.0.2 where I am an admin of the project our organization works on. However, after looking into the project I have found some flaws. Any member of the Project can add new members, delete members, delete and modify teams, delete me as an admin and make themselves as an admin of the project and many more flaws with permissions I have ran into with Doors. Is there a way I can have better control over members in my project to where they are limited at what they can do and where they can rome. I know where the roles are and permissions are. But once they are a member they have control in the entire project and these permissions and doesn't work as they should.
Any suggestions?
|
One answer
This sounds like a serious problem with the way your roles have been set up in terms of permissions.
When you make somebody a member of a project area, but do not assign them a role, they are automatically given the Everyone role. Go into the project area's Permissions section and check what the Everyone role can do - it should be almost nothing.
Then set up the other roles (typically Commenter, Author and Administrator) so that they reflect what you want the users in that role to be able to do. The default role permissions out of the box are actually pretty good here, so I suspect somebody has messed around with the Everyone role.
I actually always go in and remove all permissions from Everyone, and add all permissions to Administrator. I also tend to remove the Configuration Manager role that gets set up as I don't find it useful as it is
Also make sure that people are just added to the Members section of the project area and not the Administrators section - that's another common mistake I have seen.
Comments Davyd,
Thank you,
I made an entire new project to test the permissions issue out, and any member I add with no role, which defaults to Everyone still can go into - (Manage the Project area) and add members and change their own role. Is this a bug? Does this need to be looked at further? Should I put a ticket in?
Marcus
Not a bug - it's a configuration issue on your end somewhere.
There's only 3 ways someone is able to edit their own roles in a project area:
- they have explicitly been given permissions. Check the Permissions section for the Everyone role and make sure that it has no permissions under the Process section at all
- they have been added as an Administrator. Check that you have added them under the Members section and not the Administrators section on the main Project Area admin page
- they have been put into the JazzAdmins or JazzProjectAdmins group when they were created as a user. Check that they are only in the JazzUsers group and nothing else
Ralph Schoon
commented Oct 24 '22, 9:19 a.m.
| edited Oct 24 '22, 9:20 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I have tried this with 6.0.6.1 and I can not reproduce this behavior. I will try 7.0.2. I used an administration user and created a user to the project area and I did not provide any role. I logged out and logged back in using the new user. I added another user with role and tried to save the project area. This resulted in an error:
I would check if the everyone role has strange permissions set.
Note, it is important to make sure the correct user is used. When working with multiple browser windows and logins strange things can happen. I thought I had reproduced it, but then realized I had a different login. I would check the permissions in your template. Otherwise I would open a case with support, to make sure there is nothing wrong.
Ralph Schoon
commented Oct 24 '22, 9:39 a.m.
| edited Oct 24 '22, 9:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I tested 7.0.2SR1 and see the same behavior. I can only assume the permissions for the Everyone role are allowing to "Modify collections of team members (modify/members)" in your project area.
Thank you,
Davyd and Ralph,
I am currently in 7.0.2 SR ifix16. Davyd I definitely understand your view point on how things should work, but I'm saying it is not working as it should. I'm the admin, using a member that has no rights at all, not in no administrative role but has administrative rights on the back end...of course there other permissions with folders they cant get to due to the roles that are set and are assigned to, however, that member can go to the Manage Project Area and change their role. Which should not be able to happen but can.
I've stripped all rights for every role, to test out a member of the project and its allows this function to take place. It's a concern as I am establishing a more strict role base for users of my project however, in doing I've found this issue.
Ralph Schoon
commented Oct 24 '22, 11:22 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I'd open a case with support. Something is not right.
Was about to say the same thing - if you're sure that the user is not a member of JazzAdmins or JazzProjectAdmins then I would open a case with Support straight away.
If this is a local installation in your environment and you're using LDAP, I would triple check the way the LDAP groups have been mapped - if they inadvertently have been put into the one of the Jazz admin groups, or if one of the admin groups has been mapped to a group they happen to be a member of, then that would totally explain what you see.
@Ralph - when you say "I tested 7.0.2SR1 and see the same behavior.", do you mean you CAN reproduce this or you CAN'T?
To Ralph's point, make sure you use a different browser for the test user or completely clear your cache first.
Just triple checking - you have only put users in the top section and not the bottom section shown here? Sorry if this is obvious but you have no idea how many times I see it!
showing 5 of 8
show 3 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.