Workflow no longer functioning as intended

[Jorge Parrales]

JIRA Version 7.5.0

This morning, it was brought to my attention that a key component of our workflow was no longer functioning. I have not yet been able to uncover why. Our workflow is configured so that when an issue is created, it goes into "Open" status, which is our backlog status. Optionally, when creating an issue, our users can update a custom field (radio button) on the create screen titled "Backlog Override", changing the value from Backlog to Ready for Development. Doing this triggers a post-function to transition the newly created status from Open to Selected for Development. This feature worked successfully until this morning. We had not yet updated from 2.2.42 to 2.2.43 at the time we discovered this. The problem did not go away after updating the plugin either.

While investigating, I uncovered another part of the workflow no longer functioning as intended, which is also related to writing statuses or executing transitions with a post-function. In this case, our subtask workflow is configured in such a way that when transitioned to Peer Review, a linked Peer Review subtask is automatically created. In the event that the assignee of the original subtask decides to preemptively reopen their issue (in case they discover they messed something up before their peer discovered it), it triggers two separate post-functions, the first of which moves the peer review subtask into "In Progress", and the second which moves the same peer review subtask now into "Closed" status with "Rejected" resolution. Thought this feature worked successfully previously, it now only fires the first post-function to move the peer review into progress. Alternatively, if the peer review is already in progress, it will then fire the second post-function to move the peer review into closed with rejected resolution. Essentially, the workflow seems to no longer want to change the status of the same subtask twice within a single post-function. I wouldn't have thought much of it except for the fact that it used to work.

The second issue isn't a big deal to me. I can easily remedy that by making a hidden transition from open to closed statuses on peer review subtasks which is fired when the original subtask is manually reopened. But I did bring it up because it IS a function that no longer seems to work and because it felt possibly related to the first issue, which is a much much bigger deal for us. A tremendous key to our operations has to do with extensive backlog grooming sessions, which will only become more timely and complicated if we are having to filter through items that never belonged in the backlog to begin with. Any help you can offer would be greatly appreciated.

Here is the configuration of the "Create Issue" transition for standard issues.

This is the configuration of the "Reopen transition for subtasks

I am also attaching the logs for our instance from around the time I attempted to create a test issue with the backlog override field set as Ready for Development and it failed to transition the issue into the next status (About 9:41 or 9:42). It does not appear that there are any errors registered in the logs....it's just not executing the transition. (You'll notice tons of error related to a JWT calculated field titled "Time in Current Status". This is unrelated and unfortunately happens every time we create an issue, but isn't critical and it always calculates successfully into every other status.)

Last note: There are at least 5 other places within our workflows where the Issue Status or Execute Transition virtual fields are set with a post-function, and they are all working appropriately. Which is why it seems like this error is specifically related to writing two statuses on the same post-function (no status to open to selected for development on issues, and then selected for development to in progress to closed on peer review subtasks), though I can't prove it.

[Fidel Castro Armario]

Hi @jparralesAIL,

Try the following changes:

1. Transition "Create Issue": use the following setting rule: (Ready for Development)Selected for Development : {delay=1500}
2. Transition "Reopen": select "Execute transition (delayed execution)" as target field for first post-function, instead of "Execute transition"
3. Transition "Reopen": use Approve/Reject : {delay=1500} as source value for 7th post-function.

You can try only modification 2, and if it doesn't work, you can implement also modification 3.

Suffix : {delay=1500} will make the delayed transition execution to be carried out 1,500 ms (i.e., 1.5 s) after transition has ended.

In relation to errors in the log caused by the Calculated Number Field, please, attach a screenshot with the configuration of the field.

[Jorge Parrales]

@fcarmario

Thank you for your excellent suggestions.

As the Create Issue problem was the most pressing and critical for our operations, I immediately implemented the 1st suggestion on Friday morning, and testing did show that it resolves the issue. Thank you very much for your help on that.

I have not yet tested your 2nd and 3rd suggestions, but will do so this afternoon and will update this issue accordingly. I will also provide a screenshot of the Calculated Number Field configuration at that time.

[Jorge Parrales]

@fcarmario

After testing suggestions 2 & 3 (first, just 2, then also 3), the issue was still only transitioning through the first transition and not the second. I then updated the first post-function's target field as Execute transition instead of with delayed execution, and then added the {delay=1500} suffix to the 7th post-function, and that time the test proved successful. So here is my final, correctly functioning configuration on the Reopen transition.

As for the Calculated Number Field, here is the configuration I am using for that.

Thanks again for your helpful suggestions!

[Fidel Castro Armario]

I'm glad you achieved to solve the problem. I close the issue. Please, reopen it if you need additional support on this issue.

[Jorge Parrales]

Thanks Fidel

Just out of curiosity, are you able to explain why I am getting so many error logs regarding the Calculated Number Field?

[Fidel Castro Armario]

Hi @jparralesAIL,

Sorry, I forgot to answer your question about the calculated field. Now, I do it:

The problem is that while issue is being created the field is being evaluated but we still don't have a transition, so the result of evaluating sub-expression last(timesOfTransition("", %{00016})) is null.

We can solve the problem by replacing sub-expression last(timesOfTransition("", %{00016})) with sub-expression min([last(timesOfTransition("", %{00016})), {00057}]).

Try the following expression in your "Calculated Number Field":

{00057} - min([last(timesOfTransition("", %{00016})), {00057}])

You can also use the following alternative expression:

last(timesOfTransition("", %{00016})) != null ? {00057} - last(timesOfTransition("", %{00016})) : null

[Jorge Parrales]

@fcarmario

Your suggestion does seem to have resolved the constant error issue. I will continue to monitor our logs to verify, but it does look like that resolved the matter.

Thank you!