Using Behaviours you can easily restrict priorities and resolution values by project and/or issue type, or anything else such as current user groups or roles.
This is only half the story though, as you can only restrict priorities and resolutions to ones that actually exist. So, if for instance, you create new resolutions that make sense for a systems administration task, the challenge is in making them invisible for all other projects or issue types.
For resolutions, the supported solution is to modify your workflow to use the
jira.field.resolution.include property. However this doesn’t scale well when you have very many workflows. If you do, you should seriously consider writing a script to update all your workflows.
Restrict by Workflow Action
Let’s take a simple example which doesn’t suffer from these problems. Imagine a workflow where we have an end-state that represents something that won’t be fixed, so we want to prevent use of the resolution Fixed when entering that state.
Note that you could use workflow properties above, however that stops you using a common action for resolving, which you should aim to do to reduce the multiple maintenance problem. This is also more flexible, as it lets you change the available options depending on the user’s role etc.
In this case we have a transition called Terminate, and we restrict the resolutions only to those that don’t imply the issue is "fixed".
Note the use of
setFieldOptions. This has two forms:
a Map object, where the keys are the IDs of the resolution (or priority, version, custom field option, etc), and the values are the strings that will be displayed in the UI
pass a List (or any Iterable) of Option objects, or ProjectComponent, Version, Project, Resolution
Apply this script as an initializer - it doesn’t depend on any other field.
Restrict Priorities by Group
In the following example, we restrict users who are not members of the group jira-developers to being able to use anything but the two highest priorities.