Hi everyone,
Hoping to get some configuration examples/ideas or just some general thoughts to take back and think through.
I have inherited a Jira site and it's clear that this site was configured with one team in mind. Since I've been the administrator, there have been many teams and departments that have joined the site so the configuration is no longer suitable for me as a project administrator. Not having standard configurations results in too much manual work for me to spin up a new project but I'm also noticing that it's leading to collaboration gaps because teams aren't always speaking the same language (as far as custom fields on different projects goes).
There are a few thoughts I have on configuration changes but the one I want to focus on is permission schemes. We have a few groups that are all relative to one team. I want to instead revamp those groups and use them as a better way to set a baseline level of access for new users in Jira.
For anyone who handles Jira permissions via groups, in what way do you bucket your Jira users? I have considered going using organization (I work for an organization that contains several child organizations), department (these change too frequently for my liking and I know it's not currently possible to change a group name), and team. Do you have any suggestions? Any thoughts? Any pros and cons? Any other grouping buckets I should consider? Interested in any and all thoughts.
You can look into grouping them on multiple factors. So, this could be organization-team-role format. Example: at-product-developers where 'at' is the shortform for the organization, Atlassian, 'product' refers to the product management team, and 'developers' is the role of the individual in the team.
Ultimately what you decide on depends on what makes sense and is suitable for your organization. I would recommend looking at one type of project to see what makes sense and then see how this would work for all the other projects.
This would definitely be a time intensive process but will pay off in the future.
Hope that provides you with some guidance.
My general viewpoint is that everything in Jira should be open to all logged-in users unless there is a specific reason to lock things down. So I have a a single AD group that allows permission into Jira and a generic permission scheme that allows users in that group to browse the project.
If there are any specific projects that need to be locked down, I have different AD groups created and separate permission schemes that allow those groups to browse the project.
At least where I've used Jira, it's rare that there is a need to restrict access to certain areas of the tool once users are able to log into Jira.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see. When you say open, what kind of permissions does that relate to? Right now, the three roles we have in use are Administrator, Project Editor, and Project Viewer. For your example in my situation, are you saying that all logged-in users would be Project Editors for all projects using the general permission scheme?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We use a large number of shared schemes, so we don't really have project admins, since that would allow them to update a workflow or screens that are shared by other projects.
We are using DC so it's possible the naming convention is slightly different in Cloud, but we have a team of system administrators that manage everything from an administrative perspective, and then end users who can do pretty much everything else (e.g. create/manage sprints, any type of issue update, etc.)
There are some instances where particular groups of users can execute certain transitions, but we manage almost all of that via AD groups, which removes the responsibility of maintenance from the system administrators and puts it onto the Access Management team.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I probably should have chosen a discussion rather than a question but ah well, I'll just accept responses as answers lol
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.