I was wondering if there is a way to restrict creation of an issue type based on which role or group the creator is in.
For example, I want only Developers to be able to create a new feature or enhancement.
Hi, this isn't possible for OnDemand. Only the downloadable version can do this.
There was an issue for this: https://jira.atlassian.com/browse/JRA-5865 but has been resolved as won't fix.
Discussion: https://answers.atlassian.com/questions/33259/permission-to-create-specific-issue-type?page=1#33270
Yes, this can be done out of the box, Peter. First, create a group containing only the developers you want to have access to creating this type of issue. Next, on your workflow for that particular issue type, go to the origination step for the worklow - for example, 'Create Issue'. Add a validation step of type permission and select the group you created in the first step above. of course, you should test it to assure it's working correctly prior to publishing the change (if you don't want to cause potential problems with your users). Anyone not in this group has no access to creating that issue type. They simply would not see it in the dropdown.
Technically, there is a "hack"ish work-around. You can add the group/s to a permission scheme setting (e.g., Set Issue Security, or something you're not currently using), and then add a Validation to the Create transition of the workflow for that permission (which is available in OnDemand).
Hello,
Could anybody point me to the solution for the downloaded version of JIRA?
Cheers & best
Plugin / JavaScript
I recently created a plugin that might help you. I'm open for suggestions to make it better. Cheers.
Another option is to use the free Script Runner add-on. That adds the option to add a simple script as a validator on the Create transition. With this you could add the following validation to a transition is an issue-specific workflow:
import com.atlassian.jira.component.ComponentAccessor def groupManager = ComponentAccessor.getGroupManager() groupManager.isUserInGroup(issue.reporter?.name, 'some group')
Wilton's solution is more elegant, since (if I'm not mistaking) does not even offer the user to create an issue of a certain type. This solution will show an error when the user tries to submit an issue of the type he is not authorized for.
Hi Wilton,
Would you plugin work on JIRA 5.2.X version ? I've been looking for this kind of features for years !!
Thanks for your reply
Would you plugin work on JIRA 5.4.X version ?
Hi there,
unfortunately not. You should seriously update your JIRA.
This is excellent thinking. Hacky for sure but very excellent.
I don't see an option to add validators based on groups. Can you post a screenshot? (probably not since this post is 3 years old!)
The permissions validator no longer contains an option to specify a user group; you may only specify a permission (e.g., Create Issue) which is useless since this would deny the person from creating any issue type.
That's what I thought. It looks like using Script Runner is the only option. Otherwise you need to create a separate project
Hi
I am new to script runner and if I wish to put multiple groups in the below line , what should be the syntax ?
groupManager.isUserInGroup(issue.reporter?.name,
'some group'
)
Thanks !
I can see that this is an old question, but I had the same today. I put my solution here for anyone's benefit.
There is a suitable validation option called "Users in a field are/aren't in a project role".
So the steps to set it up:
- Optional: create a JIRA (security) group (say "Special Users Group").
- Create a role (say "Special Users Role") (see How to add project roles)
- Update your workflow
– Select the Create Task transition, and add a validation step
– Use the "Users in a field are/aren't in a project role" validator
– The "Special Users Role" should show up under the "Selected project roles" section
– Fill in validator properties as needed
- Assign your users to the "Special Users Role", optionally via the "Special Users Group".
Hi Balint,
I do not have the "Users in a field are/aren't in a project role" validator option, although I do have defined roles associated with the project. Any advice as to why this would be happening? I am using the cloud-based version.
Thanks.
hi,
Thanks for the code. What if I need to add a condition for issue type? Two of my issues use the same workflow action. So how do I modify your script to trigger only if the issue type is lets say "User story"
I can't seem to get this working. Any suggestions?
What I did on the 'create' transition in the workflow specific for issue type Idea:
Nonetheless, anyone with access to the project can create an issue of the issuetype Idea.
@[deleted]Try running the Permissions Helper - https://confluence.atlassian.com/adminjiracloud/using-the-permission-helper-868982879.html - to see if that lists anything that helps understand what permissions the user has access to that they should not. Almost certainly, there's another permission or role that the users have access to granting them greater access than they should have. It's just too wide open of a scenario for me to help with without having access to your setup.
Also, you may have just been using a single user as a quick test for this solution, but I always recommend that Permissions be tied only to Roles, and Roles tied only to Groups. This makes it easier to manage permissions by making sure a User is in the correct groups. It also makes the traceability easier to follow to understand a user's permissions.
Hopefully, some of that helps!
With Workflow Enhancer for Jira you can create a Universal Validator that checks [groups] user is in, evaluating to true or showing a custom error message to user.
Hey, this sounds great. Can you point me to an example of how to formulate this validator ? I want to check that the user belongs to the group INT_ECO if he wants to create an issue of a certain type.
In my case it was the on-premise version, maybe that1s the difference.
@Alec Mishra
Hi Mishra,
i'm also facing same issue do you have anyupdate on that.
Might not be exactly what you're looking for, but we've just achieved this by creating a workflow for each of the task types. We can then apply different validators to to each workflow to ensure only certain groups can create certain task types.
This means our API can create Tasks, but users cannot. However, uses can create Sub-tasks on the tasks created by the API.
It's a right faff but it works and we refuse to pay for extra plugins for things that should really be built-in from the start,
Know this is an old thread - but I had the same dilemma and solved it by adding a 'Universal Validator' on the Create transition....
Hi,
I solved this issue using Scriptrunner's behaviour, used below code in initializer and it showed Issuetypes based on logged in user, you can validate user against project roles or even groups
import com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.security.roles.ProjectRoleManagerimport static com.atlassian.jira.issue.IssueFieldConstants.ISSUE_TYPEdef projectRoleManager = ComponentAccessor.getComponent(ProjectRoleManager)def allIssueTypes = ComponentAccessor.constantsManager.allIssueTypeObjectsdef user = ComponentAccessor.jiraAuthenticationContext.loggedInUserdef issueTypeField = getFieldById(ISSUE_TYPE)def availableIssueTypes = []//use this def and if code to check project roles/*def remoteUsersRoles = projectRoleManager.getProjectRoles(user, issueContext.projectObject)*.nameif ("Testers" in remoteUsersRoles){availableIssueTypes.addAll(allIssueTypes.findAll { it.name in ["Task", "Experiment"] })}*///use this def and if code to check groupsdef remoteUsersRoles = ComponentAccessor.getGroupManager().isUserInGroup(user, "jira-administrators")if (remoteUsersRoles) {availableIssueTypes.addAll(allIssueTypes.findAll { it.name in ["Task", "Experiment"] })}else {availableIssueTypes.addAll(allIssueTypes.findAll { it.name in ["Task"] })}issueTypeField.setFieldOptions(availableIssueTypes)
Hope this helps.
Regards,
Priyanka
Hi Priyanka, good work.
Could you help with the code if Current user belongs to both Users and Developers roles, therefore both the above sets of issue types should be available
This link gives the code but the behavior is not as expected in the screen shots added below "Restricting Available Issue Types"
https://scriptrunner.adaptavist.com/5.5.0.3-jira8/jira/recipes/behaviours/restricting-issue-types.html
Hi Arun,
Thanks, Happy to help , though not sure what you want to achieve. Do you want to validate that if the user is part of both Users and Developers group then he should see Bug and Task issue type else he should see remaining ones?
Let me know, I will try to code accordingly.
Sure, I have 3 Issue types ( Defect, Enhancement and Documentation) Defect has to been seen by developers only group but few users also are users and developers so they should all 3 (similar in the picture) and the code is restricting the dual group user to not see all but just 2
Thanks,
Arun
I may be missing something obvious here...
The best way to block any transition in a workflow is to add a condition.
However, in Jira 8.x (and probably earlier), the Create transition does not support Conditions.
So the other option is to create a validator that will fail. This is fine and dandy, but it means that the user will get the issue creation screen, will fill all the mandatory fields (and others) and then, when she clicks on the Create button, the operation will be rejected.
That a really bad UX.
It is and it gives the wrong error message. For example if you allow to use create transition only to people who have "delete issues" permission, then on issue creation they will get an error saying they don't have permission to delete issues. That would be really confusing to the end user.
Too bad that it doesn't support conditions as there would be an option to add helpful text when condition is not met.
That is not in Cloud, right?
It looks like you're new here. Sign in or register to get started.