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