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.
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:
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
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"
Nic, Thanks but there is a couple of more tangents. We would have multiple clients.
So, it woudl look like this:
Order Placement Team
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?
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.
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?
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.
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.
You may create group per team, cross project strategy.
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 and Randy,
Thanks for your answers. Yes, what you are stating is what I meant. We are doing the Group and Role relationship. We will be using groups like teams and then tieing those to roles. Then using the Roles in permissions. I do have one question about functinality. If you are using JIRA for a mutliple client setup, then it would seem only logical that you would create client specific groups and client specific Roles for each project. I would believe trying to have one set of either would be asking for trouble in that you woudl not want one client to see antoher clients project.
Nic and Randy,
I do need to bounce a concept off of you in regards to your suggested solution for group to role.
The current concept of our roles would be Agent, Supervisor, Executive
So lets say we have teams(groups) called Shipping and OrderPlacement. We associate users to each team. Then we tied the teams (groups) to the roles - that really would not work because everyone in that team would get whatever the role had in permissions. One options would be to call our groups a team/role blend in the name of the group, such as shipping -Agents, shipping-supervisors. Then we would tied that back into the Agent role or Supervisor role appropriately. Is there a better way?
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG