I am basically wanting to assign the test case review subtask to a group of QA on a round robin basis and I never want it to assign the task to the person whos designated as the assigned tester. Need a better way to write this since it is having issues.
Hello @Bobby Moyini
What issue are you encountering, specifically?
Can you share with us the details from the rule execution Audit Log showing us what you receive when you encounter the problem?
The issue is that the sub task sometimes assigns to the same person as the assigned tester. The log doesn't show any exceptions or errors.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What type of field is customfield_10102?
Why are you using that field in your comparison instead of "{{issue.assignee}}"
I suggest that you try adding a Log action after the Re-fetch and before the If: Compare components.
In that Log action print the exact two smart values you are using in the Compare.
Then check the rule execution audit log the next time a subtask is created and gets assigned inappropriately. Verify that the log indicates the two smart values being compared are set to the same value.
I suspect that they the two smart values are not going to show the same value.
Why?
You are using the Assign action for the sub-task. That sets the "assignee" field. But in the comparison you are looking at customfield_10102. The "assignee" field doesn't have a "customfield_#####" alias, so I don't think you are using the correct field in your comparison.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That field references a custom field for assigned tester. When we generate QA subtasks we create test case creation , test case review , and test case execution subtasks. What the automation is attempting to do is assign the test case review subtask to someone other than the assigned tester in the parent (the other two subtasks pull in the assigned tester from the parent)
I was assuming the automation was assigning the subtask based on round robin and then checking if that sub task was assigned to somebody that matches the assigned tester field. If it did match it would run the round robin again and assign it to someone other than that person.
I'm open to a better way to do this if there is a good alternative.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for that additional information.
Is the "assigned tester"/customfield_10102 field a User Picker field?
Have you tried adding the Log action I recommended and seeing what it reveals in the case where you get an improperly assigned subtask?
Reviewing the components of the portion of the rule you shared:
1. Is this the creation of the test case review subtask? I am assuming that it is.
2. This changes the focus of the rule to the created subtask.
3. This sets the Assignee field of the created subtasks.
4. At this point {{issue}} refers to the created subtask, so {{issue.customfield_10102}} refers to the "assigned tester" field in the subtask.
{{issue.parent.assignee.accountId}} would be referring to the Atlassian Cloud Account ID of the user specified in the Assignee field of the parent of the subtask.
Therefore this comparison is not comparing the items you mentioned as neither the Assignee of the subtask nor the Assigned Tester of the Parent are being referenced.
If you want to compare the Assignee of the subtask to the Assigned Tester of the parent you would need to compare
{{issue.assignee}} to {{issue.parent.customfield_10102}}
You could add the log action that I recommended previously to double check what it reveals with your current rule when the Assignee of the subtask is set and matches the Assigned Tester of the parent.
Or you can update the comparison in 4 as I mentioned above first. I would still recommend adding the Log action, but you would need print out the alternate smart values I suggested.
I'm not sure that the methodology you currently have is the best. I need to do some research on the round-robin assignment option because I don't work with that one regularly. I'll get back to you if I come up with a better suggestion about how to accomplish your requirement.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you , your suggesiton worked perfeclty! I am not familar with the log action, ill have to try that also on other issues to help troubleshoot.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Here is a link to the Log action documentation:
https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Log-action
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.