Bill Sheboy Expert

You may not be able to catch an issue type change with a move (convert) with the automation rules. Here is a suggestion to add it. Trigger Issue Move event notification when the Issue type is changed within the same project https://jira.atlassian.com/browse/JRACLOUD-70640 What problem are you trying to solve by watching…

Awesome: I am glad that worked for you! Looks like they have started implementing some new fields for changelog...when I checked the documentation it still only showed 3 fields available. Time to explore a bit and see if they added the other requested stuff, such as the specifics of when a change occurred and who made the…

Gotcha. Well, the changelog history will not help for an option as it does not support the Key field. (There are suggestions/ideas in the Code Barrel (now part of Atlassian) backlog to improve this to add more fields and details in the changelog...The devs are limited by the Jira API as to what is possible...apparently :^)…

Hi @Cédric Cox Are you trying to get the moved issue's prior key within the same automation rule? If so, have you tryied saving the key before the move using the action Create Variable? Please see this documentation for more details on that action: https://support.atlassian.com/jira-software-cloud/docs/automation-actions/…

Hi @Jiri Pik Yes, the trigger would be Issue Created...and due to potential timing issues you might want to add a re-fetch so the item is fully loaded. Your JQL would check for any issues in your project which have the triggering issue's summary. Perhaps something like this. * Trigger: Issue created * Action: re-fetch *…

Hi @Danielle Hutchins Without more details about your rule specifics, I suggest that "timing...is everything." ;^) The rule engine seems to queue execution of rules (and their component parts) asynchronously. The Allow Rule Trigger is to prevent (or allow) overlapping rule execution, and it is not a one-stop, full…

Hi @Joey Klein -- Welcome to the Atlassian Community! I am glad that worked for you. __Bill

Hi, @Graham Harbour LookupIssues returns a list, so you could also just get the first value, regardless of the number of issues in the sprint: {{lookupIssues.first().project.name}} Regarding the REST API attempt, that did not work out. Please see earlier response for details. Best regards, Bill

Hi @Ryan -- Welcome to the Atlassian Community! When you know the summary you are looking for, say TargetSummary, use something like: project = myProject AND summary = TargetSummary The challenge here is your TargetSummary. Is it a known value or perhaps constructed from other fields in an issue? If not... If you do not…

Not fixed, and here are 3 suggestions to address this (some 5+ years old): https://jira.atlassian.com/browse/JSWSERVER-11744 https://jira.atlassian.com/browse/JSWCLOUD-12723 https://jira.atlassian.com/browse/JSWCLOUD-17858

Hi @Shreyanth Reddy Bezawada I pasted in your smart value and it worked for me in a log message: {{now.format("MMMM")}} This may have something to do with the task title field. So, maybe break this down into steps for fault-isolating this: * Try it in a log message to confirm the smart value works * If so, try setting this…

Hi @Pete Hall I am unclear what problem you are trying to solve by using two "sprints" (one for dev and one for QA)... Rather than moving work between two parts of one team spread across sprints, have you considered: * Have one Scrum team, with one sprint, with all the people contributing to the work based on their skills…

Hi! I do not have recent experience doing this, and I found two posts that show examples of formatting to get URLs to work. The first is just formatting info and the second shows the full set-up process steps. https://support.atlassian.com/jira-core-cloud/docs/use-automation-with-slack/…

Hi @Callum Carlile _Automation Consultants_ -- I am glad that worked for you. Those HTML list markups were to help when using Lookup so you can produce a list of issues. When you have just one item, no need for them. __Bill

Awesome! I am glad that worked. I am going to experiment with this a bit more using information from the REST API returns for sprints to see if there is an attribute/tag for the project in the sprint list. It *seems* like there should be, but it does not seem to be working just yet. ;^) Update: Nope, that does not work…

Ah... Now I believe that I see what you are trying... Those sprint triggers have no issue context, and the project name smart value comes from the issue. So you would need an issue to access project name. Maybe try the lookup action to get an issue, and then use that item to get the project name.

Hi John and Graham, I just tried what you tried, and my results were: {{issue.project}} -- This one blows up with a long error message. Interesting... {{issue.project.name}} -- Returns the correct value {{issue.project.displayName}} -- Returns nothing (null) {{project.name}} -- Returns the correct value Best regards, Bill

Hi @Brian Paison -- Welcome to the Atlassian Community! I do not believe that you can delete the posting, but you could accept your above response as the answer. Best regards, Bill

Hi @Esther Strom When you create the issue, is there a way to uniquely identify it with JQL? If so, could you use a Lookup Action to get the newly created issue and then use the key? Given the way automation is scheduled to run asynchronously, this approach could have race track/timing issues when the create happens in…

Hi @Thomas Fortenberry That would be more of a workflow solution than an automation rule one. Please search the community posts (or a browser search) for something like "require field before status change", and you may find a few approaches. Best regards, Bill

Nick, I am glad that helped you. __Bill

Hi @Greg Bailey Please consider posting your entire automation rule; that will help the community have some context to comment on what you are asking about. Thanks! Best regards, Bill

Hi @Debra Graham This appears to be a known defect, and I posted a link to it on your other question. Best regards, Bill

Hi @Debra Graham This appears to be a known defect found in 2018: Labels not being used anymore still show on Labels list macro https://jira.atlassian.com/browse/CONFCLOUD-58953 Best regards, Bill

Hi @Laurie -- Welcome to the Atlassian Community! I agree with the other recommendations about disabling delete permissions. My company uses an "abandoned" custom field instead to track work no longer needed. However, if you really want to delete and you want to track it, you could have your site admin set up a webhook to…

Hi @[deleted] I can think of two ways to do this, both using a scheduled trigger to periodically check for a condition... * If you can write JQL to detect the issue to transition, use that in the scheduled trigger and use an action to transition the status. * If you cannot represent the target date in JQL, when you create…

Hi Guy, Thanks for explaining what you are trying to accomplish. And just to confirm, you have multiple teams doing work within on project and separate sprints for each team. Correct? Unfortunately, there appears to be no way to sort the values in a list field (e.g. Sprint) by an attribute (e.g. date) to get what you want.…

Hi @Grace Ackerman -- Welcome to the Atlassian Community! According to the documentation, those are the only two fields for create at this time: https://support.atlassian.com/jira-core-cloud/docs/use-jira-cloud-for-slack/ There is a suggestion to make this more configurable, which you may review and vote for here:…

Hi @Dionei Piazza Would you please provide more details about what you are trying to display and how? That may help the community give you ideas to try. For example, are you trying to show some field over time using the custom date/time field on the axis? Best regards, Bill

Hi @Sunil Thakur Have you tried to first perform a call to get a list of the users, and find the account ID you need for the user in the JSON? Then you could use that to add them to the group with another call. The call to get the users list is: /rest/api/3/users/search?maxResults=1000 Note that unlike other REST API calls…