jira fix version field

[gil]

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

[Carolyn Nelson]

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 

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 

[Linda Walmer]

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.

[MattS]

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.

[Sravya Vuggina]

Hello,

I am trying to do something similar, by showing released versions only in the affects versions field. Any luck in getting this work? If not using out of box feature, any suggestion using behavior script is appreciated. 

[Azfar Masut]

I agree with Carolyn here. Looked into JAC and found out https://jira.atlassian.com/browse/JRASERVER-31309 has been closed due to no votes. I'm raising a request to Atlassian to either reopen them or create a new one. Please, please put a comment on that ticket. Will help all of us to justify our needs here

[Rajagopalan Balaji]

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.

[Kai Gottschalk]

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

[M. P.]

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

[Nic Brough -Adaptavist-]

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.

[Kai Gottschalk]

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

[M. P.]

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.

[Nic Brough -Adaptavist-]

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

[M. P.]

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)

[Vijay Kumar]

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?

[Nic Brough -Adaptavist-]

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.

[Vijay Kumar]

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

[Nic Brough -Adaptavist-]

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.

[Shinjani Gaur]

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.

[Nic Brough -Adaptavist-]

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.

[Shinjani Gaur]

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?

[Peter Van de Voorde]

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

[M. P.]

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

[Matt Doar]

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