Features used to implement the example
- Users in field are (not) in a project role
- Boolean validator with math, date-time or text-string terms
Example: Limit issue creation per role and issue type
A well known limitation of Jira is that it's not possible to set issue creation permissions per Issue Type. We are going to show how to overcome this limitation by inserting a validation in "Create issue" transition in a workflow.
We will show two different solutions based on two different features of Jira Workflow Toolbox:
- Using validator Users in field are (not) in a project role: this solution is suitable when we have a different workflows per issue type, or when we don't want to set different issue creation permissions in a same workflow.
- Using validator Boolean validator with math, date-time or text-string terms: this solution is suitable when we share a workflow among different issue types, and want to set different issue creation permissions per Issue Type and Project Role in a same workflow.
Let's suppose that we want to limit issue creation in a workflow, only to user in project roles "Developers" or "Testers". To do it we will introduce a validator Users in field are (not) in a project role in transition "Create issue" with the following configuration:
Once configured, transition "Create issue" will look like this:
Alternative implementation
Let's we implement in a workflow the following issue creation permissions per issue type and project role:
- Issue type "Bug" can only be create by users in project roles "Users" or "Testers"
- Issue type "Improvement" can only be create by users in project roles "Testers" or "Product Managers"
- Issue type "New Feature" can only be create by users in project role "Product Managers"
We will introduce in transition "Create issue" a validator Boolean validator with math, date-time or text-string terms with the following configuration:
Boolean expression used is:
(%{00014} = "Bug" IMPLIES (isInRole(%{00020}, "Testers") OR isInRole(%{00020}, "Users"))) AND (%{00014} = "Improvement" IMPLIES (isInRole(%{00020}, "Testers") OR isInRole(%{00020}, "Product Managers"))) AND (%{00014} = "New Feature" IMPLIES isInRole(%{00020}, "Product Managers"))
Note that:
- %{00014} is code for "Issue type"
- %{00020} is code for "Current user"
Once configured, transition "Create issue" will look like this:
Other examples of that functions
Users in field are (not) in a project role
Boolean validator with math, date-time or text-string terms
- Block a transition until all sub-tasks have certains fields populated
- Block an epic's transition depending on linked issues status and due date
- Block or hide a transition for an issue depending on its issue links
- Block or unblock a transition after an issue rested a specific time in a status
- Block transition until all sub-tasks are in a specific status category
- Close parent issue when all sub-tasks are closed
- Enforce a field (Select List) to be set when another field (Radio Button) has a certain value (works with any kind of field type)
- Ensure that all issues linked with a certain issue link type have "Due Date" field set
- If field A is populated then, field B must also be populated
- Limit issue creation per role and issue type
- Limit the number of hours a user can log per day
- Limit valid dates for work logs
- Make "Time Spent" field required when there is no time logged in the issue
- Make a custom field mandatory when priority is "Critical" or "Blocker" and issue type is "Incident"
- Make attachment mandatory depending on the value of certain custom field
- Make different fields mandatory depending on the value of a Select List custom field
- Make linked issues, sub-tasks and JQL selected issues progress through its workflows
- Make parent issue progress through its workflow
- Prevent issue creation if another issue with same field value already exists
- Reject duplicated file names in attachments
- Require at least one sub-task in status "Resolved" or "Closed" when "Testing required" is selected in Check-Box custom field
- Require issue link when resolving as duplicate
- Restrict parent issue from closing if it has sub-tasks that were created during a given parent issue status
- Restrict sub-task type creation depending on parent issue status
- Restrict sub-task type creation depending on parent issue type
- Set a condition in a global transition which only applies in a certain status
- Validate a custom field "Story Points" has been given a value in Fibonacci sequence
- Validate compatible values selection among dependent custom fields
- Validate only issue links created in transition screen
- Validate that multi-user picker custom field A does not contain any user in multi-user picker custom field B
- Validation and condition based on time expressions
- Validation based on the value of a date type project property
- Validation on issue attachments
- Validation on MIME types of issue attachments
- Validation on sibling sub-tasks depending on issue type and status
- Validation on the value of a Cascading Select field