Track a moved ticket (no key change)

[I-Ming Chen]

I'm using a custom ScriptRunner script to track when a ticket moves from one type to another. The key does not change but merely the type does (type being a sub-category of the project).

// Handle for our ticket
Issue issue = event.issue

def eventTypeManager = ComponentAccessor.getEventTypeManager()
def eventTypeName = eventTypeManager.getEventType(event.eventTypeId).getName()

I do see that it triggers eventTypeName = Issue Moved. But I'm writing a post-function script that isn't listening to events; it's tied to transitions.

1) Is there a way to identify this trigger in a post-function script?

2) Can I even tie a ticket move to a transition?

3) Is there a different/better approach I should take?

I've read a bunch of posts regarding transitions but nearly all of them deal with next possible steps which I'm not interested in. I want to know what got our ticket to its current moved state.

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

You have already answered a lot of your own question!  Issue move is not a transition, as you say, it is a structural change to an issue.

It can't even be done as part of a transition, because it could rip out the current workflow and replace it with another one, which will never end well.  We have all seen cartoons with people sitting in a tree sawing the branch off on the side nearer the trunk.  It can't work.

So...

1) Is there a way to identify this trigger in a post-function script?

No, because the issue edit/move event is not part of a workflow.  Post-functions run as part of a transition in a workflow.

2) Can I even tie a ticket move to a transition?

No, as above

3) Is there a different/better approach I should take?

Yep, write it as a listener instead.  Listeners react to events like edit and move.

They are different to post-functions, in that you usually need a little bit more work to script/configure them to only react to the right events, but you can think of them as post-functions that happen outside transitions.

The other thing you need to think about in a listener is "what issue am I working with?"  With a post-function, the current issue is directly available as an issue object, but in a listener, a script does not have that.

But this is not hard to solve.  You can write listeners by pasting post-function code into them, and just adding

def issue = event.issue

So that they know what issue to work with!

[I-Ming Chen]

That's kind of what I was thinking this was going to lead towards. Luckily I had already written the script as a listener when I first wrote the script as a test. Shouldn't be too much of a lift for me. Thanks for sanity checking!

[Florian Bonniec]

Hi @I-Ming Chen 

Why do you want to use a postfunction ? What do you want to do with this information ?

Best way to catch issue move is to use a listener on this event, then you can use this listener to set a customfield, label or issue property then use this stored information to process the information if it's relevant later in the WF process.

Do you want to check a move or an issue type change ?

If it's just the issue type change you can write a postfunction that look in the issue history to see if the issue type have ever change. For that you can use ChangeHistoryManager.

https://docs.atlassian.com/software/jira/docs/api/7.6.1/com/atlassian/jira/issue/changehistory/ChangeHistoryManager.html 

Regards

[I-Ming Chen]

I'm using a post-function because the script only runs on very specific ticket types and transitions. The idea is to do some external API calls as soon as a ticket of the ticket type has been detected. The script is working fine for all other transitions I have it targeted for but I'm having trouble figuring out when the ticket first shows up on a non-create.

I did some prelim tests on ChangeHistoryManager but I'm not skilled enough to know how to get useful info out of it. This is what I've tried so far:

def changeHistoryManager = ComponentAccessor.changeHistoryManager

def lastTransition = changeHistoryManager.getChangeItemsForField(issue, 'status')?.last()
myLog.debug("Maybe last transition?:")
myLog.debug(lastTransition)

def revTransition = changeHistoryManager.getChangeItemsForField(issue, 'status')?.reverse()
myLog.debug("Transition?:")
myLog.debug(revTransition)

DEBUG [Log]: com.atlassian.jira.issue.history.ChangeItemBean@47379705[fieldType=jira,field=status,from=10618,fromString=Validating,to=3,toString=In Progress,created=2022-10-05 16:16:59.133]

DEBUG [Log]: [com.atlassian.jira.issue.history.ChangeItemBean@3a5e20bf[fieldType=jira,field=status,from=10618,fromString=Validating,to=3,toString=In Progress,created=2022-10-05 16:16:59.133],
com.atlassian.jira.issue.history.ChangeItemBean@120f28f8[fieldType=jira,field=status,from=1,fromString=Open,to=10618,toString=Validating,created=2022-10-05 16:16:37.157]]

Still figuring out what this output means or if it's helpful in my quest.

[Trudy Claspill]

Hello @I-Ming Chen 

Welcome to the community. 

Are you using Jira Server or Jira Data Center? And what version are you using?

What do you want to do after you discover that an issue has changed Types?

[I-Ming Chen]

Server. Version 8.20.12 I think.

I've written some Java Groovy that processes info from the ticket and makes some API calls to another system for custom integration. However, I must trigger my script immediately when the target ticket type is first created.