I created a permission scheme from scratch and where most if not all permissions like browse projects, create issues, add attachments, etc. are granted to site admins, jira-servicedesk-users group, and service desk customer - portal access. The error that shows up reads like the following:
Permission Errors
This service desk project has permission errors that can impact functionality. It says the administrators role is missing a few permissions, same as service desk team, and service desk customer.
These are all project roles. So my question is, am I only suppose to use project roles in permission schemes or can I grant permissions to groups only? And when I click "Fix Permissions" it makes a new permission and names it the same but puts a 1 or 2 depending on which one it was. When it comes to the group I work with, we kind of do not need an administrator or jira-administrator, just users and site admins and customers. Could I give my agents administrator project roles for their respective projects and grant the administrator project role permissions?
We have around 70 permission schemes and 50 projects so I am trying to clean up. Someone on the community told me I only need one permission scheme for all 50 projects if the permissions are going to be the same for them. Sorry for the long description. Hope you understand the question, if not please ask for more clarification. Thank you for your help.
Hi @Fahad Akhtar ,
I see three main questions, if I'm misunderstanding anything please let me know.
1. What is the proper use of roles & groups? - Service Desk requires certain roles to be added to the scheme as you've noticed, but you don't need to grant these roles to any users. It typically recommended to use project roles over groups because it allows for the project admin to manage access to their project, instead of requiring someone with the jira-administrator permission to edit groups. It's also beneficial because if there are ever differences in who should have access to a project, roles will let you specify who should be added to a certain project, whereas adding a user to a group will grant access for any scheme with that group in it.
2. What roles should users have? - A little confused by the wording here, but it sounds like you'd like to know where to assign the Administrator role? It again not necessary to give it to anyone. If you've added a group into the Agent or Administrator permissions, members of these groups will be able to use their functionality. You just lose out on being able to make projects have a unique "staff" as every member of these groups will have the same access/permissions for all projects using the scheme.
3. How best to clean up? - That's correct, if all projects should use the same scheme, you only need one. Note: anyone with the jira-administrator permission can edit the access of a permission scheme and if this is done, it will of course affect all projects using it.
1. What is the proper use of roles and groups?
I have 6 agents that work on a total of 50 or so projects. The project load is distributed among the 6 of us. But I want everyone of these 6 agents to see all 50 projects and to have access to all aspects of these 50 projects. This is why I feel I have to grant permissions to the group these 6 agents are in instead of assigning the project administrator project role to each agent for their respective projects. Also I tested to see what an agent can see when they are assigned a project administrator role to one or more projects. They only have access to the customer portal/help center.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
My above reply kind of answers your number 2 concern of everyone my agents having access to all projects which is what I want.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What is the difference between the administrators project role and the administrator group and the jira-administrators group? What are the similarities and differences? Thanks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There are three main admin groups on Cloud- jira-administrators, administrators, and site-admins. Site-admins is for full administration including user management and billing. Jira-administrators and administrators have the same permissions by default, but the former is for specifically admins of Jira, whereas the latter allows for administration of multiple applications (If you have Jira and Confluence linked for example)
You can see more info here: https://confluence.atlassian.com/cloud/create-and-update-groups-744721627.html
The Administer Projects permission lets you see the Project Settings option in a project. The Administrators role (when linked to this permission) lets you specify individual people who should see the Project Settings option without sharing that power in other projects using the same scheme. (Not what you want in your case)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Okay thank you for your answers. They clarified a lot of stuff for me.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Jira service desk has very strict permission structure. Once changed, it will always flag it when uou access the project. I suggest ignoring it if this is how you want your project to work.
Cheers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you want to fix it,
make sure you do not change any settings in the permission scheme.
Cheers
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.