Mykenna Cepek Expert

The two warnings shown above, "Unknown fields set during create", suggest a (separate) problem with the subtask creation components. Those warnings identify a "Current Status" field, aka "customfield_15900". Have you researched and/or fixed that problem? The warning suggest that you "Check your custom field configuration",…

It looks like only some of the "Action details" are shown above. I only see a couple of notices that look like warnings. Can you revisit this same execution (match the timestamp) and show the rest of the "Action details"?

Hmm, my guess is you're not using Jira Cloud (tip: it helps if you tag your questions here with Jira Cloud, Jira Data Center, or Jira Server). I haven't used the latter two in many, many years; sorry. Maybe under the "More" menu, or hiding elsewhere in an issue (three-dots menu, suppressed by permissions, or not exposed as…

On thought on this: However, another recent addition we built was the 'Advanced Branching' component. When we built this, we created a way for the system to hook into and store the underlying objects of a smart value template. This is why the components in an advanced branch can treat the branched variables as their raw…

I'm having doubts that this rule is the one causing the problem, which you said was: After moving the second sub-task to done, the first sub-task that has been set to "done" automatically moves to "To-do", when the page is refreshed. And the series continues with random status' of done and "to-do". The rule you posted has…

Typically the Filter for a project is set to sort by Rank (which is recommended). This allows the drag-n-drop functionality to work in the Backlog view and on Scrum/Kanban boards. Otherwise, no, the stock product does not offer a way to group items shown in the Backlog. However... Quick Filters are commonly used to help…

Interesting question! Sounds like a good Product Suggestion to offer to Atlassian. Thinking this through, I don't see a way to truly lock this down with Automation as provided today. If the rule is able to look up the value and use it, then it's either exposed or easy to expose. As you say, a project admin having access to…

It would help to see the rule you tried to use. In general, to solve your use case, your rule would use the details outlined here. I suspect you've already got that much figured out though. Sending an email in the branch/loop will indeed send one email per issue. What it sounds like you really want is to aggregate that…

I'll take issue with the suggestion that: The entire goal of automation (IMO) is to address deficiencies in the base Atlassian product, as it doesn't really work well at scale. While I'm quite outspoken on the limitations of Automation in Jira, I find myself coming to Atlassian's defense here. The goal of the product (I…

My guess is that the parallelism that Automation uses to handle looping on multiple issues is causing the non-determinism that you're seeing. That was a performance / consistency tradeoff that Atlassian made, and it prevents a lot of rules from behaving as one might otherwise expect. _ _ _ _ _ _ _ I had a crazy idea for…

I'd love to pile-on with @Doug Levitt in providing use-case based frustrations with Jira Automation. I think we've been using Jira for about the same amount of time!

I'd start by going into the "Issue" screen for any Jira project you have, and click on "Go to advanced search". There you can use JQL to make custom searches across all issues in any of the projects in Jira. For example, searching for: originalEstimate is not empty and statusCategory = "In Progress" will give a list of all…

I'm not sure your item 4, to eliminate duplicate values in a list, is possible within (only) standard Jira Cloud Automation today. As noted, Jira apps might provide alternatives. As much as I wish for more programming language-like functionality in Automation, it's just not a fully functional programming language. It's…

Agreed that this would be a nice feature. And (to this former software developer) it sounds hard to implement. Note that each "Publish" action creates a new version of the page, and lists ALL the collaborators who contributed changes to that version. So at least there is a small set of possible users for each set of…

Exact phrases cannot be checked currently, and just today I noticed that the priority of the related JAC issue (linked earlier in this thread) was unfortunately decreased. However, just because JQL doesn't support it doesn't mean that Jira Automation can't make an exact check -- it can. It'll just take a bit more work in…

For item 1: it would help to have more detail. Consider posting a screenshot of that portion of the rule. Conditional/Branch nesting is a known limitation of Jira Automation. The typical workaround is to "unroll the nesting". In your case, perhaps a JQL-based conditional could check for the missing issue and set a…

It's good to hear, @Matthias Gaiser _K15t_, that your sync app is continuing to pay attention to the Jira Server and Data Center markets. My information came from both our own internal testing, and also from a large client who did their own substantial testing of several sync solutions, and ended up unsatisfied, creating…

We also found a few other points of exposure, despite this type of "external user lockdown" via Jira Permission Scheme: * Shared/public filters are visible. The content of those filters isn't accessible if the underlying project isn't accessible by the external user. But the names of the filters are exposed. * Similar to…

Separate Jira instances would have to share their data. There are (paid) Jira Apps which can sync between instances. You could spin up some free Jira Cloud instances and most Jira Apps are free for 2-4 weeks. Lots of opportunity to do Proof of Concept work, if you want to explore that direction. I haven't used those sync…

Hmmm. Perhaps the "Create Issue" action in the If/Else is altering what should be the "current issue" as the Epic specified in the branch. That sounds like a bug to me, but let's try to work around it... Here is updated pseudocode that might get you going: ... Action: Create Epic Branch: For Most recently created issue…

Interestingly, the Create Issue action does not offer the Status field as something that can be set on create. To implement @Jack Brickey's suggestion, after the "Create Issue" action for each subtask, you'd add: * a Branch with Type = "Most recently created issue" * a "Transition Issue" action with Destination status =…

Thanks for posting more details. As @Bill Sheboy aptly points out, there are known inlining and asynchronous behaviors that can affect rule execution, and differ from our expectations. These effects are not well documented, but folks like Bill and I have called them out in many community postings. An alternative approach…

Atlassian recently rolled out an Early Access Program for their External Collaboration for Confluence. It is not yet available outside this EAP. But it may help to know that they are working on the Confluence side of this currently:…

I believe the if/else condition does allow for checking if a multi-select field contains a value: Yes, I have a multi-select custom field called MultiSelectTest. We didn't have any multi-select fields, so I had to create one (months ago) to do some testing!

Try using the "If / else block" condition instead of an "Issue fields condition". That will ensure that execution continues even if the condition is not true. Also, I'm noticing that your second "For most recently created issue" branch might misfire if the "Desk Phone" conditional causes a Task to be created. At that…

Also, you wrote: I think the Automation capabilities within Jira may be sufficient to calculate the values for you Actually, no. Jira Automation cannot calculate something like a total Story Points or Original Estimate value for an Epic from the Story-level child issues. I'm pretty outspoken here in the Atlassian Community…

Hi @Andrej Freeze greenique. I'm rather confused by what you wrote here. The main problem I'm having is that Jira doesn't natively support SubTasks under Epics very well. Examples: * Within an Epic, using "Create issue in epic" does not offer the SubTask issue type as an option (even if the project allows for that issue…

I can't contribute to how to do this as an app developer. I can clarify that apps can do this, as shown by the following screenshot of one of the apps we have. I accessed this under "Apps > Manage your apps > app > Configure"

Sounds like a bug to me. I'd report it (here). Be sure to give Atlassian access to your instance, and give them the name of the rule which illustrates this problem. Ideally this will be a rule they can execute in your environment to reproduce the problem you're reporting. So if you need to copy your rule to make a "safe"…

Please see my response above.