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

[Josh Allen]

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.

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.

[Bill Sheboy · Accepted solution]

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:

1. use the Send Web Request action to call the REST API to query for status=unreleased versions in the other project
2. find the earliest release date in the results
3. use that to filter and get the id of the matching version
4. 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:

• https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828
• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-versions/#api-rest-api-3-project-projectidorkey-version-get
• https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Affects-Versions

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

[Josh Allen]

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]

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?

[Bill Sheboy]

First thing, sorry for the long reply as this will take a bit of explanation.  You can skip ahead to "Back to workarounds" for more ideas.

The error is describing the problem...(in a roundabout way :^) The trigger is for a version, and that provides no issues to the rule: thus the branch on current issue cannot find it.

Rather than using the lookup issues action, try using a branch on the same JQL.  (Please note: this will not work, as described below when the project is unknown.)

• trigger: version created
• branch: on JQL
  • action: clone issue into...???  This is the tricky part: into which project should the new issue be created?

If the issue goes to the same project as where the version was created, the challenge is neither the Issue Create nor the Issue Clone actions allow dynamically selecting the project.

Back to workarounds:

1. for a known set of projects, use if / else conditions
2. for an unknown set of projects, call the REST API

#1: for a known set of projects, use if / else conditions

• trigger: version created
• if / else condition
  • smart value condition
    • first value: {{version.project.key}}
    • condition: equals
    • second value: project A's key
  • branch: on JQL to your template issue SEAP-48
    • action: clone issue, selecting your project A
• else / if
  • smart value condition
    • first value: {{version.project.key}}
    • condition: equals
    • second value: project B's key
  • branch: on JQL to your template issue SEAP-48
    • action: clone issue, selecting your project B
• ...repeating for each project

#2: for an unknown set of projects (or more than about a dozen), call the REST API

This workaround uses the REST API with Send Web Request:

• trigger: version created
• action: Send Web Request to call the REST API issue get and load your template issue, SEAP-48
• action: Send Web Request to call the REST API issue create, using text functions to replace the project information with the trigger information {{version.project.id}}

[Josh Allen]

@Bill Sheboy 

This is so great, thank you. I've learned so much over the past week on Jira automation and I really appreciate your help. 

#1 workaround with if/else works just like it should, so i'm going with that. Now in your example, you have one template issue (SEAP-48) being cloned into the multiple projects. That works and it successfully places the cloned issue into the next unreleased version. However, it's not able to do that if my template issue isn't within SEAP.

The workaround that I've tried on a few projects is to create a template issue within each project and then clone and add to the release which seems to work correctly. I just want to avoid creating 30 different clone tickets, one in each project, so i thought I'd ask you first before doing that work.

My template issue is PAYM-293. Is it looking for the next unrleased version in PAYM project?

[Bill Sheboy]

For the template issue, if that issue's project is in the scope of your multiple-project scope rule (in the rule details), it can be accessed for use in cloning from one issue in one project.

Now, the messy part: my very first post in this thread appears to be correct about the need for the REST API...

After some testing I found when branching to an issue (e.g., PAYM-293) that issue's project's versions are used in the Clone Issue action for things like "Next Unreleased Version".  That will fail to create issues in any other project as the versions are project-specific.  It does not matter which project is selected in the Clone Issue action.

I believe the only way to do this scenario is to call the REST API to get the next unreleased version for the specific project into which the issue is cloning, and then use advanced edit with JSON to set the version.

[Josh Allen]

Okay, that's what i was thinking. I appreciate the testing you did. I'm gonna stick with creating the templates in each project until i can get a dev to help me with the JSON.

With your help I think i've gotten the automation to a great spot. Thanks again.