Feature #1245

close versions

Added by Marco Tralles over 9 years ago. Updated about 8 years ago.

Status:ClosedStart date:2008-05-16
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Projects
Target version:0.9.0
Resolution:Fixed

Description

it would be great to have the chance to close a Version, so that no more issues can pe added to a obsolet Version. That would help to manage events, because obsolet „versions” (dates / milestones) become history …

Screenshot.png (76.4 KB) Digital Base, 2009-11-09 12:23


Related issues

Related to Redmine - Patch #1666: explicitly mark versions as complete and restrict target ... Closed 2008-07-20
Related to Redmine - Patch #2959: Only display active versions in context menu submenu Closed 2009-03-12
Related to Redmine - Patch #3370: Hide completed version in new issues Closed 2009-05-16
Related to Redmine - Feature #3849: Only show needed Versions Closed 2009-09-11
Related to Redmine - Patch #1676: Only show incomplete target versions Closed 2008-07-23
Related to Redmine - Feature #1360: Permission for adding an issue to a version. Closed 2008-06-03
Duplicated by Redmine - Defect #2844: closed version should not be available in the drop-down m... Closed 2009-02-26
Duplicated by Redmine - Feature #3315: Close versions Closed 2009-05-07
Duplicated by Redmine - Feature #3814: Option to filter completed versions from the Target Versi... Closed 2009-09-03
Duplicated by Redmine - Feature #4175: Allow administrators to "freeze" a revision on the roadmap Closed 2009-11-05
Duplicated by Redmine - Defect #1829: New Issue : Target version should not included closed ver... Closed 2008-08-28

Associated revisions

Revision 3020
Added by Jean-Philippe Lang about 8 years ago

Adds version status to limit issue assignments (#1245).

Available version statuses are:
  • open: no restriction
  • locked: can not assign new issues to the version
  • closed: can not assign new issues and can not reopen assigned issues

Revision 3023
Added by Jean-Philippe Lang about 8 years ago

Adds a link to automatically close completed versions in project settings (#1245).

History

#1 Updated by Thomas Lecavelier over 9 years ago

Somewhat relative to #393, so if implemented, there's no real need of the present feature.

#2 Updated by Jean-Philippe Lang over 9 years ago

Thomas: not exactly the same as #393, and it would prevent a "closed" version from showing up in the roadmap if someone accendentally assigns a ticket to this version.
I have this problem here on redmine.org so I think it can be usefull :-)

#3 Updated by Marco Tralles over 9 years ago

yesterday i had the additional idea to close Version only for some tracker - so that you can add a bug-report to a older version, but no feedback or feature-request - i think this would be perfect.

To close the Version compleatly even all Tracker will be disabled for the version - but for software-development it should be possible to report bugs to older versions - maybe it could be a bug wich is still present in a newer version and has now affects to other parts of the software-system (e.g. the actuall openSSL-Bug wich affected a branche from 2006).

#4 Updated by Anonymous over 9 years ago

We us the list of issues from a version to show which issues were fixed for that version, not which issues appeared in that revision. So being able to open issues against a closed (i.e. released) version seems odd to me. That is what the 'Affected Version' field on redmine.org is for.

If you want to see what bugs affect which versions, then surely using an 'Affected version' field and querying on that would be a better way?

Perhaps 'Affected Version' could be a standard field to aid with this?

#5 Updated by David Gillard over 9 years ago

+1 We are deploying a large number of versions to our live system currently. We would like to maintain a list of old versions so we are able to see what was fixed by which version however users are sometimes making mistakes and assigning a new issue to a version that has already been released. Having this feature would prevent this from happening and clean up the version drop down on the issue update screen

#6 Updated by Mischa The Evil over 9 years ago

I guess both feature #1445 and even maybe feature #1505 are related in some way too...

I'm at the moment investigating a switch from a combination of DokuWiki, WebSVN & FlySpray to Redmine (so it's big in the sense that I'm spreading into RoR after being 100% PHP-based) and came around this issue too...

Just to inform and give an idea: In Flyspray this is handled by extending the issue with a new (default) field called "due version" besides "due date" and "reported version" fields. The new field is a selection-list which provides the list of versions configured for the specific project. But this versions list is extended in a way that with every version you can select if it's a
  • "past version",
  • "present version"
  • "future version".

Now versions which are marked as "past" don't show up in "reported version" & "due version" fields since this version is "past" (closed).
Versions marked as "present" are shown only in the "reported version" field. Versions marked as "future" are shown only in the "due version" field.
Now the roadmap can be also based on the versions-marking as only versions marked as "future" should be displayed on the roadmap initially. If "show completed versions" is clicked also versions marked as "past" and "present" (since it is released) should show up.

I also noticed that even when i'm logged-in as a "reporter" (at least a role explicitly without having the "edit issues" permissions) I'm still able to modify the fields "% Done", "Target version" and "Assigned to". This is the partly base too of feature #1445 imho.
Within the versions-implementation in RM 0.73 this behaviour lets a non-privileged users modify the "Target version" which leads to a probable mess-up of the roadmap.
There for I would vote (+1) to make sure that the field "Assigned to" cannot be set by anyone with only the permission "Add issue" and to categorise both "% Done" & "Target version" fields under the permission "editing issues" at least while updating issues (see below).

If such implementation is chosen feature #1445 is fullfilled since the other pointed fields in that issue (Priority, Start and due date & Estimated time) cannot be changed without having the permission "edit issues" (at least not in RM => 0.7.2), they can only be chosen when entering an issue. Though they don't have side-effects for the planning components like the roadmap.

Even such a thing can be solved quite simple I think; Imagine a situation where all planning components (roadmap, time reports, etc. aren't counted/used when issues are still in the status "New". This way the admin (at least ppl with the sufficient permissions to edit issues) can review the filled fields of an issue, while assigning it to the developers and changing the status to "Assigned", and modify them where needed. After this assigning-round the issue should get another status like "Assigned". That status can be made the point where the values of the fields of an issue starts counting for the planning components in RM.

HTH and if more info is wanted just let me know. Maybe I'm able to shed a bright light on this issue.

Greetings,

Mischa.

#7 Updated by Mischa The Evil over 9 years ago

Also I just found feature #685 too is related to this subject partly. Forum-thread http://www.redmine.org/boards/1/topics/show/952 is related too.

#8 Updated by Mischa The Evil over 9 years ago

Last but not least I found the following thread at the forums regarding hiding/disabling fields while editing issues which in-directly relates too: http://www.redmine.org/boards/1/topics/show/812.

#9 Updated by Patrick Oppenlander over 9 years ago

+1 Would love to see this feature too. I think Russell might be onto something with his idea that 'Affected Version' could become a standard field where the versions are automatically populated.

-Patrick

#10 Updated by Anonymous over 9 years ago

Patrick Oppenlander wrote:

+1 Would love to see this feature too. I think Russell might be onto something with his idea that 'Affected Version' could become a standard field where the versions are automatically populated.

There is an issue with the way Redmine uses affected version that I posted about here: http://www.redmine.org/boards/1/topics/show/1170 which I think adds more weight to the need for affected version to be a standard field.

Cheers

Russell

#11 Updated by Patrick Oppenlander over 9 years ago

Russell Hind wrote:

There is an issue with the way Redmine uses affected version that I posted about here: http://www.redmine.org/boards/1/topics/show/1170 which I think adds more weight to the need for affected version to be a standard field.

Cheers

Russell

Your board topic makes sense, I have come across the same issue. Have you already entered a feature request for this? I couldn't find one. I think it's related to this issue of closing versions but is probably a separate feature.

#12 Updated by Anonymous over 9 years ago

Patrick Oppenlander wrote:

Your board topic makes sense, I have come across the same issue. Have you already entered a feature request for this? I couldn't find one. I think it's related to this issue of closing versions but is probably a separate feature.

Hi Patrick, haven't opened a ticket for this yet (was hoping for some feedback from the forums first) but no-one has replied. I'll open one today and relate it to this issue (if I have permission to)

Cheers

Russell

#13 Updated by Peter Van den Bosch over 9 years ago

It seems a couple distinct issues are addressed in this discussion.

About marking a version as closed and hiding them when appropriate (the original issue): I've created a patch in #1666. It applies against current trunk (r1684). Please give it a try and let me now what you think of it.

It doesn't address the other issues discussed here though (i.e. affected version and limiting access to some issue fields).

Btw, I reported #1445 to be able to make clearer distinction between reporters on the one hand and bug triagers and developers on the other hand.

In many projects (e.g. open source projects), reporters often don't have enough insight on what the progress, target version, development time, target version, etcetera should be. Giving them access to these fields often results in them promoting their own reported issues and thereby messing up the issue tracker as a tool for development planning.
Also, hiding these fields equals less complexity for the reporter to deal with.

I think disallowing 'edit issue' can be a bit too strict because altering the category and correcting mistakes in issues you reported can still be useful. Using a 'not reviewed' flag for each field seems harder to me to implement and only useful for the developer when the signal-to-noise ratio is high enough. Given he has to review the fields, he might as well give them appropriate values himself.

#14 Updated by Anonymous over 9 years ago

Patrick Oppenlander wrote:

Your board topic makes sense, I have come across the same issue. Have you already entered a feature request for this? I couldn't find one. I think it's related to this issue of closing versions but is probably a separate feature.

I've created issue #1675 and related it to this

#15 Updated by Luiz Carlos Junior over 8 years ago

+1
I'm also interested in this feature

#16 Updated by Alex Cartwright over 8 years ago

This is also a very wanted feature for our project - would really appreciation it for 0.9.

#17 Updated by Jean-Philippe Lang over 8 years ago

Patch #1666 adds a 'completed' boolean on versions. But sometimes, we would like to lock a version (no more issues can be assigned to that version), even if it's not completed yet.

So rather than a boolean, we could add a status on each version, with the following values:
  • open: issues can be assigned to this version
  • locked: version is not completed but we can not assign new issue to this version
  • closed: version is completed (every assigned issue need to be closed), we can not reopen issues assigned. reoping an issue needs to change 'target version' to an open version
  • obsolete: could be introduce later, when a standard 'affected version' field is added, so that this version doesn't show up in the 'affected version' list.

This should fill most of the needs. What do you think?

#18 Updated by Brad Beattie over 8 years ago

A few clarifications...

  1. If a version is locked, can you move issues out of it?
  2. Can an issue be deleted if it's in a locked version?
  3. Does a locked version act like a protected wiki page, in that those with locking permissions can still move stuff around?
  4. Does "locked" also refer to the due date? If so, can issues in the version have their due dates modified past the due date of the version?

I like the idea, but there are some implications to consider.

#19 Updated by Thomas Capricelli over 8 years ago

#17 : i like the idea very much.

Also, you speak about the 'reported version'. But it's not very clear to me:

I keep my version of redmine updated with svn and i have a field "expected version", which is useful, but quite strange, as reporters are not the one supposed to decide about this.

However, on this site, there's no such field, and instead a field "affected version", which is useful too, but something different. I dont know why my redmine is different than this one, i have never changed anything related in the configuration.

#20 Updated by Jean-Philippe Lang over 8 years ago

Actually, I mean 'affected version' (post edit).
The 'affected version' field here on redmine.org is a custom field.

#21 Updated by Eric Davis over 8 years ago

+1, I like it.

#22 Updated by Derek Montgomery over 8 years ago

+1 too, I like it too.

#23 Updated by Jean-Philippe Lang over 8 years ago

Brad Beattie wrote:

A few clarifications...

Basically, these rules just define which versions are 'targetable'. I don't think it's a good idea to lock everything, so:

  1. If a version is locked, can you move issues out of it? => Yes, you just can't add new ones
  2. Can an issue be deleted if it's in a locked version? => Yes
  3. Does a locked version act like a protected wiki page, in that those with locking permissions can still move stuff around? => No
  4. Does "locked" also refer to the due date? If so, can issues in the version have their due dates modified past the due date of the version? => No

#24 Updated by Thomas Pihl over 8 years ago

I like this solution!

/T

#25 Updated by James Turnbull over 8 years ago

+1 - also like this solution. Perfect for us.

#26 Updated by Alex Cartwright over 8 years ago

Sounds perfect solution to me. Is it possible to get this in 0.9 please?

#27 Updated by Mischa The Evil over 8 years ago

+1 - perfect for me too! Especially like this state:

obsolete: could be introduced later, when a standard 'affected version' field is added, so that this version doesn't show up in the 'affected version' list.

#28 Updated by Alex Cartwright over 8 years ago

Any word on if we'll get this for 0.9?

#29 Updated by Gregor Bader over 8 years ago

Alex Cartwright wrote:

Any word on if we'll get this for 0.9?

+1

Would like to see it in 0.9, too! The List of Versions for new issues is getting long really fast.

#30 Updated by Aniket Upganlawar over 8 years ago

+1

Would like to see this in 0.9 if possible.

#31 Updated by Nanda P over 8 years ago

+1

#32 Updated by Gilles DENAT over 8 years ago

+1, would be great for projects with lots of versions (quite common, isn't it ?)

#33 Updated by Dan Olsen about 8 years ago

+1, we really need this future to keep things clean with our versions.

#34 Updated by Kirill Ponomarev about 8 years ago

+1 for me too.

#35 Updated by Maxim Krušina about 8 years ago

+100 (we're using versions for every invoicable part of work, so we have to close after invoiced)

#36 Updated by Anonymous about 8 years ago

+1 please!

#38 Updated by Eric Voisard about 8 years ago

+1

#39 Updated by VM Weseloh about 8 years ago

+1

#40 Updated by Andrew Sherman about 8 years ago

+1

#41 Updated by G N about 8 years ago

+1

#42 Updated by Kousuke Ebihara about 8 years ago

+1, I really need this feature.

#43 Updated by Jean-Philippe Lang about 8 years ago

  • Status changed from New to Closed
  • Target version set to 0.9.0
  • Resolution set to Fixed

Feature added in r3020.

#44 Updated by Alex Cartwright about 8 years ago

Jean-Philippe Lang wrote:

Feature added in r3020.

You're a star, I didn't think this would make it into 0.9. Thank you so so much.

#45 Updated by Digital Base about 8 years ago

Before this change, i used [COMPLETE] to mark versions as completed. This is a very nice addition

I do think the context menu needs to be updated to reflect these changes. There is no need including "closed" versions in the target versions (see attached screenshot)

#46 Updated by Erik Lindblom about 8 years ago

Thank you so much for this!

If I could make one last request on this, the road map page will still show closed versions. Is it possible to make this status field the flag on whether it shows up on the road map rather then having a ticket count / due date?

#47 Updated by Jean-Philippe Lang about 8 years ago

Digital Base wrote:

I do think the context menu needs to be updated to reflect these changes. There is no need including "closed" versions in the target versions (see attached screenshot)

You need to explicitly close the versions you don't want to see.

Rather than editing each version to change its status, you can use a button that was just added (r3023) to automatically close all the completed versions of a project. This button is located on the 'Versions' tab in project settings. I hope this will help.

#48 Updated by Jean-Philippe Lang about 8 years ago

Erik Lindblom wrote:

If I could make one last request on this, the road map page will still show closed versions. Is it possible to make this status field the flag on whether it shows up on the road map rather then having a ticket count / due date?

I don't really see why a version with open tickets should not show up in the roadmap. Can you give a use case?

#49 Updated by Erik Lindblom about 8 years ago

Jean-Philippe Lang wrote:

Erik Lindblom wrote:

If I could make one last request on this, the road map page will still show closed versions. Is it possible to make this status field the flag on whether it shows up on the road map rather then having a ticket count / due date?

I don't really see why a version with open tickets should not show up in the roadmap. Can you give a use case?

On second look of my work flow, kindly disreguard that idea.

This actually works the way I wanted to, but didn't realize it on my first look. I had closed a version, yet it still showed up on my road map. This was because there were still tickets assigned to it. This forces me to move those tickets somewhere else if I am done with this version.

Also available in: Atom PDF