Make Jira workflow transitions react to project property changes

Learn how to create workflow transitions, conditions, validators, and post-functions that work differently depending on the context of the project. If you’ve ever wanted to block the creation of issues for certain projects until they are greenlighted, you’ve come to the right spot.

Jira magic is workflow magic

How is it possible that Jira is so adaptable to almost any type of knowledge organization, and yet it allows to create robust processes that people actually follow?
Many of the magical powders come from workflows:

Workflows can be shared between projects, supporting standardization.
Yet they are endlessly customization.

Workflow customization has many parts, including the possibility to add any number of status, and design how statuses are interlinked with transitions.

But that’s not nearly all! In fact, the most sophisticated area of workflow configuration is, no doubt, buried in the transition options: properties, triggers, conditions, validators, and post functions.

Conditions, validators, and post functions look at the issue

Conditions, validators, and post functions happen at different moments of the transition, but they are similar in a very basic way: they all look at the information stored in the issue and its context to restrict the transition (conditions and validators) or make something happen (post functions).

Since the context checked is relative to the issues, it obviously follows that similar issues transition identically in all projects with that workflow.

How to create conditions, validators, and post functions that check for the project

But what if I want to make my transitions sensitive to the context of the project? What if I want to make sure, for instance, that issues can’t be opened in projects that are inactive? Or that an engineer can’t start working on a customer project until the budget for that project has been approved?

Of course, you may argue that there is a way around: by associating inactive projects to a different workflow scheme. There are at least two severe problems with that:

Workflow maintenance is important but should be minimized. Ideally, each project should be associated to only one workflow scheme from its creation. Since only Jira Admins can make these changes, it’s unrealistic to expect them to make modifications of the workflow schemes every time project contexts change (for example, every week).
Jira projects are static and don’t change over time. What changes is the work that they contain. Whoever maintains the workflows would have to check regularly with project leads and stakeholders, or rely on sources other than Jira, to be on the watch for changes in the project status. Making such a sensitive administrative issue reliant on communication between parts of the organization that are often not in the same team seems over the top.

Leveraging Projectrak for workflows that are project-sensitive

If you read the two objections above you’ll quickly realize that the problem is double. To solve it, you don’t only need to make workflows sensitive to projects. You actually have to make projects in Jira dynamic!

Projectrak (formerly Profields) solve both problems:

Thanks to its project custom fields, Jira projects can store data that change over time –either by manual input, with Bulk Operations, or synchronizing to any third-party tool through the REST and JAVA APIs.
Once Projectrak is in your Jira instance, transitions can be customized to look at the current value of any project field.
And finally, busy Jira admins don’t need to update project data, which can be maintained by anyone with the Projectrak admin role

An example of Projectrak project Layout with all the project information organized.

Workflows that listen to project data are more diverse, more dynamic, and ultimately smarter. The challenging part in creating project-sensitive workflows is identifying change-sensitive information that can stimulate the workflow, triggering behaviors that are smart for your processes.

That’s why we’re presenting three common use cases that we’ve seen used at our customers, one for each type of transition option.

For all of them, we’re going to assume the simplest possible workflow so we focus on the transitions without losing the big picture.

Use case 1: Block work until the project is budgeted (condition)

In projects for external customers, it’s not uncommon to start gathering requirements in Jira as part of the tender or proposal of interest, and before a final agreement has been reached between the parties. Restraining your teams to start working on any issue unless the project has an approved budget can prove very useful.

Steps

Select the transition “start working” (between Open and In Progress)
Click on the conditions
Select the Projectrak Value Condition

Depending on your processes, there can be different ways to implement this condition. These are just two possibilities:

There is budget

4) Select the project custom field “Budget” (numeric)
5) Mark the budget different than 0, and add it

The budget is approved

4) Select the project custom field “Budget approval”

5) Mark the equal operator and the value “Yes”

Use case 2: Create issues only when the project is open

Similar in a way to the use case above: you might want to lock down a project so users don’t create more issues. There may be any number of reasons for this: the process behind the project is no longer supported, the application you were developing has been deprecated… or the project has simply been considered a loss of focus.
It’s a good practice to include this validator in all your workflows so you can always lock down a project that becomes inactive.

Steps

Select the transition “Create”
Click on the validators
Select the Projectrak Value Validator
Select the Projectrak field “status”
Mark the equalizer connector and the value “open”

Use case 3: Make issues inherit the current priority of the project

If your teams use boards with information from different projects that compete for limited resources, this trick can expedite prioritization.

The idea is that if projects are prioritized, then you can automate how issues are ranked. Note that prioritizing projects is intended dynamically, i.e.: Project A may be unimportant this quarter and urgent in December. The issues created in project A during this quarter will receive a low default priority today, and a top default priority in December.

The board will then be populated with issues from multiple projects that are already pre-groomed!

Let’s see how to build this one. In this case, we’ll need some scripting.

Steps:

Select the transition “Create”
Click on the post-functions
Select Projectrak Script Function
And here comes the magic! Paste this code into the box:


import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.IssueManager 
import com.atlassian.jira.config.PriorityManager 
import com.atlassian.jira.issue.MutableIssue 
import com.atlassian.jira.event.type.EventDispatchOption 
import com.deiser.jira.profields.api.field.FieldService 
import com.deiser.jira.profields.api.value.ValueService 
import com.deiser.jira.profields.api.field.Field 
import com.deiser.jira.profields.api.field.priority.PriorityField 
import com.deiser.jira.profields.api.field.item.priority.PriorityItem 
  
def PROFIELDS_PRIORITY_FIELD_ID = 6 
def priorityManager = ComponentAccessor.getOSGiComponentInstanceOfType(PriorityManager.class) 
def issueManager = ComponentAccessor.issueManager 
def fieldService = ComponentAccessor.getOSGiComponentInstanceOfType(FieldService.class) 
def valueService = ComponentAccessor.getOSGiComponentInstanceOfType(ValueService.class) 
def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser 

 try { 
    def project = issue.projectObject 
    PriorityField field = (PriorityField) fieldService.get(PROFIELDS_PRIORITY_FIELD_ID) 
    PriorityItem projectPriority = valueService.getValue(project, (PriorityField)field) 
    def issuePriority = priorityManager.priorities 
    .stream() 
    .filter { 
        priority -> priority.name.equals(projectPriority.text) 
    } 
    .findFirst().get() 
    issue.setPriorityObject(issuePriority) 
    issueManager.updateIssue(user, issue, EventDispatchOption.DO_NOT_DISPATCH, false) 
} catch(NoSuchElementException ex) { 
    //The priority of the project does not exist at issue level 
} catch (Exception ex) { 
    //Here you can handle unexpected exceptions 
}

Hint: the use case is about building a contextual repository

Note that this is a bit of a dummy example to cue you into the important takeaway: using Projectrak (formerly Profields), Jira projects can work as repositories of contextual data that can be inherited by issues while varying from project to project.

Imagine, for example, that your company needs a deputy lead for each project component to cover for the vacations and leaves of your main assignee. There’s no place in Jira to do that!

To solve this issue in their change management process, Panasonic created a project layout for component deputies, so every change request would be automatically assigned to component leads and deputy leads for analysis.

Take a look at this video for more details!