Trouble with Ticket Transitions (Script Runner -> Fast-track transition an issue)

[Andrew Wolan]

I am presenting the following two issues because they appear to be similar. Perhaps they are not. In either case, we would like to try and resolve them because they are a bit annoying.

In both cases, we are running JIRA version 5.2.11

Issue 1 – Cause unknown
Sometimes when we transition a ticket, the ticket will enter a weird state in which no one is able to transition it forward to another state. By “unable”, I mean that regardless of whoever logs into the system, their UI will not display any action buttons which to transition the ticket. However, the UI will note that the ticket is in a particular state that the users should be able to manipulate. Furthermore, the “Permissions Helper” will state that the users in question should be able to transition the ticket.

This issue has occurred a few times in the past year. Whenever this happens, we have resorted to making a new ticket and deleting the old one. Is there anything that cna be done to try and salvage the ticket instead?

Issue 2 – Caused by “Fast-track transition an issue”
This issue is similar to the above issue. An investigation appears to point the blame at the built-in script of “Fast-track transition an issue”. Allow me to elaborate.

Whenever a user “Creates” a new ticket, (of the type “Problem Report”,) the ticket is put in the “Triage” state. When a ticket is in the “triage” state, numerous people are able to transition the ticket to some other state.

We are using the built-in script listener of “Fast-track transition an issue” so that when such tickets are created by someone in “Customer Support” group, the tickets are:

• auto-transition to “CE Triage” state
• be assigned to a particular user

When a ticket is in “CE Triage”, only 3 specific people can transition the ticket to a different state.

What we are noticing is that sometimes the script will not properly process the ticket, putting it in an odd state. In particular, what we are noticing is that:

• According to the UI, the ticket is still in the “triage” state.
• According to the ticket “History”, the ticket is in the “CE Triage” state.
• Though the ticket says it is in “triage”, only the people in the “CE Triage” group can transition the ticket.

Is there a known issue with “Fast-track transition an issue”? Is there anything that can be done to correct tickets that enter this state?

[Nic Brough -Adaptavist-]

In both cases, it sounds like you have a transition that has a broken post-function or listener on it. I don't know if the fast-track transition has a bug in the version you're using (if it does, I've not seen or heard of it before)

Whatever it is that is breaking, it sounds like it is leaving the two database tables where Jira handles the position of an issue in the workflow out of sync. One of the functions in the "integrity checker" is specifically there to correct this case, so I would find an issue that is broken, run the integrity checker, and go back to the issue to see if it has been fixed! Admin -> Troubleshooting -> Integerity checker (look for the workflow and status items within it)

If that works, you have a culprit - something is corrupting the workflow data. As I said, I can't be at all sure it's the fast-track, I'd start with a look at ALL the non-system post-functions

[Nic Brough -Adaptavist-]

No, that's not a problem for the transition, it's just cleaning up a filter

If the integrity checker has found nothing, I think we might be into having to go into an intense read of the logs to find out what's going wrong.

[Andrew Wolan]

Ran Integrety checker. It found one invalid filter subscription. (Below.) I'm not familiar with subscription filters, but does this seem like a possible culprit? To me it doesn't seem like a smoking gun we were hoping to find, but the checker did at find something.

Check FilterSubscriptions for references to non-existent SearchRequests

ERROR: Subscription filter with id 10300 is missing its corresponding saved filter and will be removed: FilterSubscription (ID:10300)

[Andrew Wolan]

Ok. Any suggestions on where to begin?

[Nic Brough -Adaptavist-]

I think you'll need to rig up some tests to replicate the the problem, and then read the logs when fast-track transition is executed. You might want to turn up the logging on the classes providing it as well (Admin -> profiling and logging). I'd also have a close look at ALL of the conditions, validators and post-functions on the transitions around where the errors are creeping in.

[Joseba/Jorge Gailen]

Despite this thread is quite old, I'm facing the same Andrew's 'Issue 2'.

JIRA Service Desk 3.1.0

JIRA Core 7.1.0

Adaptavist ScriptRunner for JIRA 4.2.0.5

_Jeo

[JamieA]

hi - is the thing that is being transitioned a service desk issue? Does this happen intermittently or always? If the former, is there a pattern?

[Joseba/Jorge Gailen]

Hi Jaime,

It happens intermittently, but we have been able to catch a pattern for the moment.

In our case, it happens having configured a 'fast-track' post-function configured in the first 'create' transition.

Thanks.

_jeo

[JamieA]

So it always happens for the fast-track that is on the create transition?

[Joseba/Jorge Gailen]

It always happens on the create transition but only on really few issues. Haven't discovered any pattern for those issues yet.

Thanks.

_jeo

[Sandor Krisztian Andre]

Hi I'd like to revive this thread since I have a similar issue.

I have a fast-track transition postfunction (ScriptRunner) on a non create transition.

status 1 -> status 2 has the fast-track postfunction as the last postfunction

When I look into the issue history the transition order is senslessly reversed:

status2 -> status 3 (fast-track)

status 1 -> status 2 (manual)

Another issue is that some of these fast tracked trasitions are then not represented in eazyBI's [Measures].[Transition to] measure, but that may be a separate issue.

Br,

Kris

[JamieA]

Issue 1 can happen where there is an action that has a condition provided by a plugin that's not present. Rather than just that action not being available, it seems that all actions are not available.

But it should happen for all tickets, not just a few.

Agree with Nic re integrity checker - the link from the issue to its particular workflow might be bust or out of sync or something.