How to make epics inherit the fixVersion defined in the JQL filter of a board.

[Gabriel]

Hello community!

One of my users has configured a board which targets a specific FixVersion.

Ex.: project = ABC and fixVersion = XYZ ORDER BY Rank ASC

When we create a standard issue type on that board (Bug, Task, Story), it automatically  inherits the fixVersion configured in the board's JQL filter but not the Epics that we create from the panel of that board.

Is there a way to make epics created from that board inherit the fixVersion?

I've taught about creating an automation rule but it seems we cannot do an advanced compare condition based on the board's ID.

Can anyone help figure this out?

Thanks

Gabriel

[Bill Sheboy]

Hi @Gabriel 

For some context on your question, why do you have a specific fixVersion value in the board filter?  Knowing that may help reveal other solutions to this use case. 

For example, let's say your board is always intended to show the next unreleased version.  There is a JQL function to find that version; that would make the filter generic and allow automatic assignment of the Epic, or other issues, when needed using an automation rule.  The function is: earliestUnreleasedVersion()

https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-functions/#Advancedsearchingfunctionsreference-earliestUnreleasedVersionearliestUnreleasedVersion--

Kind regards,
Bill

[Gabriel]

Hi Bill,

This user wants to track certain activities using releases (fixVersion field) in a specific board.

There are other releases configured in this project and the version she uses cannot be set dynamically in the board's JQL as you proposed since it's neither the first nor last release (date) in the project. Also other releases might be created in the future.

Of course, there are many other ways for this user to track those activities but when you think about it, there are no other functions in JSW that automatically input a value in a field to tickets created in a specific board so here we are... lol

I have suggested to make the fixVersion a mandatory field when creating/editing epics which solve the issues - workaround style ;)

Thanks for input :)

Gabriel

[Bill Sheboy]

Thanks for clarifying, Gabriel.

That seems like the version is being used for something other than just release management, in regards to this board.  Other than making the fixVersion field required for epics, I wonder: from the other data in the epic can you determine the fixVersion used for this board?  If so, that might be used in a rule.

Which goes to your last point...A board is a view of a project's issues based on a filter (and a choice about Scrum or Kanban).  When one wants the issues to display, the fields are set to match the filter.  So it makes sense to ask the fixVersion be entered at issue create if the desire is to display on a board/backlog.

[Trudy Claspill]

Hello @Gabriel 

There is nothing that detects the board that is displayed when an issue is created, so it is very unlikely that the issues are "inheriting" the Fix Version value from the board filter.

Issues are created in Projects, not in Boards. Boards are just a way to visualize and manipulate the issues that are in projects.

What is displayed in the Board is based on the board filter. An issue can actually be displayed in many boards based on the filter.

I would like to understand how you concluded that the issues are inheriting the Fix Version from the board filter. I don't believe that is possible. I suspect that there is some other method being used to set the Fix Version for the issue as it is created; either an automation rule or it is being set manually.

You can check what Automation Rules have run for an issue by clicking on this.

That will show you the rules that have been triggered for that issue recently.

[Gabriel]

Hi Trudy,

I was also skeptical about this behaviour but this is really what is happening.

I have created a video/gif that demonstrates this behaviour.

As you will see, there are no automation rules assigning the fixVersion as per the history of the ticket. 

I invite you to test it yourself if you are on Cloud.

Cheers :)

Gabriel

[Trudy Claspill]

I would suggest that you check the Project Settings > Automations  (if you are a Project Admin) and ask a Jira Admin to check Jira Settings > System > Global Automations to see to confirm there are no automation rules applying to the issue creation.

You could also check in the Workflow to see if there is a Post Function on the Create transition that is setting the field.

And can you try creating an issue using the Create button in the menu bar to see if there the Fix Version field is filled in with a default value?

[Gabriel]

Hi Trudy,

I am the Jira admin @ PHX labs and I can assure you that there are no automation rules configured in this project nor global automation triggering this behaviour.

Also, there is no post-function that is configured in the workflow.

I've tested this on my personal sandbox and could recreate this behaviour.

When I create a ticket from the create button, there are no pre-filled data in the fixVersion field.

Believe me, test it and you will see ;)

[Trudy Claspill]

Well, I'll be darned! I have now indeed tried it out in my own instance and it behaves just as you say! When the board filter includes

...AND fixVersion=<a version>

...it does indeed set the Fix Version field for new issues created in that board.

I have learned something new. Thank you!

I'm not sure if that is actually intended functionality. You might want to open a case with Atlassian Support to ask about that.

I can't think of any way for your Epic creation to detect that it is being created while that board is being viewed, and get the Fix Version from the filter for that board.

You could potentially have an Automation Rule such that when an existing issue was added to an Epic, the Fix Version could be copied from the child issue to the Epic. I'm not sure how you would limit it to issues and epics on that one board though. 

[Gabriel]

We both learned something new this week hahaha ;)

I am pretty sure this behaviour is intended but somehow I couldn't find any reference for this... 

I already tried to create an automation rule for this but as I wrote in my original post, you cannot do an Advanced Compare Condition based on the board's ID and you cannot call a board's ID in a JQL so I think we've hit a limitation of Automation for Jira :(

We'll just have to live with this.

Thanks for the exchange and have a great weekend!

Gabriel