Redmine

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

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 :-)

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).

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?

+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

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...

• "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.

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.

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.

+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

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

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.

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

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.

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

+1
I'm also interested in this feature

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

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.

• 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?

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.

#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.

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

+1, I like it.

+1 too, I like it too.

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

I like this solution!

/T

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

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

+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.

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

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.

+1

Would like to see this in 0.9 if possible.

+1

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

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

+1 for me too.

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

+1 please!

+1

+1

+1

+1

+1

+1, I really need this feature.

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.

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?

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.

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?

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.