Bill Sheboy Expert

Hi @Wojciech Wardaszko The documentation for the match() function states that the regular expression search's "underlying implementation is based on Java's Pattern class", however my experience and several other community posts indicate it does not support all of the…

Hi @Akshithrekulapelli First thing: writing automation rules often involves experimentation. I recommend you review the documentation and examples, create a test project in which to write and test rules, and to learn about automation. Once you have a rule working, then copy it to your desired project(s). Please look here…

Hi @Dani Miles As your single-select values contain a number and text, you could extract the number before the operations, such as using the left() function: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#left-int-length- For example: {{issue.customfieldA.value.left(1).asNumber|0}} I…

If you are using Jira Cloud, you may use the Lookup Issues action to do that: * create some JQL using the results of the match() in a Lookup Issues action to compare to issue key * then use an advanced compare condition to see if any results were returned, testing if {{lookupIssues.size|0}} is greater than 0

Thanks for that information! When you are using the scheduled trigger technique I noticed, you do not use a test on currentUser() as that would only evaluate to the "Automation for Jira" user. I will clarify the example rule I posted above for your second question.

Sorry if I was unclear; I submitted a suggestion to add a feature of verbose logging. That does not exist in the Cloud or Server/Data Center versions yet.

I am not following how that can be the case...Would you please post images of * your complete rule, including the details where the query occurs, and * the audit log details showing the execution? Thanks!

Hi @Tobias Three things to try/consider... a) Are you just trying to get the numeric value after that string? If so, please try this expression: {{issue.summary.match("TEST-(\d+)")}} b) Might there be multiple results in your summary? If so, consider how you want to proceed, as that regEx will only return the first one…

Awesome; progress!

Thanks for that information, and I think the problem is your schedule trigger has JQL. Try removing that, and adjusting like this... * trigger: scheduled, with no JQL * action: lookup issues, with JQL for one specific assignee * if/else condition block...* advanced compare condition: testing if {{lookupIssues.size|0}} is…

Hmmm...I believe that should work. Would you please show the JQL you are trying to use in the Lookup Issues action, inside of the branch?

Here is my test rule for cloning from the branch. For this example, I used only user stories. In my test rule, I have two clones: one after the trigger to test cloning the trigger issue correctly and another inside of the branch, testing that the branched-to issue is cloned correctly. I cannot see your entire rule, only…

I just tried this and it worked as I described, where the cloned issue is from the branched-to issue...not the trigger issue. Please post images of the audit log showing the details of execution when the rule does not work as you expect, and of the details of your Clone action.

Other than the issue change history (in the UX and via the REST API) those are the only built-in things. Perhaps check the marketplace to learn if there is an addon app which has what you are looking for in this type of tracking: https://marketplace.atlassian.com/

Nope...it appears the Link action is so much faster than the clone that the re-fetch will not help. Let's do this a different way, moving the link closer to the clone: * trigger: issue created * action: re-fetch (This one is to help the next condition pass, as the issue created trigger can fire faster than the data is…

Please try changing that to include both projects using IN: project IN (10007, MYPROJ) Otherwise no issues will match as they cannot be in both projects at one time.

Hi @Torres, Rodolfo (R.) -- Welcome to the Atlassian Community! As @Ravi Sagar _Sparxsys_ noted, the settings and actual issue history are key in understanding the display of Atlassian's interpretation of a "control chart". For your outliers, I recommend opening up those specific issues and looking at the history. From…

Ah...branches! Branches which could be on more-than-one-issue run in parallel and asynchronously. There is no guarantee of when the branch will finish, up to the very last step of a rule. So the cause of that error is the Link action runs before the issue is created. A possible work-around is to add a Re-fetch action…

Yes, I understood that, and so I suggested branching. Assuming your "templates" are example issues, let's try below. If instead you are using some addon app for "templates", please look at the documentation for that addon to learn what automation capabilities are supported. In your rule, in the Tracking Project, you have…

Hi @Chris F That type of field-to-field comparison is not possible with the built-in JQL features; it is not a SQL. If you have one of the marketplace addons for JQL, this type of comparison may be possible. If not, I would suggest exporting your epics to a spreadsheet to perform the comparison. There are some other…

Thanks for clarifying that information. There is an id for each change in the issue change log history, and I believe you would need to call the REST API to get it: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-changelog-get

Hi, Richard. I am glad to learn you solved this with filter subscriptions. FYI for what I was suggesting, I did not mean to create a branch for each person, as that could be a very long rule! Instead you can use the lookup to drive the branch, like this: * trigger: scheduled with no JQL * action: lookup issues, with the…

Hi @Marco Delgrande Your use case is related, and different from the original question, which had a delta-change for all issues. Yours has relative changes for each sub-task dependency. When you have a new question, I recommend creating a new question and linked back to the related one. Otherwise only the people following…

Hi @Scott Lai Would you please post images of your rule and the audit log details? Those may provide context for what you are observing. Thanks! Until we see those... One work-around would be to define a created variable before the if/else block, let's name it varResponse. Inside of the block, re-define it with the same…

Hi @Inna S For a question like this, please post images of your rule and the audit log details showing the execution. That will provide context for the community to offer suggestions. Without that information, I wonder... Your JQL references a Jira project. Is your rule defined in a different project? If so, the rule…

Thanks for the additional details. I do not believe that would be possible with the built-in features.

Thanks for the explanation, @Simmo 

Please post images of your automation rule and the audit log details showing the execution and error. Those may provide context to help explain this symptom.

That information appears to be from some other tool, or an addon app to Jira Cloud. If it is an addon app which has added custom fields to Jira, you could find the smart values for the fields using the information in the how-to article below, and then reference them in your automation rule.…

Did you look at the link I provided, which provides an example rule and the supporting JSON? For your use case, you would also include information from the parent issue's components.