nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Nic - Help with Security to Project - Groups or Roles?

Mark Gordon

JIRA and Nic,

We are trying to find the best way to handle securiyt. We want our users to be only able to see tickets under their project. We first decided to make Project Roles. They users are falling under jira-uses groups which I think is fine. I have users associated to Project Roles and the proejct roles have specific permissions. The uses are able to see other projects. Obviously we have quesiton about our approach. 1 - Should we be using groups?, 2 - Why are they seeing projects outside of their project?

We have viewed the youtube Jira sponsored turtorial on users, groups and permissions but not much help here. Any suggsetions woudl be appreciated.

Thanks,

Accepted answers

Nic Brough -Adaptavist-

Yes, the client usage would be like that. I'd try to keep group names clear as well - name them after the client. Then you can use the groups in relevant projects.

So, now you have roles of Agent, Supervisor and Executive. And groups of shipping and OrderPlacement. Again, I go back to these being separate entities that can work together - you certainly should NOT just merge or hybridise them. Work your way through the logic:

Are all people in Shipping going to be Agents? If yes, use the group in the Agent role.
Are all people in Shipping going to be Supervisors? If yes, use the group in the Supervisor role.
And so on.

The flexibility in roles means that you *can* use groups, but you really don't have to. If there is no match between a group and a role, then forget it, don't bother, your groups don't match your roles.

The good thing about the use of roles here is that

It's delegate-able - your project admins can put INDIVIDUALS and/or groups in to roles, you're not relying on your admins to maintain every single group all the time (that way lies madness)
It's flexible - you can use users, or groups, or combinations thereof in it
It's tied to projects, not global settings
You can reuse the same schemes over and over.

So, the answer to "is there a better way" is "Yes, use roles and dump your groups unless you have a really good reason to use them". Good reasons would be for basic reporting or VERY generalised things like "Group A = customer X", or "business unit 1" vs "business unit 2"

All comments

Nic Brough -Adaptavist-

Start with the permission scheme for each project (it could well be one scheme shared, or many schemes. Either way is fine, you just need to look at them to establish what is going on)

In each scheme, list out what the rule is for "Browse Project". It's likely to be something like "Role (users)", and I'm strongly hoping it is *just* roles you are using in there.

Then, go into each project and check who matches the rules given for browse-projects.

I suspect you're using Jira-users in the roles, which means "all people who can log in are project users" and the permissions scheme rules will make that "project users can see the issues". So everyone.

If that's the case, you need to stop using jira-users in any roles. Go through the projects and strip it out, replacing it with more appropriate sets of users and/or groups.

Mark Gordon

Nic,

We are almost there We do have a specific permission schema. We are using custom Roles. Assiging users to the roles. yes, the users are tied to Jira_user. So, we would want to make a new group. Assign those users to the group instead of Jira_user. Then work with Browse Project by either gorup or role? do you have a prefreence to use group or role?

Nic Brough -Adaptavist-

Do not mix up roles and groups. ("The users are tied to jira_user" is vague in the way you've used it and probably inaccurate). Go back over your roles, check the usage of groups and make sure that you have a full flow of rights - think of it as "Role X can do Y, and group Z is in role X, so they can". I've found writing it out like that can really help sometimes.

I'd always recommend using roles for access, groups might look simple, but they're a nightmare to look after in large systems. It's fine to add them to roles, but they should be used very sparingly in permissions schemes.

randyz

Hi Mark,

You are almost there.

Like Nic said use the project roles, then add groups to the project roles.

It would also be best create a number of groups to use per project. Each project role should have the nessary groups that you have created for administration purposes.

How many groups and what type of groups you need to create really depends on the organizational needs of your users and projects.

You may create a group per project, static project strategy.

create a group and add all the users that need access to that group
add the group to a role that has browse permissions

You may create group per team, cross project strategy.

setup mutiple group based on team functions
setup roles to applicable functions of the project
add the functional groups to the applicable roles of the project (either browse or edit)

Another note is that if you don't want users with project browser permissions to transition tickets, conditions must be set to limit those that may transition the issue(best to use roles for this as well).

Nic Brough -Adaptavist-

Yes, the client usage would be like that. I'd try to keep group names clear as well - name them after the client. Then you can use the groups in relevant projects.

Are all people in Shipping going to be Agents? If yes, use the group in the Agent role.
Are all people in Shipping going to be Supervisors? If yes, use the group in the Supervisor role.
And so on.

The good thing about the use of roles here is that

It's delegate-able - your project admins can put INDIVIDUALS and/or groups in to roles, you're not relying on your admins to maintain every single group all the time (that way lies madness)
It's flexible - you can use users, or groups, or combinations thereof in it
It's tied to projects, not global settings
You can reuse the same schemes over and over.

Mark Gordon

Nic, Thanks but there is a couple of more tangents. We would have multiple clients.

So, it woudl look like this:

ABC Company

Shipping Team

Agents

Supervisors

Order Placement Team

Agents

Supervisors.

With the above, we were thinking of still using Groups to keep it split out so clients do not see other clients - mihgt be a bit easiser this way. But with whatever we use, something might be a highbrid. Jsut because there is a role called agent might not be powerful enough. We might have to have a role called Shipping Team - Agents so we can handle seucrity for those to only work with specific issues. Then that will tie back to a group called ABC Company - Shipping Team. I do not like this concept but it might be easier for someone to add users to. So, we could address permissions by adding Shipping Team - Agents and Shipping Team - Supervisors for Create issues - something like that. Any other suggestions?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

security