Bill Sheboy Expert

Hi @serge calderara In order to transition the issue with an automation rule, I believe you need the specific status value's id. To get that from the name you would need to call the REST API to get all of the status values for the project, and then grab the one which matches your name. If you want to try this with Jira…

Hi @Salim Bouassida As Curt noted, your rule has JQL in the scheduled trigger. And for Jira Cloud, this mean it will try to execute for each issue. Two possible solutions are: * better solution: trigger your rule on "sprint started" instead of a schedule, and send the information using {{sprint.goal}} as each of the…

Hi @Pratibha Tambakad -- Welcome to the Atlassian Community! I recommend first talking to your Jira admin to learn what addon you have, as this is not possible with out-of-the-box features. If you have one of the scripting addons or automation rules, your admin can help you implement this use case. Of note, please consider…

You are on the correct track...And if the original is not working for you with CMP there is still a problem with your rule/Jira site, which I suggest you report. The work-around pattern would be this: * action: lookup issues with JQL for a specific category, such as Improvement * action: create variable* name:…

Hi @Gentrit Cerimi Adding to Stefan's answer... Smart values are name, spacing, and case-sensitive. When in doubt of the exact smart value to use for a field, please try the information in this how-to article: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/ Kind regards, Bill

Hi @Urmo Adding to John's answer, please the documentation on the actions Comment on Issue or Log Action for more details on this: https://confluence.atlassian.com/automation/jira-automation-actions-993924834.html Kind regards, Bill

Hi @aravind1516 Adding to Alex's answer: are you asking about 4 calendar days or 4 working days (e.g. Monday - Friday)? Kind regards, Bill

Hi @Andrea Kargodorian -- Welcome to the Atlassian Community! With a rule of this type, which branches to any issues with the same parent epic using JQL...Have you confirmed that the date of the trigger issue is not also changing? If it is, you may want to modify the branch to exclude the trigger issue from the results.…

Hi @Sam Harding Would it surprise you to learn that smart value, list filtering does not currently appear to work with team-managed projects (TMP) as compared to company-managed projects (CMP)? Please see this…

I would advise against testing the full {{lookupIssues}} inside of iterating on that...which I why I split it into the two parts: no issues found and some issues found. And...I think I figured this out: are you using a team-managed project (TMP) or company-managed project (CMP)? When testing with CMP it worked for me...but…

Hi @Jefferson young Short answer: no. There is a suggestion to add REST API functions for automation rules, making it is easier to automatically backup/document them, put them under source control, etc.: https://codebarrel.atlassian.net/browse/AUT-999 I believe there are other suggestions to add in-line comments to rules.…

Hi @Nikita Rao For many of the automation actions which offer a drop-down list, you can also use a smart value expression. Which action are you trying to use? The "trick" to make this work is: * in the field, type in (or paste in) your smart value... * and it will appear below the field * select it below the field * and it…

Before the send email action, please write this to the audit log and note the results: Count of issues is: {{lookupIssues.size|0}} So your rule would be: * trigger: version released * action: lookup issues * action: write to audit log * action send email

Awesome, and I am glad you figured it out! You can also chain those things together in one step: {{lookupIssues.parent.key.split(",").remove("[").remove("]")}}

Yes, with an automation rule you could add a comment/send a notification, set a custom field, etc. And many of those things could later be searched for using JQL. To learn more about automation rules, please look here to get started: * https://www.atlassian.com/software/jira/guides/expand-jira/automation *…

Just a hunch...would you please post an image of your complete rule one more time? Perhaps we are missing something obvious in the rule's structure/order of components.

Hi @Tony Georgiadis -- Welcome to the Atlassian Community! That is correct, as you are using a diff() with units of measure of milliseconds. Please try businessDays instead to count Monday-Friday, as described here: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/ I do not believe this…

The only other suggestion I have is the rule is "glitched"...sometimes rules get broken by adding/removing components after too many edits. Try disabling this rule, and re-create it from scratch to see the impact. If that still does not help, I suggest submitting a ticket to Atlassian Support to take a look as they have…

Let's try to rule some more things out... What is the JQL you are using for your Lookup Issues, and if you use that stand-alone does it return what you expect? Is the value "Technical Debt" correct, or are there any leading/trailing spaces in the drop-down list value? Have you tried a value other than "Technical Debt"?…

Thanks for those tests! They verify we have both the correct smart value and references to its attributes. Now your prior test was checking for a value of "Test", and I do not see that as one of your options. In only see: New Feature, Improvement, Bug/Defect, and Technical Debt. Please try to change "Test" to one of those…

Hi @keshav mahawar -- Welcome to the Atlassian Community! With the Edit Issue fields action, you may either select the field from the drop-down list OR edit the fields using the advanced edit with JSON. You cannot do both for the same field. Try removing the field from the drop-down selection. Kind regards, Bill

Hi @Romain Lavie Context is key for automation rules... * Outside of a branch, the smart value {{issue}} refers to the triggering issue * Inside of a branch, {{issue}} refers to the the branched to issue When you want to reference the triggering issue(s) inside of a branch, please try this one: {{triggerIssue}} Kind…

Hi @Nikos Vlachos A few things to try, depending upon how much visibility you want. Hopefully this is a temporary condition which the team can improve, and so more permanent solutions may not be needed. * When this condition occurs, consider using right-click and flagging the issue. Those issue will then highlight in red…

Okay, I just tried that with a couple of different custom fields (text and single-select) and it worked for me. Let's try some diagnosis... (A) What is the type of your custom field? (B) When you write the following to the audit after a lookup issues action, what do you observe?…

Hi @Ian Rees If you want the specific date/time of the changes for a version please check the audit log entries, searching and parsing as needed. Access to this information may be subject to your Jira site permissions and how much of the audit log is retained over time.…

Hi @Erika Yamamoto You may want to ping the vendor of that app for this question... The examples in their documentation show several use cases for Automation for Jira (A4J), but not checklist status change: https://railsware.atlassian.net/wiki/spaces/CHK/pages/305528896/Automation+for+Jira And there is another use case for…

Hi @Geoff Worling The change log smart values, {{fieldChange}} and {{changelog}} refer to any issue changes relative to the trigger issue. Your trigger is on Issue Transitioned, so they would only refer to the status values. If you need to refer to the previous assignee, as they change over time and for other trigger…

Ha, and thanks. You are on a roll answering questions, Mark. Well done!

Hi @Joni Johnson You are trying to conditionally update the trigger issue (a subtask) based on the type of the parent, correct? If so, you may access the parent's issue type with {{issue.parent.issueType.name}} to compare based on the issue type name. That would make your rule something like this: * trigger: field value…

Hi @James Wardle Yes, and...to Mark's answer: When checking a lookup issues result for no issues, it helps to use a default value to compare. Otherwise the result will be "null" and that may not match to 0 logically. For example, testing with: * first value: {{lookupIssues.size|0}} * condition: equals * second value: 0…