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; } } }

Locking down scope in JIRA

keerthi_guntupalli

Hello Everyone,

I'm supporting an ERP program that has completed design phase and is now moving into build and testing phase.

the program team want to prevent users on creating and editing issues at all hirerachy levels except sub-tasks, but at the same time certain people want to have access to create and edit when required.

Also, all the build and testing tasks are planned to bulk upload as standard tasks.

This is mainly to control agreed scope only gets into JIRA.

Whats the best way to acheive this in JIRA?

Accepted answers

All comments

Brant Schroeder

@keerthi_guntupalli Jira spaces and work items use permission schemes to set what permissions a role, group or user has. You can learn more here: https://support.atlassian.com/jira-cloud-administration/docs/types-of-permissions-you-can-grant-in-a-space-scheme/

If a user has the ability to edit or create a work item they will have the ability to do so for they will be able to do it for all work item types. There is no way to restrict it on the delivered product to just Sub-tasks. On past projects we took away individuals ability to create issues in the project and used Jira Service Management as the intake for sub-tasks. This way we could vet the request through a CCB process before introducing it to the project. If you do not have JSM you can so something similar using forms.

As for editing we would remove editing capability allowing only certain permissions like comment to be allowed on work items. We would also use transitions and transition screens to allow individuals to edit certain fields when the issue transitioned on a transition screen. Depending on what you would like them to edit you might be able to change the permission scheme (Assign issue, watchers, etc.) to allow them to do the edit. Most fields will be part of the edit functionality in the permission scheme.

Trudy P Claspill

Hello @keerthi_guntupalli

What type of Space does this concern?

In addition to what @Brant Schroeder mentioned, if the space is Team Managed then there is not a Permission scheme. Instead permissions are allocated based on the Access setting for the space and the Space Roles to which a user is assigned.

Refer to

https://support.atlassian.com/jira-software-cloud/docs/next-gen-permissions/

A possible workaround to prevent creation of certain issue types by certain users would be to add a Rule or Validator to the Create transition of the workflow for that issue type in which you confirm that the user is a member of a Role or Group allowed to create that type of issue. That will show the user a message and not allow the creation to complete.

keerthi_guntupalli

Thanks @Trudy P Claspill , i like the workaround of restrcting through workflow, is there available documentation i can use as aquick reference around implementing this. thanks

keerthi_guntupalli

@Brant Schroeder thanks a lot for your insights, very helpful

Trudy P Claspill

@keerthi_guntupalli

What type of Space/project does this concern?

Click the ... button next to the Space name in the navigation panel on the left. What are the last two lines in the pop-up? It will be something like this:

Software space
Company-managed

Both lines are important. Please be sure to share what both lines say.

Unfortunately I misspoke about the availability of this option as a native solution. Natively Jira does not provide a Validator/Rule that can accomplish this. There are third party apps that extend workflow capabilities and provide features like this.

Do you have access to any third party apps that extend workflow capabilities? If not are you willing to consider a third party app to solve this requirement?

If you are not willing to consider a third party app then I believe the only native solution would involve using an Automation rule to detect that a issue of a particular type was created by a user not authorized to create that type of issue, and then to automatically transition it to a closed/cancelled/rejected status, and optionally send email about this to the creator and/or other people on the team. Technically you could have the automation delete the issue outright, but that is a permanent deletion. The data is not recoverable. It is generally better to change the issue to a closed status so that the data is not permanently lost.

keerthi_guntupalli

Its a company managed project, and currently doesnt have access to third party apps, but like to understand what are those apps, so that i can explore on that as i am looking for stronger reporting capabilities aswell.

Nacho Moreno Ortega

Hi @keerthi_guntupalli ,

My name is Nacho, and I'm part of Decadis.

If using a third-party app is an option for you, I would like to recommend our app, Jira Workflow Toolbox.

You can control which group of users creates the issue by creating a Jira expression validator in a "Create " transition or in the transition in which you want the user not to make changes.

For example, the following expression indicates that, unless the issue is a subtask, the user must be in a specific group to create or transition the issue.

issue?.issueType?.name != "Sub-task" ? user.groups.includes("Group Name") : true

If you have any question on how implement it, please feel free to create a request in our support portal and we will be happy to assist you.

Best regards,

Nacho

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud