Bill Sheboy Expert

Thank you for clarifying the scenario! Your rule will need to use the multiple-project scope setting to access the issues. Your Jira Site Admin will need to make the change in the global rule administration. Next, do you want to concatenate the field value to the JPD Idea field or replace it? Let's assume you want to…

Hi @Cláudia Silva Are you using BitBucket? If so, the REST API does not support that information, and here is a suggestion to add it: https://jira.atlassian.com/browse/BCLOUD-22700 Kind regards, Bill

Yes, and...to your ideas, @Stephen_Lugton As Deming describes such annual review practices in "Out of the Crisis": It nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, nourishes rivalry and politics. It leaves people bitter, crushed, bruised, battered, desolate, despondent,…

That "None" indicator causes lots of confusion, and I recall several suggestions to do something about it. Regardless... Getting the max dates from sprints is easy: {{issue.sprint.startDate.max}} and {{issue.sprint.endDate.max}} But that may not help if they are found at the wrong time / conditions. Let's pin down the…

Hi @Riyas Khareem -- Welcome to the Atlassian Community! First thing, hopefully scope changes to the sprint are an infrequent occurrence. The team could consider any such changes during their retrospective to discuss "why did that happen", how could we improve, and create experiments to do so. This may eliminate the need…

Here is another way to see them all, but as references to the Ideas instead. The results could be exported to get the links. * navigate to Filters > View All Issues * add links to the columns * use JQL to select the Ideas in your JPD project which have links project = myJPDProject AND issueLinkType = "is implemented by"…

What the audit log shows is the rule is not finding any child issues, so I am unclear what you mean...and that seems unrelated to copying the Fix Version value. And reviewing your original rule image, one of the conditions checks if the trigger issue is an Epic, Story, Sub-task, or Task...but Sub-tasks cannot have…

Hi @Gary Spross Short answer: I do not believe it is possible to get them for a specific JPD project using out-of-the-box JQL. If you want issues probably linked as "Delivery Tickets" to any JPD project Ideas, that would be the following, using the internal, link type name used by JPD: issueLinkType = "Polaris issue link"…

The way your rule is written, it does this: GIVEN an issue has linked issues WHEN the issue transitions to Done THEN FOR EACH linked issue of link-type Implements EDIT the linked issue's Summary back to same value That is probably not what you wanted to do. Did you instead want to do this? GIVEN a JPD Idea has linked…

That view of the Sprint field indicates the issue is not currently assigned to an active sprint, and it has been in two, prior completed sprints. You note the issue completed in a sprint; did that issue: * complete during one of those sprints; or * was it removed / carried over as incomplete, and then marked as "done"…

First thing, for rules like this where conversion is involved, it helps to use writes to the audit log to check the values: https://confluence.atlassian.com/automation/jira-automation-actions-993924834.html#Jiraautomationactions-logactionLogaction I recommend adding some writes to the audit log to help diagnose this during…

Hi @Julian Governale Sometimes rules get "glitched" / broken due to repeated update / publish cycles. That symptom seems to be caused by a problem in the rule editor storing some incompatible data or not updating it. (Other posts have observed it happening with the create (or clone) issue action and selecting fields from…

Hi @Kaysaff Tal This symptom is from a built-in, hidden behavior of branching on JQL: it automatically adds JQL to exclude the trigger issue to prevent errors / looping situations. And so that added JQL fails because the trigger issue was deleted. The fix is to use branch on Parent instead as the automation engine "knows"…

Hi @Nicolás Guzmán Short answer: I recommend working with your Jira Site Admin to send that question directly to Atlassian Support / Billing for an answer: https://support.atlassian.com/contact/#/ That is a great question! I hypothesize the answer is the "Jira" limit will apply to the net total as they will become one…

Hi @Sorokach, Mark D -- Welcome to the Atlassian Community! In my opinion, some of the measures you note are not "simplified metrics" and also unlikely to be found in the basic, Atlassian interpretation of measures for Scrum teams. Perhaps start by viewing what is in the built-in reports and dashboard gadgets, and any…

Hi @Iryna Komarnitska_SaaSJet_ Thank you for your article and drawing attention to better use of measures for teams, perhaps helping reinforce this idea from Goldratt: "Tell me how you will measure me and I will tell you how I will behave." Regarding the ideas on neglecting non-working hours, in my experience that depends…

Hi @Harold Pinther-- Welcome to the Atlassian Community! Adding to Marc's suggestions... There are several cases to address for a field sync scenario. The level of accuracy you want for the field (and when you want it) may determine the need for additional rules. Those others include at least: * when an issue is created…

Hi @patman_y First thing, what problem are you trying to solve? That is, "why do this?" Knowing that may help the community to offer other alternatives. For example, it appears you are trying to notify the assignee and specific people when issues are "not yet started and have not been updated for the last 2 calendar days".…

Hi @Eliyahu Klein --CNTR I do not believe that is possible with an automation rule after the issue has been cloned. In my experience, there are only three ways not to keep (or to clear) the Sprint field and its history for a cloned issue: * When the issue is cloned using an automation rule, include the Sprint field as…

Hi @Rüdiger Wienhold -- Welcome to the Atlassian Community! You appear to asking how to the count of completed Tasks by Assignee for a Project. That could be done using a Dashboard with the Two-Dimensional Filter Statistics Gadget: https://support.atlassian.com/jira-cloud-administration/docs/use-dashboard-gadgets/ You…

Hi @Eran Roiter Adding to the suggestion from @John Funk The article John provides uses a scheduled trigger rule, perhaps updating the summed field once per day. When an update is needed more often, multiple rules with different triggers are needed. The specifics of which rules to add depend upon how accurately you want…

Hi @Angel How often do you need to find the average, how do you want to use it, and what do you mean by "average"? * Need the value one time, and want to use the average outside of Jira* identify the issues needed, export them, and use a spreadsheet function to perform the calculation * Need the value often, and want to…

Hi @TILLENAYAGANE -- Welcome to the Atlassian Community! In your first expression, the asNumber conversion is at the wrong location. It should be convert the text field to a number for use as a parameter: {{issue.customfield_14329.minusDays(issue.customfield_16609.asNumber)}} Kind regards, Bill

I suggest trying an example Story with links to the Epics, and then use it with your normal process to see how it helps. Then make adjustments from there.

Hi @Shawna Bernazzani -- Welcome to the Atlassian Community! Adding to what Joe suggested... For an Epic and its child issues (e.g., Story) there is only one parent -> child linkage. This enforces the idea that an Epic is normally decomposed into a specific set of child issues, and so those cannot be children of another…

Hi @Sia (Nastassia) Sharasheuskaya Although changes to issue fields are usually recorded in the history, there is no easy way to access the prior values beyond what most recently changed. An automation rule can use the changelog smart value to detect the current edit that triggered the rule, such as when a field changes to…

Hi @Rakeem Bean -- Welcome to the Atlassian Community! Are the messages being sent and they contain no issue field data, or are the messages not sent at all to MS Teams? If it is the first one, this could be caused by a timing / racetrack error: The Issue Created trigger can fire so quickly that some field data may not yet…

Unfortunately, that is not possible for Jira Data Center's version of the Lookup Issues action as it only supports a limited number of fields. There are two possible workarounds, depending upon rule structure: * use the bulk-handling feature of Scheduled triggers and branches with the plural {{issues}} smart value in place…

Perhaps check with Atlassian Support to learn if it can be changed.

Hi @Christopher Vickery There is no list function "latest" to find what you asked. Assuming the most recent / latest version is always the last one created, you could do this by the ID value (as that is required for the edit): {{issue.fixVersions.id.max}} If not, things get more complicated... Instead you would need to…