Feature #1245
closedclose versions
0%
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 …
Files
Related issues
Updated by Thomas Lecavelier over 16 years ago
Somewhat relative to #393, so if implemented, there's no real need of the present feature.
Updated by Jean-Philippe Lang over 16 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 :-)
Updated by Marco Tralles about 16 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).
Updated by Anonymous about 16 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?
Updated by David Gillard about 16 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
Updated by Mischa The Evil about 16 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.
Updated by Mischa The Evil about 16 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.
Updated by Mischa The Evil about 16 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.
Updated by Patrick Oppenlander about 16 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
Updated by Anonymous about 16 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
Updated by Patrick Oppenlander about 16 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.
Updated by Anonymous about 16 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
Updated by Peter Van den Bosch about 16 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.
Updated by Anonymous about 16 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
Updated by Luiz Carlos Junior over 15 years ago
+1
I'm also interested in this feature
Updated by Anonymous over 15 years ago
This is also a very wanted feature for our project - would really appreciation it for 0.9.
Updated by Jean-Philippe Lang over 15 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?
Updated by Brad Beattie over 15 years ago
A few clarifications...
- If a version is locked, can you move issues out of it?
- Can an issue be deleted if it's in a locked version?
- Does a locked version act like a protected wiki page, in that those with locking permissions can still move stuff around?
- 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.
Updated by Thomas Capricelli over 15 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.
Updated by Jean-Philippe Lang over 15 years ago
Actually, I mean 'affected version' (post edit).
The 'affected version' field here on redmine.org is a custom field.
Updated by Jean-Philippe Lang over 15 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:
- If a version is locked, can you move issues out of it? => Yes, you just can't add new ones
- Can an issue be deleted if it's in a locked version? => Yes
- Does a locked version act like a protected wiki page, in that those with locking permissions can still move stuff around? => No
- 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
Updated by James Turnbull over 15 years ago
+1 - also like this solution. Perfect for us.
Updated by Anonymous over 15 years ago
Sounds perfect solution to me. Is it possible to get this in 0.9 please?
Updated by Mischa The Evil over 15 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.
Updated by Gregor Bader over 15 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.
Updated by Aniket Upganlawar about 15 years ago
+1
Would like to see this in 0.9 if possible.
Updated by Gilles DENAT about 15 years ago
+1, would be great for projects with lots of versions (quite common, isn't it ?)
Updated by Dan Olsen almost 15 years ago
+1, we really need this future to keep things clean with our versions.
Updated by Maxim Krušina almost 15 years ago
+100 (we're using versions for every invoicable part of work, so we have to close after invoiced)
Updated by Jean-Philippe Lang almost 15 years ago
- Status changed from New to Closed
- Target version set to 0.9.0
- Resolution set to Fixed
Feature added in r3020.
Updated by Anonymous almost 15 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.
Updated by Digital Base almost 15 years ago
- File Screenshot.png Screenshot.png added
- Assignee set to Jean-Philippe Lang
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)
Updated by Erik Lindblom almost 15 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?
Updated by Jean-Philippe Lang almost 15 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.
Updated by Jean-Philippe Lang almost 15 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?
Updated by Erik Lindblom almost 15 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.