Bill Sheboy Expert

Thanks for that information about your rule. As a reminder, your rule will need to be multiple-project (or global) in scope because it is attempting to access issues in more than one project. Please ask your Jira Site Admin to help as they will need to modify the rule settings. I recommend using multiple-project to limit…

Hi @Ignacio Yaselli and @Jehan Bhathena I have not tried using the ADF format with comments in an automation rule's JSON update before. My suggestions are... Perhaps try using the editmeta parameter to determine if there is something incompatible in what you are sending relative to what is permitted: <your Jira…

Hi @Tom Scoggin I believe Jira Server / Data Center can bulk-create issues using the REST API functions. If so, your rule could use list iteration over the values in the multiple-select user field to generate the JSON needed to add the issues, passing that to the Send Web Request action to call the function. Kind regards,…

Thanks, @Tara __ I tried that for a date / time field and it produced the same result as you see for {{now}}, so the variable and diff do not appear to be needed (unless the date calculation scenario is more complicated). Do you have a link to the Tempo worklog article as I did not see that example on the REST API doc page…

Awesome; I am glad to learn that helped!

Hi @Matias Rodríguez Alonso and @Trudy P Claspill Another way to loop a specific number of times in a rule, without using REST API function callbacks, is to build a counter with a text string. Please look here to learn about that…

Thanks for that information. I do not believe the Team field is fully supported that way for automation rules yet: https://jira.atlassian.com/browse/AUTO-525 There are a couple of things to try for a work-around, and let's try the simplest first, changing this "{{issue.parent.team}}" to "{{issue.parent.team.id}}" That will…

Hi @Aftab_Akhtar With your first rule, it seems you want to release the next version. And so the scheduled trigger should have no JQL as the Release Version action will release the next version, by default. There are additional things under "More Options" if you want to adjust that behavior. With your second rule, you want…

The purpose of the work-around is not to update the Summary page. Instead the idea is to: * from the top navigation bar, select Filters > View All Issues * use that JQL, changing the project name, and other things as needed * select Save Filter, giving it a meaningful name * as needed, update the permissions so others can…

Hi @Tường Vi Trần Thị -- Welcome to the Atlassian Community! Although it is possible to change a link type using the REST API functions, instead I recommend removing the existing link and adding the new one. Kind regards, Bill

Hi @James Cullimore -- Welcome to the Atlassian Community! To do that, I believe your rule would need to call the REST API function to get all of the versions for the project, and then use a regular expression with the match() function to filter down to the one you want. If you want to try this, here is some documentation…

Hi @Nate Ballantyne Would you please post an image of the audit log details showing the rule execution? That may help provide some context for this error. Thanks! And also... The Issue Created trigger can fire so quickly some issue data may not be available when the rule starts. This symptom can appear as failed steps, or…

Hi @Sachin Guttala Adding to John's answer: Please look here to learn more about creating JQL queries like this: https://support.atlassian.com/jira-software-cloud/docs/jql-operators/#CHANGED Kind regards, Bill

Hi @das_ sajishg _Contractor_ -- Welcome to the Atlassian Community! What you describe is not a common use of story points, where they are a relative measure which may evolve over time. You appear to want a time-based measure, so please consider using the time tracking, Original Estimate field. Then your rule could use the…

Hi @Norma -- Welcome to the Atlassian Community! First, the status categories in Jira have no substantial impact on the measurement features. Instead I was describing the different flow areas of: * not started, * started processing (i.e., Working), * completed with processing step and waiting for pull to next (i.e.,…

I did not ask if both projects use Epics...Instead I asked "are both issues the rule is trying to access Epic issue type?" If so, that your original idea not be possible as one Epic cannot have another as a Parent. At this point, I recommend submitting a ticket to Atlassian Support to learn how they can help with this…

Thanks for the additional scenario information. When an issue has multiple sprint values in the field, you may filter on the state attribute to find the active one, using conditional logic. For example, this will produce the name for that sprint, or nothing is there is no active sprint assigned to the issue:…

Hmmm...that is quite odd. Here is the rule I was suggesting: * trigger: manual * action: create new issue, setting fields as needed and copying others from the {{triggerIssue}} Without seeing the exact rule action (and audit log details) it is difficult to learn why that would not work for your rule. You are using Jira…

Hi @Tara __ Thanks for your ideas extending this for Tempo worklogs. Does that URL parameter for startedBefore encode to a UNIX Timestamp (i.e., milliseconds after 1 Jan 1970)? For those doing this filtering with the built-in Jira REST API rather than the Tempo one, the function takes a UNIX Timestamp in milliseconds.…

Hi @adrimars I recommend trying this with a regular expression to compare the team name(s) to the sprint name. When there are multiple teams to check, those could be iterated over using an advanced branch. You also seem to be describing this for the "current sprint". What do you mean by that: the active sprint, the next…

Thanks, @Rachel Wright Yes, and...I find Status Categories (and the statusCategoryChangedDate field) can both confuse and help customers: Confuse: teams using Scrum boards may not understand that only the Status value(s) mapped to the right-most board column determine "done" in a sprint, and that the Status Category does…

Hmmm...based on what I know about sandboxes, I thought the limits were the same (as they are linked to the Premium or Enterprise license products for a site). I recommend asking Atlassian Support to learn what they suggest: https://support.atlassian.com/contact/#/

Hi @John Adding to Stephen's answer: One way to identify the correct smart value (or custom field id) for fields is using this how-to article. Essentially you identify an example issue with your field, call a REST API function from a browser, and then search for your field on the results.…

Hi @Maxim Borysenko How would you identify the existing tests for reuse? If you can find them with a JQL query, the rule could branch to them for linking / cloning. Kind regards, Bill

Hi @koutarou ishibashi I do not believe that is possible yet. That general idea of more information about limit-violating rules is included in this very large suggestion: https://jira.atlassian.com/browse/AUTO-36 If you need something more specific for your scenario, perhaps add a comment to that suggestion or create a new…

Hi @Sheri Morita I believe this is caused by JPD being listed as a default in user create for the product roles. This was happening at my last company, and at that time, there was no way for customers to change the defaults themselves. We contacted Atlassian Support and they removed JPD from the defaults for us. Kind…

Hi @Brian Gauthier Do you mean the rule is not triggering or that the value is not updating as expected? If it is not updating as expected... Smart values are name, spacing, and case-sensitive. When an unknown / incorrect smart value is used, it becomes null and often fails silently (depending upon the rule structure). The…

Hi @rneill19 What do you want to do if the custom field is set (or changed) later, after issue create? Kind regards, Bill

Without seeing your complete rule it is difficult to known what happened. First, I recommend adding a write to the audit log after the Create Variable action: summed hours: {{varHoursLoggedThisMonth}} That will show what the rule found. Next, for the issue to which you logged time, review the worklog list of entries, and…

Hi @A A Ron Geister _Trundl_ First thing, I am not using Tempo, and my suggestions are based on what I know about automation rules. With that out of the way... You are referring to this information, correct? https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--issue.TempoAccountField-- Some…