Best way to handle reopening and resolving of tickets when the remote projects do not have the same workflows?

General Questions
, ,
1

Originally asked by Micah Figone on 22 July 2020 (original question)

Setup:

  • Local Jira cloud connection
  • Several JSD projects with various workflow and status configs
  • Many JSP projects with various workflows and status configs

Main Use Case: Employee submits tickets through JSD project. Each JSD project has a global exalate transition that uses a project picker to define what the destination project is. The incoming sync is only set to sync when the ticket is transition to Done and sets the remote to Done with a resolution of Done.

New Requirement: When either the JSD or JSP ticket is reopened we would want to do the same with the remote ticket.

Normally I would just put in a workflow map for this but this is not scalable as there are different statuses on both sides to map to. Some projects in JSP would go to backlog… Some would go to Open, some would… etc. And same on JSD.

My thought is to add a global transition to the major workflow templates that would be named the same across them all (eg. Exalate Reopen) and put an exalate condition on it. But what i dont want to do is make the huge map for when it gets triggered and by what per project.

Is there a way to say when the resolution is cleared call the remote “Exalate Reopen”? Then I dont have to worry about the changing the code ever when new templates come online. I would just ensure that there is the “Exalate Reopen” transition there.

2

Answer by Francis Martens (Exalate) on 23 July 2020

Sure - this is the best approach for this use case.

By calling

workflowHelper.transition(issue,“Exalate Reopen”)

You will trigger that transition independent from the type of workflow

Bonus is to hide this transition using a group condition, check the details here

Comments:

Micah Figone commented on 23 July 2020

How can you detect the resolution field being changed/cleared?

Francis Martens (Exalate) commented on 23 July 2020

there is an object ‘previous’ which contains the message before the last sent from the other side.

For instance

if (previous?.resolution?.name != replica.resolution?.name) {       	
     // do something 

}

Note that in case of firstSync, previous == null - that’s why you have to use the safety operator on the previous object.

Not sure if it makes sense. Let me know