Bill Sheboy Expert

Hello, all! It is possible to filter and sum...but you cannot do that with the built-in lookup issues functions. Instead combine the math operators with filtering and handle the empty cases. For example, {{#=}} 0 {{#lookupIssues}}{{#if(some filter expression)}} + {{some field}}{{/}}{{/}} The leading 0 and the placement of…

With the Jira Cloud version of automation, I do not believe it is possible yet to select those different triggers together. One work-around is to have separate rules for each of the relevant triggering conditions.

Have you tried either using conditional logic to see the reporter when the issue is cloned, or to add an edit of the clone later to set the field (based on your conditions)?

Hi @ADITHI BALASUBRAMANIAN -- Welcome to the Atlassian Community! Without first seeing the specifics of your rule that performs the linkages, I would answer this scenario as: this may be possible. Let's assume your rule uses logic which links one-and-only-one issue to another in a rule, with no branches in the rule. In…

Hi @Dave Furlani This would need to be a global/multi-project scope rule, and as you appear to be on the Premium product plan, the service limits for global rules should not be a problem. Unfortunately rules cannot trigger on a change to statusCategory yet. A work-around would be to list all of your possible "from" (not…

That is interesting...I would expect that when importing a rule from one Jira version (or site) to another that the id values might be different for types, even when the names are the same. And so the symptom you are seeing is the rule JSON has a name for display purpose, but it cannot match to a type by id...leading to…

Hi @David Maurel With Jira Cloud, there are company-managed and team-managed projects. And as the name implies, team-managed support project-level configuration of issue types, custom fields, etc. If you use just the name for a type there could be a mismatch for rules which span multiple projects. This same configuration…

Hi @Elif Alverson One way to do this is to modify your REST API to not add the user as a watcher during creation. The next way is to create an automation rule to remove the watcher once the issue is created: * trigger: issue created * action: re-fetch issue * action: manage watchers, and remove the user Kind regards, Bill

That is correct, I believe: because your Epics type does not use the built-in mechanism for connecting issues you would need to create queries for each epic you wish to display and then add them for swim lanes by query. To do that you will need to identify now you are connecting the Epics to their child-issues, and write…

Branching is the key for this as linking is to whatever is the current issue at that point in your rule. For example: * trigger: some trigger * action: link some issue...in this case, to the trigger issue * branch: to one or more other issues* action: link some issue...in this case, to the current issue of the branch

Hi @Mike Fink First thing, how does the team work on defects? Are they really assigning up to 10 for each person? Might a dashboard showing the open, assigned defects counts be better if the team has a daily standup? Regarding your scenario in a rule... How many possible assignees do you have? Let's say it is less than 10…

Hi @April_Delay I believe you can try that by referencing the {{triggerIssue.parent.key}} for your linking. Kind regards, Bill

Hi @Spruha Shah I noticed in your board filter that you appear to have issue types named Epic and Epics. Is that correct? The built-in type is named Epic, and your swim lanes are selected by Epics; that may be the cause of the swim lanes not working as you expected. Kind regards, Bill

Thanks for that information, Sandra. Yes, that is what I was suggesting: have the requestor create the first story, and that one includes the information a rule could use to create the remaining ones.

Oh well...onward to the support team! :^)

Hi @Daniel Newman First thing, the Epic Name and Epic Link fields are being sunset eventually...so it is possible the on-going changes for that are causing problems. There are lots of posts in the community about that if you want to learn more. Next, changing the Issue Type of an issue is technically a "move" operation,…

Thanks. One more thing to try: put "Green" in quotation marks in your JQL statement.

Hi @Sandra Fuchs Adding to Mikael's answer... What problem are you trying to solve with the manually triggered rule? Perhaps if you share that, the community to offer other ideas. For example...let's say you want newly created issues to have certain fields updated. You could change your trigger to Issue Created and then…

Hi @Elizabeth LC -- Welcome to the Atlassian Community! Adding to Alex's answer... Your original regular expression was missing a capture group for the value you wanted, and you marked the other groups as non-capture. You could try inverting to remove the parentheses grouping for the prefix and suffix and only include them…

Hi @prasad Biddika What have you tried thus far to solve this? If you have a rule started, please post images of the complete rule and the audit log details. A great deal of writing automation rules is about experimentation. You try something based on your needs, the examples and documentation, and inspect/adapt toward the…

Hi @Shamanth You are correct that the Server/Data Center version of automation does not have the Create Variable or Lookup Issues features, as does Jira Cloud automation. However, Server/Data Center does have the bulk processing feature for branches and scheduled triggers, and with that you could do what you ask by…

Hi @chhatwal_simran -- Welcome to the Atlassian Community! Do you mean the items completed/resolved in the last 365 days? If so, this would do that, after you substitute in your project name: project = myProjectName AND resolved >= -365d ORDER BY resolved ASC To learn more about creating JQL searches and to see examples,…

Hi @Alexandre Droulers -- Welcome to the Atlassian Community! I do not believe that is possible for the built-in chart's data. The chart seems to use the issue history to build that interpretation of a CFD, so you could call the REST API to gather all of the relevant issue history, parse it, and the analyze it. It may be…

Hi @Mykenna Cepek I am using Jira Cloud, not Server/Data Center, and...I wonder if you can find an issue in the project and access the properties that way with: {{issue.project.properties.snji-comments}} My understanding is the {{project}} smart value only works with the project-based triggers so perhaps that's why the…

Thanks for that information, and here are some ideas to help: First thing, smart values are name, spacing, and case-sensitive. So it can help to confirm the smart values for your custom fields before proceeding. Please find an example issue with your Business Unit field, and then this how-to article to find the correct…

Okay, one more thing to check... Using your example issue of A20-3271 follow the instructions in this how-to article to call the REST API for your issue. Basically you are just getting all of the supported smart values for a specific…

Hi @Caio Covos -- Welcome to the Atlassian Community! Yes, you may perform a calculation like that in an automation rule. I recommend triggering it on a change to any of those three fields, including the result. (That will handle the case of someone altering it.) Please look here for more information on such field…

You seem to have covered all of the things I know which could cause this symptom. At this point I recommend working with your Site Admin to submit a ticket to Atlassian Support for assistance. If you are using a paid license for Jira the admin can do that here: https://support.atlassian.com/contact/#/

Well done! So it appears there was just a comma missing between the JSON sections (template selection and data); is that correct?

I was going to suggest trying a scheduled trigger, and you have already tried that. I did a quick look and did not see this symptom in the public Jira backlog. Let's fault isolate this a bit... The symptom is the rule editor indicates your JQL statement is both valid and returns an issue, and when the rule executes it…