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; } } }

Automation - Add fix/version of "next unreleased version" from another project

Josh Allen_93onke

TLDR: When manually triggered to clone issue into another project, how do i add the next unreleased version to that ticket?

Using edit issue field fix/version only shows the current jira project, not the project i cloned into.

Screenshot 2024-05-22 at 1.59.41 PM.png

More context:

Our dev team works on several microservices each sprint that are tracked in separate jira projects (Key: ADB for example) but viewed on one project (Key: PAYM). They create a release and a review ticket in each project.

I've successfully created an manual trigger automation to clone the review ticket from backlog in PAYM into those other jira projects (ADB), add reporter, then add to current sprint in PAYM. Works great.

Now I'm trying to add the next unreleased version from ADB into the fix/version field, but it only shows Next Unreleased Version for project PAYM.

I see the Then Action: Unrelease Version but I'm not totally clear on what smart fields to put there if i don't know the version name.

Screenshot 2024-05-22 at 1.24.40 PM.png

Accepted answers

Bill Sheboy

Hi @Josh Allen

Finding that information for the other project is not straightforward. To get the versions in the other project, I believe the rule would need to:

use the Send Web Request action to call the REST API to query for status=unreleased versions in the other project
find the earliest release date in the results
use that to filter and get the id of the matching version
use that with JSON to set the field, Affects Version

If you want to try that, here are some references on using Send Web Request and the REST API function needed, and using JSON to set the version field:

As simpler, workaround could be to always assign a dummy issue to versions as they are created. Then using a multiple-project scope rule, a Lookup Issues action with JQL can find the dummy issue with the earliestUnreleasedVersion() function:

fixVersion = earliestUnreleasedVersion(SEAP)

Then grab the first issue's fix version's id, and use that with advanced edit with JSON.

UPDATE: this workaround with lookup issues, or a JQL branch will not work if the project is unknown when the rule is created. Please see later in this thread for alternatives.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Josh Allen

Finding that information for the other project is not straightforward. To get the versions in the other project, I believe the rule would need to:

use the Send Web Request action to call the REST API to query for status=unreleased versions in the other project
find the earliest release date in the results
use that to filter and get the id of the matching version
use that with JSON to set the field, Affects Version

If you want to try that, here are some references on using Send Web Request and the REST API function needed, and using JSON to set the version field:

fixVersion = earliestUnreleasedVersion(SEAP)

Then grab the first issue's fix version's id, and use that with advanced edit with JSON.

UPDATE: this workaround with lookup issues, or a JQL branch will not work if the project is unknown when the rule is created. Please see later in this thread for alternatives.

Kind regards,
Bill

Josh Allen_93onke

Hello again @Bill Sheboy ! Thank you for getting me this far BTW.

I like your workaround. It's more to my skill level. I'm gonna give it a shot. Thank you

Bill Sheboy

Glad to help!

If you mean the second workaround, with the dummy issue for versions, I recommend adding a rule to automatically add the issue when versions are created in the SEAP project. That will help ensure they are present when you need them. :^)

Josh Allen_93onke

Okay, so i've decided to reverse things a bit. Originally I was having the dev manager add a label to the template review ticket in his main jira project then run the automation which would clone the issue into the appropriate jira microservice project and add it to current sprint. Then repeat that for each microservice.

However, he's already going into several different jira projects to create these versions in the first place, and from your comment above it seemed to me i should just automate creating the review ticket once he creates the version. Rather than a dummy ticket.

The downside of this approach is that i'll need to setup and maintain the automation in a few dozen jira projects rather than just one. But it's probably worth it.

But I'm stuck.

I've created a template issue seap-48 to then clone once a new version is created, but getting the following error. Do i need to use the advanced branching or do i have the branch in the wrong spot?

Screenshot 2024-05-24 at 12.23.14 PM.png

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation