Bill Sheboy Expert

Okay, let's try this... Smart values are name, spacing, and case-sensitive...Perhaps the smart value you are using for the "Customer" field is not correct, and that would result in it always being null (empty). You can check that by finding an example issue with a Customer set, and then use the following how-to. Basically…

Hi, and thanks for clarifying. What you originally described matches your clarification: The Priority field on the cards is not a good way for me to display priority, because Epics aren't priorities as "High", "Medium", "Low"; they're prioritized as "A is more important than B", "B is more important than C", "D is the 4th…

I am glad to learn that helped, and... JQL is not a SQL and so it is not always obvious what will/will not work with Jira (especially given some defects for EMPTY handling in JQL due to the recent "improvements" :^)

Hi @Gregory James Is your Customer field a user field or a basic selection field? * If a user field, please try {{issue.Customer.displayName}} * And if a selection field, please try {{issue.Customer.value}} Kind regards, Bill

Hi @August Zellmer -- Welcome to the Atlassian Community! What would that view look like to you? Let's assume it is a list. Jira uses the Rank field for the 1-to-N prioritization you seem to be describing, so you could use a filter and a dashboard to show just the epics: project = myProjectName AND issueType = Epic ORDER…

Hi @Josh Maurer Yes, and...to Trudy's answer: I do not believe there is a built-in way to do this with a single expression. Sometimes things like this are done with either multiple chron expressions or with a script/code logic. One work-around for a Jira automation rule would be: * run the rule on a more frequent, daily…

Perhaps try simplifying your sub-filter to just use resolved, such as: resolved IS EMPTY OR resolved >= -3w

Hi @elramr Have you considered having a conversation with your Product Manager to explain "what's in it for them" with smaller work items, particularly when a team uses the Scrum Framework? Your scrum master or agile coach can help with that discussion. Some things to cover could be: * ask the Product Manager what problem…

Are you using Jira Standard or Premium license, and how have you associated these issue types? For Premium, other levels can be added to the hierarchy, and so the Parent field works. But if you have Standard, and have added issue types at the same levels as Epics, I expect you are connecting issues using links instead.

Hi @Grant Mackay -- Welcome to the Atlassian Community! Is "Program Epic" an issue type you have created, or do you mean "Epic"? Do you want this information for a specific Initiative? If so, please try this: parent = INIT-1234 Where INIT-1234 is the key of your initiative. Kind regards, Bill

Thanks, @Fernando Eugênio da Silva And it appears the documentation at the bottom of this page is incorrect, as that is what @Inna S was probably using: https://status.atlassian.com/api Kind regards, Bill

Hi @Gaurav I believe the mathematical operators are needed for that to work in a rule: {{#=}}{{issue.Consequence.value}}*{{issue.Probability.value}}{{/}} Kind regards, Bill

Hi @[deleted] -- Welcome to the Atlassian Community! Just to be clear, you want to update the display of issues on the board, and not the reporting, correct? And, are you using versions consistently to manage work? Kind regards, Bill

Hi @Raul Blazquez First thing: I recommend using a select list field for your values rather than the Description to drive setting the Priority. It is more manageable, controllable for entry, and reduces errors. If that is not possible, I recommend using the last approach with conditional logic, with some adjustments. The…

Just to confirm, you are using Jira Cloud, correct? Would you please show your Create Variable component in the rule? That may explain what is happening with the lookup. Next, I wonder: smart values are case-sensitive and I suspect the JSM objects are as well. Perhaps change the lookup query to this: objectType = "Team"…

Yes, that sounds correct for many of your ideas. And also, you note the team is new to agile ideas. I recommend raising these issues as they occur, at sprint planning, the daily stand-up, and at the retrospective. Making them visible to all may reduce the needs for the reporting. For more details on your questions/ideas...…

Hi, Renni! In your example, is assignee a required field? Or...are you noting that: * fields have been made required after an issue was created (with empty required fields), and... * during assignee clean-up (for the inactive user) the required fields are blocking the update? If so, this seems like an opportunity: whenever…

Hi @Cornelius Dufft -- Welcome to the Atlassian Community! Yes, and...to Trudy's answer: This form of change can be quite disruptive, as you note for the change of issue type. This is one reason Jira as a special operation for this: Move. I encourage you to find a way to backup the information before starting, as that may…

Hi @Robert Sirchia There is one defect, one suggestion, and one documentation article with different perspectives on this behavior. I recommend following the defect and suggestion to see how Atlassian responds: * https://jira.atlassian.com/browse/JRACLOUD-80265 * https://jira.atlassian.com/browse/JRACLOUD-78483 *…

Hi @Renni Verho What problem are you trying to solve by doing this? There is likely a different problem your team/organization was solving by making those fields required. Circumventing that may create other challenges, or re-introduce the original problem the required fields solved. Kind regards, Bill

Hi @Lance Shaw From what you described, I suspect you are running this as a global/multi-project scope, rather than a single project scope rule. Is that correct? If so, you can do what you need with a project scope rule, eliminating the need to use up your rule execution limit for global rules. For example: * trigger:…

As you have described that need, I do not believe there is anything built-it which could prevent adding items to the sprint after that threshold. However...would a reminder email/notification help when someone does this? If so, you could use an automation rule to detect when someone adds something to an in-progress sprint,…

Would you please post images of your complete rule and the audit log details showing the execution? That may provide context for what you are seeing. Thanks!

Hi @LouiseJ Rivet -- Welcome to the Atlassian Community! Adding to Trudy's answer: That rule structure and the error message seem to indicate you are trying to set fields in the issue create which do not exist for that issue type: Transat Reco Kind regards, Bill

Hi @kate reeder You might be able to set those fields using an Automation for Jira rule, triggered on Sprint Start, assuming you only have one active sprint at a time you rarely add scope to a sprint. The display on the dashboard may be done with saved filters on filter list gadgets. Your "Dev Cut-off Field" could be…

Are you showing the entire rule in the screen image? I ask this question because the log details showing the failure show that the Edit Issue Fields action is after the if/else conditions and inside the same level. So that edit could not be the one which is failing. There must be another Edit Issue Fields later in the rule…

Would you please post a new image of your current rule and the audit log details, and explain what is not working as you expect? For example, are the issues created and not linked, or something else is happening? Thanks!

No need for that; it appears that Marta has helped identify the cause.

It appears the rule was changed today, after the successful run on 9 December. After that point it appears to be failing. Do you know what was changed?

Thanks for that information. I do not believe any of the built-in dashboard gadgets can sum up the worklog time, by user, for display. Please check the Atlassian Marketplace to see if there are addon apps which can do this.