I reviewed the question: Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric s, but I don't think it applies to my case. I am getting the error:
Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric status ID or untranslated name for issues (with current status): DOPI-727 (In Progress - 3)
The rule I have is preventing transition an issue to IN PROGRESS if the issue is unassigned, so it transitions it back to the previous status. The problem I am getting is that sometimes it works and sometimes it doesn't for the same issue. Here is my rule, it seems to be large, but the logic is simple, just we need to consider different scenarios an message based on the issue type:
I highlighted the portion for the subtask. As you can see from the Automation log. Note: I added the edit condition for start date after the log execution, so you don't see this edit condition in the log. Subtasks haves standard workflow TODO<->IN PROGRESS< ->DONE. Allowing backward transition from current status to the previous one:
The first time the condition is triggered the rule successfully executed, when the user transitioned an unassigned issue from TODO to IN PROGRESS:
but the second time (about 15 mins after the previous trigger) failed. The rule was triggered when the user did the same operation. I got the error message:
Here is the issue history:
I highlighted when rule was triggered.
In this case, the workflow is the same, so I don't think there is workflow post-condition or function. The rule works because the first time for the same issue it worked, but for some reason it fails the second time and according to the issue history, nothing specific happened.
I am trying to find any specifics for the second case that justifies the fail, but I am not able to find it.
Any help is appreciated,
Thank,
David
Hi David.
I'd suggest that its probably far more effective to add a "validator" into each of the workflows to check that the "assignee" field is populated when transitioned to "in progress" - rather than allow it to move forward and then automatically transition it back again?
@Tim C thanks! This is a good advice, but then I depend on my Jira Admin, whenever I can, I try to solve it using Jira rule. The thing is that I was not able to find the pattern when it fails, other than it happens usually after a success execution, and the user latter tries again to transition the issue being unassigned. For example today it failed for the same issue after several successful executions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @[deleted]
You could try using "smart values" to capture the change in "status" values to double check on your possible routing options ...
{{fieldChange.fromString}} - Returns the previous value as displayed.
{{fieldChange.toString}} - Returns the new value as displayed.
You can simply record these smart values into the automation log using the "log action" event. This makes easier to track to find these type of slight differences in data between successive executions, etc.
Obviously, all types of data and customfields can be captured...
{{assignee.displayName}} - Returns the assignee
FYI. More info on smart values ...
https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Tim C at the end I asked my Jira Admin for help and we implemented validator in the workflow. This is more stable, and allows to send a popup message advising the user why the transition is not allowed, so I disabled the rule.
I logged the status value, actually I added a condition before roll back the transition to make sure it is a valid transition. Since it happens after several attempts the user tries to do a transition we don't want to allow, but again, I don't see the pattern, because sometimes it happens after the first, the second and third attempt. Something is odd here, and because the rule can fail after the third attempt then I don't see it could be an issue with the rule or the workflow itself, after every successful attempt the Jira issue on the same status, trying to transition to the next one, so why it succeed the first two times and fails the third one for example?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@David Leal, could it happen that when the automation rule started, the issue was already in Done status? It cannot be seen among the issue history events when the In Progress > Done transition happened compared to the rule execution. My guess that one wanted to put the issue into Done status and made the two transitions until there faster than the automation would put it back to To Do status.
Just two remarks:
I like helping people more than warning them, so in a case like this, assigning the issue to the person who made the transition instead of dropping back the status.
When I have to move the issue to a previous status, I mention the person who made the transition. It is easy to miss Jira notifications especially if noone is assigned to the issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Boldizsár Vermes thank for taking the time to review my question. We only allow transition to the next status, there is no way to go from previous status to DONE, we don't allow such transition. It happened only when the rule failed, and it was not possible to roll back the transition, so the user continues until to reach the DONE status, but that is because the rule failed.
I am checking the history of the rule execution and for an issue that the rule didn't fail the first one was execute at: 09/21/23, 02:07:29 pm and the second time at 09/21/23, 02:07:59 pm, so even for this case within the same minute it didn't fail, then in the third attempt fails at: 09/21/23, 08:09:42 pm. Which is weird.
Assigning the assignee the user who does the transition is a good option, but it won't be a good approach for our case, because sometimes is the PO, the BA , or the person who runs the DSU who does the transaction (not the person who actually does the work. It is not the general case, but I don't want to assume that always the person who does the transition should be the assignee. I want also to educate my team that unassigned work should not be work in progress.
The rule is implemented for a program, several teams within the same Jira project, so at the end I have more than 15 people, I need to relay on rules and workflow conditions/validators because reaching each one of them when they try to do a non valid transition is not manageable.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For example just looking to one issue (subtask) that executed successfully several times and then failed. Here the information with the time stamp.
This is the issue history:
Here is the log information in the automation rule:
then the failed execution:
as you can see the rule executed correctly three times for the same subtask, then in the fourth attempt if failed.
as you can see it is a weird situation why it works as expected the first three times then it failed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
HI @David Leal
Think I agree with @Boldizsár Vermes - its probably down to the exact timings and how quickly the rule runs compares to updating the status of the ticket (i.e. probably still at the original status and thus can't be moved back yet).
You could introduce a delay into the automation processing by using the "refetch issue data" event after the rule gets triggered.
You could then use {{issue.status.name}} and {{issue.issueType.name}} smart variables to double check the actual values and then use these as controls in your if/then statements.
As mentioned before - you should record these variables into the event logs to make it easier to de-bug and find these slight variances which aren't being handled in the logic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Tim C that was my first assumption "timing", but the previous successful execution was at 2:14PM and the first railed execution was at 8:09PM, so there is enough time. The refetch action, has no parameters, and as per my understanding the scope is within the rule only, so invoking it before transitioning won't have effect at all, because no changes happened at this point.
You can see that the if-condition checks the status before doing the transition to make sure the issue is at the expected status before making the transition back.
I replicated in a sandbox Jira Environment the rule, to do further tests and even invoking the rule twice within the same minute it doesn't fail.
By accident when I duplicated the rule I had both rules activated and I got the error, because both rules are executed at the same time even the rule prevents a transition from the wrong status status via If-condition, it failed, so that maybe the explanation. Now reviewing the rules I have in my Jira production environment, there is no other rule that does a transition back under the same condition, so I don't know what could happened, but at least similar rules triggered at the same time and doing a backward transition maybe the reason.
I activated both rules again and I was able to replicate the error. One rule executed successfully and the other rule failed with the error I mentioned in the question. The error cannot be avoided even using re-fetch which proves that this action has effect within the rule only. Maybe the error happens under other scenario that occurred in my production environment that I am not able to figure out.
It seems to be a bug, because even the rule checks a valid status before making the transition back, this check doesn't have effect and allows to do a transition back for a subtask that was already moved to TODO due to the other rule.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @David Leal
Btw, you can look at the audit log from the "global automation" (under admin settings/system) rather than under the specific project rule - you'll see everything being run in sequence and would pick up on multiple rules being triggered in parallel (and any further rules also triggered from changes by the inital rules). Duplicated copy of rules could certainly causes problems. Both rules would get triggered but only first would edit ticket and second one then errors as data gets out of sync. Not sure this is deemed a bug.
Also, I think there could be some misunderstanding around the "timings" we were talking about. It's not the difference in the date/time of when the rules get triggered (2pm v 8pm) - but the very slight system time is takes for ticket to complete the post-processing steps which happen on transition and getting updated (especially if there's lots of other workflow processing and/or automation rules running on same event). Sometimes an automation rules can get triggered and runs too quickly while the ticket itself is still being updated. The data reload/refresh issue data event can avoid this situation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Tim C I see, I guess you are referring to some feature only available for Jira Admin, I am just Jira project admin. I will check with my Jira admin. The only option I have is from the list of rules, click on the ellipsis (top right) corner then select: View performance insights, but the view doesn't show what other rules were executated at the same time my rule failed. I know another rule was executed to set start date, but this rule doesn't do any transition. This is what I see:
Highlighted at the time the rule failed in my Jira production instance, but it doesn't offer the sequence of the events.
I consider it is a bug, because of the if-condition I have, it prevents to the transition back from a status other than In Progress:
so if I duplicate this rule, both of them active, now I try to move an unassigned subtask from TODO to IN PROGRESS, both rules are triggered. One rule moves the subtask back, then the other rule should not execute the transaction back, because the subtask is already in TODO status so the if condition doesn't pass, but this is not happening, it gives the error instead.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yeah, global automation is only available to jira-admins.
Both of the rules will be triggered by the same transition event - and both rules are going to match your first condition and probably okay right up to both rules adding the "log update" event - but when it comes to doing the "status" transiton - the first rule will update it and the second rule will error/fail as there's now on option to transition again (as it's already been updated).
Perhaps, I'm guessing you could try adding a "loop" workflow transition from "to do" status back onto the same "to do" status - which may prevent the rule from giving error (as they'll then be a valid transition?).
However, only having a single rule running is the best option.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.