fix version from issue to epic

[Ander]

Hi,

We have issues in one jira project and epics in other jira project and we wold like to create and automation to do:

1.- When issues is transitioned to done

1.1.- if fixversion is created in epic project, assign fixversion to the epic of the issues

1.2.- if fix version does not exist, create fixversion in epics project and assign

Is these possible? can somebody help me?

Thanks  

[Jack Brickey · Accepted solution]

Hi @Ander , Is the issue that is moving to done associated to an Epic? If so is the Epic associated with a single fix version? I am trying to understand how or where you would test to see if the version exists? 

[Bill Sheboy]

Hi @Ander 

Yes, and...to Jack's questions...You appear to be using a Standard license level for Jira Cloud.  If that is correct, please note...

The rule(s) you are describing would need global / multi-project scope.  The different Jira license levels have limits on rule executions per month for those ones.  And I suspect that a rule triggered on issue transitions would rapidly consume your monthly limit, and then potentially stop executing.

Kind regards,
Bill

[Ander]

Hi,

Yes the issue that is moved to done, has epic link (the epic I want to add the version)

Yes I have the standard license, do not worry about the executions, that would not be a problem.

Somebody can help me?

Thanks 

[Bill Sheboy]

As site admin you can navigate to the Global Rules administration, and then edit your rule's Details to change the scope from a single project to global or multi-project..

[Ander]

@Bill Sheboy , thanks for your answear, but I do not know, how to configure the automation to create and add to the epic the fix version if not exists or only add the version to the epic is version exists

Thanks

[Jack Brickey]

Hi @Ander , I played with this a bit yesterday but didn't complete as I had other priorities. I will try to get back to it today. If you have a rule that is close to your goal please share here.

[Ander]

Thanks @Jack Brickey 

I started with this, but does not work

[Jack Brickey]

@Ander , here is an example rule below. However some things that need pointing out.

• You may already realize this, release versions are unique to a project. I mention this only because you indicated you have a project for Epics and then another project for the actual issues. So unless you are manually keeping Release version names in sync across these two projects then you're going to run into issues.
• The way I approached the problem in the rules below what is as follows:
  1. When an issue is moved to done
  2. Copy the value of the FV in the triggering issue's Parent epic into the triggering issue's FV field
  3. Check to see if the triggering issue's FV field is empty. If not the rule will exit. If so continue...
  4. Create a new release version
  5. Edit the trigger issue and set the FV field to the latest unreleased version. This obviously assumes that all previous versions have been released and the previously created release equates to the latest unreleased version. This could be a bad assumption for sure. So you need to work out the specifics of how your releases are managed.

[Ander]

Hi @Jack Brickey 

Let me know if I have understand it.

To work Like I want, first I need to sync version between projects, I think is possible with an addon like version sync and then I would have to create the automation, that is OK?

Thanks

[Jack Brickey]

I don't have any experience with that app and unsure you would need it. In my opinion, it is more of a process thing.

Basically, your team agrees that the project defining the Epics (Epic-project) for the project where the work is done (Work-project) also defines/controls the versions. In other words Epic-project would be where versions are initially created and then the Work-project would inherit from the Epic-project. This inheritance could be done manually or via Automation.

I can imagine that things could get complicated depending on your actual usage of this process. For example, if you allow issues from different work projects to be associated with a single epic in the epic project, then the versioning will get confusing. However, if your epic project and work project have a one to one relationship, then things will be cleaner.

I hope all this makes sense. My challenge is being able to give you solid advice without really understanding how your team works.

[Ander]

Thanks @Jack Brickey 

[Ander]

Hi, somebody can help me, how I have to configure the automation?

Thanks