jira fix version field

Is it possible to tell JIRA not to show the released verisons from the Fix Version field?

7 answers

I think the best way is to create a field called 'Target Version' and ask your users to use this field to indicate the version in which they want this to be fixed. The fix version can be used by the dev team.

 

Hi Chris,

most likely you are looking for the possibility to "release fix versions", right? Have a look at this page:

https://confluence.atlassian.com/display/JIRA/Managing+Versions#ManagingVersions-Releasingaversion

Here it is described that you can release and archive JIRA fix versions (incl. not showing them anymore).

Hope that helps!

Kai

What if we don't want to archive "Released fix version". Is there a possibility to not allow users that aren't projectmanager to add "Released fix version" ? Some user accidentially add "released fix version" to new created issues , thats why we would like to avoid this failure. Thanks in advance

If you don't archive them, then the list will continue to grow, and people will be able to use the released versions.

The point of archiving is to stop people adding releases you aren't going to want to add to. I'd recommend using it as intended.

Hi M.P.,

Some user accidentially add "released fix version" to new created issues , thats why we would like to avoid this failure.

JIRA does not natively support security level on field level, see JRA-1330. However you can use one of the workarounds described in the issue (e.g. transitions with specific screens/fields).

As it seems a problem for you to have the (released) fix versions especially in new issues, I'd propose check if the field "fixversion" is present in create screen currently. If so, I'd tend to remove it.

Cheers
Kai

thanks for reply but archiving fix released version doesn't solves our problem, as we are getting bugs from customers that has to be created out of some already released version.

I'm sorry, your requirement is not clear to me here. I really don't understand what the problem is.

Ok let me explain it more detailed, following scenario:

  1. Customer reports Bug - found on released version
    • User- creates Bug.
      • As "Affected Version" he has to choose one of "released versions"
      • As "Fixed Version" he has to choose one of "unreleased version"
  2. Fixing BUG is extended
    • User has to change "Fixed Version" by choosing one of "unreleased versions" from ALREADY created BUG (as it was decided to fix this bug in next version)
    • Here some of users do sometimes mistake and choose "released version" INSTEAD OF "unreleased version"

For that reason, we want to disable "released version", if bug was already created, so that users can only change fix version by having the possibility to choose ONLY "unreleased versions" (disabled "released version" and enabled "unreleased version" on created bug screen)

Only if they're archived. You could also prefix them with a character to make them sort differently?

What if we don't want to archive "Released fix version". Is there a possibility to not allow users that aren't projectmanager to add "Released fix version" ? Some user accidentially add "released fix version" to new created issues , thats why we would like to avoid this failure. Thanks in advance

Hi M.P.

You could also remove the Fixed Version field from the create issue and edit screens in your screen scheme. You can then add it to a screen you use in the close issue transition on which you can set a condition that only people with a certain permission (project role) can execute this transition.

Best regards,
Peter

I have the same problem and not sure if the answers suggested above are satisfactory. The question, if I may rephrase is that I need to see a particular version in 'Affects Version' field, but SHOULD NOT see it in the 'Fix Version' field.

 

  1. Archiving does not help because it will make the version disappear from BOTH affects version and fix version fields.
  2. Hiding the fix version field for general users is not practical; Users need to be able to enter a fix version value.

Hope I have explained the scenario in an understandable manner.

 

Any suggestions please?

 

 

That's wrong. First of all, how does an end user know when it's going to be fixed? It's not up to them, it's up to the development and/or product teams to decide when a version is due to be fixed. IF it's up to the users, they'll just put "next" on every single one, and that's all your planning and resource allocation processes shot. Best bet there is to create another field for "when the users would like this fixed" and then have all your developers ignore it (because it is functionally pretty useless) Secondly, what happens when you fix a bug, close it, then the users find that you have not (or that it's happening for a different reason that they can't be expected to know)? Oh, suddenly, they can't report the bug against the version it has happened in. So they are now forced to leave out the version information.

Nic, thanks for your comments. I agree with the scenarios you have mentioned, which do not merit the 'affects version' and 'fix version' needing to have different lists.

 

However, different organizations follow different approaches; in my organization, anyone can set the 'fix version', and it is used to indicate in which version they want the fix. Engineering team will set the version value to the correct value and approve the defect for fix. So, I am trying to prevent folks from setting an incorrect 'fix version', because it has already been released.

 

So whether we appreciate these scenarios or not, what I want to know is, is it possible in anyway to show different lists in the 'affects version' and 'fix version' dropdowns? If yes, how can it be done?

 

Many Thanks,

Vijay

Your process is basically broken as far as Jira is concerned - you're using fix versions in an inappropriate way and really should split it out into a "desired fix version" and "fix version". But no, you can't get different lists, because that's not useful for most scenarios.

The process followed by my team is exactly the one described by Vijay, which is that a bug can be found on a release that has been shipped and has to be fixed in future releases. We are migrating from Bugzilla, which does support two separate list of versions for "Affects Versions" and "Fix Version(s)" so would like to understand how others have gotten around this limitation in Jira.

What limitation? You've got a valid list of versions, it's available for reporting issues in "affects version" and when you plan to fix it in "fix versions", which then becomes "was fixed in" when you mark it resolved and eventually release it. If you've shipped a release, then mark it as "released". You will still be able to log issues against it.

So what exactly does "Releasing" a version mean in Jira? It is still available and visible for use in "Affects version" and "Fix version(s)" fields. Does Jira treat a "Released" version any different from an "Unreleased" version?

I don't think Nic Brough (do you work for Atlassian?) has understood the issue that many of us are having.

If a new issue is reported in a Released Version, then, in the "Affects Version" field, we want the ability to choose from all the Released and Unreleased versions.

However, once a version is Released, AKA in production, out the door, done, nothing else will ever be fixed/changed in that version again -– we no longer want  people (in our case, team members) assigning new tickets to that fixVersion.  It wouldn't make any sense!  Unfortunately, I spend a lot of time as a project admin, moving tickets out of these versions that team members choose in error.  I'm blue in the face trying to explain to them why they shouldn't be choosing Released versions that they see in the drop down smile

I admit, there are a couple scenarios where it might be valid to select a Released version:

One is a mistake.  A defect ticket is fixed in the release, but the ticket erroneously was never assigned to that release.  Since this is not a frequent occurrence, there should be a special permission to allow an Admin or a Project Lead to assign a ticket to a Released Version.

The other situation is if a customer reports something in say, the 1.0 release and we already know it was fixed and released in say, version 2.0.  In our world, we just tell the customer the version it is fixed in and close the ticket as a duplicate.  That may seem dumb, but that's the way we do it. 

Our system is primarily to track work being done, not as a repository for customers to see what is fixed in what versions.  We don't give our customers access to our work system at this time.  That's probably not state-of-the-art, but I'll bet there are a lot of JIRA users out there who are the same.

Know your customers – don't try to make us use the system they way you think is best smile

I agree with Carolyn.  Nic, you really can't tell us what our requirements are.

So, anyone from Atlassian, are you planning on improving the Fix Versions?  They really need to be enhanced to allow us to stop letting people assign items to a released version.  Archive can then be used as it should for fix versions that will never see the light of day.  

Also, there really shoudl be a way to add custom fields to fix versions so I can store key information about them (and widgets for the dashboard and issue list fields that allow me to display and use these fields).  For example, I'd like to associate key milestone dates for our process, an overall business owner for the fix version, etc.

You could use the Schedule permission to limit who can set values in the Fix Versions field. Or a Behaviours script to only allow non-released Versions in that field.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,254 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot