Sub-tasks that have been marked as "Done" automatically change to "To-do" impacting ticket tracking

[Jerin Geevarghese]

I have configured a series of sub-tasks which auto-populate when a ticket is created and match a certain criteria. These sub-tasks are marked as "To-do" by default when opened. After working on one of them and setting the status as "Done", I proceed to work on the next sub-task which is also completed and marked as "Done". Here is where the problem starts:

After moving the second sub-task to done, the first sub-task that has been set to "done" automatically moves to "To-do", when the page is refreshed. And the series continues with random status' of done and "to-do".

Attaching screenshots for reference, please let me know what can be done to help stop this unnecessary sub-task status changes.

[Mykenna Cepek]

I'm having doubts that this rule is the one causing the problem, which you said was:

After moving the second sub-task to done, the first sub-task that has been set to "done" automatically moves to "To-do", when the page is refreshed. And the series continues with random status' of done and "to-do".

The rule you posted has an "Issue assigned" trigger, meaning this rule will only execute when the Assignee field is updated.

So if the problem you're seeing occurs when transitioning issues, then this rule is not causing the problem.

To investigate which rules might be in play, look at one of the sub-tasks which have been moved into the wrong status. In the Detail Pane of the sub-task (on the right side), click on "Automation - Rule Executions" and review the "Recent rule executions". From there you can click through to see rules which have been recently run against that specific issue.

My guess is that some other rule is triggering to change the status.

For example, we have rules set up to help keep the status of Stories and their Subtasks in sync. Those kinds of rules could easily explain the symptom you're seeing (if you have such rules enabled for the project of interest).

[Bill Sheboy]

Thanks, @Mykenna Cepek !  I missed that part regarding the trigger.

__Bill

[Jerin Geevarghese]

Hi @Mykenna Cepek

Thank you for your detailed response. I am trying to follow your advise and look at which automation rules have run, but I cannot find the said  "Automation - Rule Executions" and the "Recent rule executions". Could you please redirect me where to look correctly?

Attaching screenshot of the details tab for the wrong status sub-task

[Mykenna Cepek]

Hmm, my guess is you're not using Jira Cloud (tip: it helps if you tag your questions here with Jira Cloud, Jira Data Center, or Jira Server).

I haven't used the latter two in many, many years; sorry. Maybe under the "More" menu, or hiding elsewhere in an issue (three-dots menu, suppressed by permissions, or not exposed as a "field" on the "screen", etc)? A little help from my DC/Server community colleagues?

Another option (at least under Jira Cloud) is on the Automation Administration screen, where there are tabs to view things like automation "Usage" and "Audit Log" (see screenshot below).

The latter is NOT a rule-based log, but an automation-wide log of what rules have recently run. If you have that, you can make the problem occur, then quickly check that automation-wide Audit Log to see which rules most recently ran.

[Jerin Geevarghese]

Hi @Mykenna Cepek

Thank you for your response. You're right, this one is under setting and audit logs. I tried to re-perform the action and unfortunately, I dont see any names of the rules executed using other automations rules, I do see some errors - not sure what it exactly means though.

Thanks & Regards,

Jerin

[Jerin Geevarghese]

[Mykenna Cepek]

It looks like only some of the "Action details" are shown above. I only see a couple of notices that look like warnings.

Can you revisit this same execution (match the timestamp) and show the rest of the "Action details"?

[Mykenna Cepek]

The two warnings shown above, "Unknown fields set during create", suggest a (separate) problem with the subtask creation components.

Those warnings identify a "Current Status" field, aka "customfield_15900". Have you researched and/or fixed that problem?

The warning suggest that you "Check your custom field configuration", which is a bit ambiguous. The custom field is probably fine. The field configuration is likely suspect. Ensure that Field Configuration(s) used for this project allow that custom field.

[Mykenna Cepek]

Also, the screenshot above is the Audit Log for this rule. That's not what I was suggesting that you review.

There is a different Audit Log that is global for your Jira instance. It shows all the rules recently executed. Have you found that? It's where you would be able to see what other rules might be triggering around the same time as this rule runs.

[Jerin Geevarghese]

Hi @Mykenna Cepek,

Thank you for your response! I have not found the audit log you suggested so far. Probably will ask through another thread in the community here and research before performing the steps mentioned to exactly find what we're looking for.

Thanks again and appreciate your support :)

Kind Regards,

Jerin 

[Mykenna Cepek]

Still would help to know if your Jira is Server or Data Center (and which version) or Cloud.

[Bill Sheboy]

Hi @Jerin Geevarghese 

In your branch of sub-tasks, have you considered adding a condition to check if the issue is (or is not) in a particular status before transitioning to "to do"?

For example, you could add a check that the status is not equal to done.

Kind regards,
Bill

[Jerin Geevarghese]

Hello Bill! Thanks for prompt response.

No I did not consider this as I wanted the sub-tasks to be viewed as "To do" first and then worked on, how can it help though?

where do you suggest I place this - in 1 or 2 (image attached) 

[Bill Sheboy]

In each location where you branch on sub-tasks and try to transition them, please try this:

• branch: on sub-tasks
  • condition: status not equal to done
  • condition: status not equal to "to do"
  • action: transition to "to do"

[Jerin Geevarghese]

Hi Bill, 

Thank you for your response. I tried to branch the sub-task out by adding condition: status not equal to done

But this does not reflect for the old tickets. Is it only applicable for the new tickets or is it that this solution does not help?

Thanks,

Jerin  

[Bill Sheboy]

Jerin, let's pause for a second to confirm something please:

1. Are you trying to create a subtask and then transition that new subtask to "to do"
2. Or something else

If it is #1 and only the new subtask needs to transition, you can change to branch on most recently created issue, and the problem with altering other "done" subtasks should stop happening.

[Jerin Geevarghese]

Hi Bill,

The sub-tasks are already created (not looking at creating new one's additionally) - with the status "To Do", when an assignee is assigned.

I wish to transition the status of these pre-populated sub-tasks to "done", and let it stay as "done". Rather it switches back to "To do"

Hope this clarifies your doubt?

[Bill Sheboy]

In none of your rule images do I see issues transitioned to "done" by the rule.

Would you please try to post your complete rule as one image?  That will confirm that we are seeing the same thing as @Mykenna Cepek and I try to help you.  To do that, you may need to shrink your browser zoom, grab the image, and crop/scale it back up.  (Or use a screen capture app which handles browser scrolling.)

Thanks!

[Jerin Geevarghese]

Hi Bill,

Please find attached the long screen print as requested. Hope this helps!

Thanks,

Jerin

[Bill Sheboy]

Thanks for your complete rule image, Jerin.  

It does appear you are repeatedly creating new subtasks for the trigger issue, and then transitioning them to the "to do" status.  All except the last one, which you leave in whatever the initially created status is.  (perhaps backlog?)

Again I recommend you change each branch to just work on the just the most recently created issue as that is all you appear to need.

• action: create sub-task
• branch: on most recently created issue
  • action: transition to "to do"

This should speed up your rule and eliminate the need to test for the "done" status of other subtasks.

If that does not help, I am at a loss of next steps.  And at that point I'm interested what @Mykenna Cepek suggests.

Thanks!

[Jerin Geevarghese]

Hi Bill,

Thanks for the response. I tried to recreate what you mentioned on branch: on most recently created issue, unfortunately the status' still flip unnecessarily.

The trigger issue for assignee change takes places only once for our business case, hence it made sense to trigger this for all sub-tasks to be pre-populated. The last sub-task is an optional one, hence left it to Open - to use only if needed.

Thanks for the support so far! 

Kind Regards,

Jerin 

[Bill Sheboy]

You describe...

• When you change the branch to most recently created issue
• Some of the "done" issues still change to the status of "to do"

Then something other than this rule is changing the issues.

Please find an example issue moved from "done" and look at the change history to learn which user made the change:

If that user is the automation user, it is another rule.  Talk to your Site Admin and they can help you find the site's audit log for automation to learn which rules were running when the change occurred.  Together you may investigate why the subtasks are changing.