nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation - Condition to check whether an issue is in the backlog or a sprint

Martin Arana

I'm looking for a way to detect if an issue was created in the backlog or a sprint or if it was moved from one to the other. The idea is to assign the current version to an issue assigned to a sprint.

I've tried checking if the sprint field is empty, the trigger being either the creation or movement of an issue. Got no response either way

I've also tried checking if the sprint field was modified (in case this field is somehow assigned a second after it's creation/movement). Still no success.

Is there anyway to reliably check this value during an automation check?

Accepted answers

Bill Sheboy

Hi @Martin Arana -- Welcome to the Atlassian Community!

I do not believe the scenario you describe can be done with a single automation rule. However...

Would you please describe the problem you are trying to solve? (what and why) Knowing that may help the community to suggest solutions to help. Thanks!

Kind regards,
Bill

All comments

Alex Koxaras -Relational-

Hi @Martin Arana and welcome to the community,

The only "safe" workaround I can think of is the following:

Add an automation to populate a custom field (e.g. a text field) with a value, when
- An issue moves from backlog to any other status
- When the sprint value is being populated

After that you can narrow down all issues which do not have values in this new custom field, and you will be sure that they are in the backlog and their sprint field is empty.

You could also experiment with the smart value {{issue.status.name}}{{fromString}} which will provide the previous value of the current status.

Let me know if that helps.

Trudy P Claspill

Hello @Martin Arana

Welcome to the Atlassian community!

Is this for a Team Managed project or a Company Managed project?

What steps are you executing to create the issue "in" the Sprint? Are you filling in the Sprint field in the Create Issue dialog? Or, if you are in a Team Managed project, are you using the Create Issue option that shows in the Sprint area on the Backlog screen?

Please show us the Audit Log for the execution of the rule you've shown when you create a new issue both within and outside of a sprint.

Bill Sheboy

Hi @Martin Arana -- Welcome to the Atlassian Community!

I do not believe the scenario you describe can be done with a single automation rule. However...

Would you please describe the problem you are trying to solve? (what and why) Knowing that may help the community to suggest solutions to help. Thanks!

Kind regards,
Bill

Martin Arana

This is a Team Managed project

The usual way we go about it is to create the issues on the Backlog View, using the "+ Create issue" buttons
Adding them either on the current sprint if it's something we need soon or on the backlog for future reference

Those rules I created are long gone now, so I can't get those Audit Logs 😅
For now I've gone for a hacky workaround where I assign the Version whenever a user is directly assigned to a task (which usually means the task is now a priority)

Thanks for your help

Martin Arana

The overall problem I'm trying to solve is that whenever an issue is created by any user, they're bound to forget to assign the Fix Version field

This is fine for the backlog section, since it's meant to hold issues for far into the future, but once the issue is assigned to a sprint (either by being created in it or being moved into it), it means it's absolutely gonna be included in the current Version

Now, this could be solved by making the issue required on the issue settings and it's something I tried out, but it became extremely bothersome to have a window popup every time I created an issue
Specially when you're quickly iterating on what are the tasks for the week with a group of people 🤣

Which is why I wanted to set up a reliable automation rule
What I'm using right now, in my desperation, is a rule that sets the Version as soon as a user is assigned to the issue (which most likely means the issue is now a priority)

Thanks for your help

Bill Sheboy

Thanks for those details, Martin. I believe you would need several automation rules to cover the different scenarios, including at least these:

when a sprint is started (trigger), check if all of the issues in the sprint have the next unreleased version assigned, and if not, add it
when an issue is created (trigger), re-fetch it, and check it has been assigned to the current open sprint and has no version assigned; if so, assign the version
when the sprint field is edited for an issue (trigger), check if it is in the current open sprint without a version assigned, and if so, assign it
when the version field is edited for an issue (trigger), check if it is in the open sprint and does not have the next unreleased version assigned. Note this one can only be checked with a JQL condition as there is an open defect for fixVersion changelogs and rules.
when a sprint completes (trigger), and there are remaining incomplete issues, decide what to do with issues assigned to the next unreleased version
Probably not currently solvable with a rule: when the next unreleased version is deleted while a sprint is in progress, decide what to do
Probably not currently solvable with a rule: when the versions are re-ordered and the "next" one is changed while a sprint is in progress, decide what to do

Some potential things that complicate these are if you have parallel sprints running or if your "next release" is not in the expected order in the releases list (that is, at the bottom).

Martin Arana

That's actually very smart 👀

On my project the only status types we got are To do/In progress/Done, so that would make things easier

Think the only problem would be not having those remaining tasks counted on the stats, though I may be able to live with that 😅

Thanks for your help!

Martin Arana

Those are a lot of scenarios I hadn't accounted for 💦

I mostly focused on #2 and #3, but like I said on the first post, they don't seem to trigger at all
As if the Sprint field was different to other fields

I wonder if there's a way to debug the rules somehow

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

automation