I am currently looking for possible solutions to restricts the available issue type in one of our jira projects to certain user groups.
Description:
"Anyone outside COS Jira group should be able to open only the following types of issues in the COS jira project:
COS Standard Service
TOS Standard Service
Incident
All members of COS group should be able to open any kind of issue types associated with the COS schema"
I found that it is possible via Issue level security scheme, and also through scriptrunner. I tried both solutions but not successful. May be a better script in script runner would work or a proper solution using issue level security scheme is also helpful. Please support.
Hi Amal,
I can confirm that the Behaviours feature of ScriptRunner for Jira Cloud can help with this requirement.
We have an example located here which shows how to restrict issue types based on user groups that can be used as an example to create the script that you require.
If you need further assistance with creating a script then I would ask you to raise a support request here so that our support team can assist with this.
I hope this information helps.
Regards,
Kristian
But they can still create issue via API /board issue creation / automation !!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, behaviours only work on views that Atlassian has enabled the UI modifications API for, which are currently the Create Views, Issue View, and Transition View.
They support the issue view in multiple places such as on boards as documented in the page here, but automation would still be able to create issues and work around this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey all - glad that @Kristian Walker _Adaptavist_ found the Behaviours example using Javascript because I was having a hard time looking through Scriptrunner's docs for that. :-}
Re: suggestions from @Piyush Annadate _ACE Pune_ and @Fazila Ashraf to use a validator, I will quote the wise words of @Nic Brough -Adaptavist- from a few years ago:
I do not recommend doing this though, as it's ugly for the users - they enter all the data for their issue, then a validator says "you can't do this" and they have to start again with a new issue create.
I agree with Nic that's an awful user experience. Recommend using Behaviours and maybe use Validator as a "backstop" for the exceptions that Piyush pointed out: "API /board issue creation / automation"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you're open to using apps, our team developed Field Rules – UI Modifications for Jira. It includes a Hide Issue Types rule, which allows you to hide specific issue types on the Global Issue Create view. The rule comes with extensive precondition settings, including user groups, project roles, and even the state of other fields.
It leverages the UI Modification API provided by Atlassian, which allows apps to modify certain screens. Please note that it works asynchronously, so a slight flicker may occur—something to consider when evaluating whether it suits your needs.
I hope it will help
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It is not possible to hide an issue type from the 'create screen'.
The best possible approach can only prevent them from actually submitting the ticket with a validator check. :(
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Amal Johnson
Issue security is applied as when issue is created, but here you want to have restriction during issue creation itself; so concept of issue security doesn't apply here (details here)
Here you have 1 Options:
1. You can have an VALIDATOR for the create transition in the workflow based on 'Scriptrunner script' (since you have that). Just have a validator that user who is initiator (not reporter) is in that group vs not based on issue type.
Ex. Issue type is A & user in Group-A, then they can create; Issue type is B & user in Group-A, then they cannot create.
2. [cannot be done] Behavior cannot be used as in cloud it doesn't perform UI manipulation.
Snippet of script example: https://www.scriptrunnerhq.com/help/example-scripts/Limit-issue-types-based-on-roles-cloud
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your response @Piyush Annadate _ACE Pune_ . But I assume this approach doesn't prevent the users from viewing the issue type right? My preliminary goal is to hide certain issue types in this project for a specific group of people. Only the assigned group should see all issue types.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Approach above would restrict issue creation.
In your requirement - you can have an issue field of Group type populated, as when the issue type matches post issue creation, update the group field with the required (automation or scriptrunner script, but go with jira automation). And prior that, update your issue security to have rule with group custom field as well .
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.