Redmine

Luiz Carlos Junior wrote:

I would like to suggest a role that prevents unauthorized users reopen or change the attributes of tickets associated to closed versions. Comments, in principle, would be normally allowed.

As far as reopening and assigning issues it is already implemented by using the locked/closed statuses for each version. See RedmineProjectSettings. Version locking/closing was implemented via issue #1245.

I noticed that, as you said, Redmine already prevents the reopening of closed tickets associated to already closed versions. However, it is still possible to change the ticket's version and this would mess the history of the project in the same way.

Once a ticket is associated to a closed version, "normal users" should not be able to change it in any way (not even moving it to an opened version).

What do you think?

Mischa The Evil wrote:

Yes and no. Let's say it depends on how strict your policies are.
Redmine as such isn't very configurable regarding permissions for changing issue-attributes. Let's say it is an well-known feature request to gain more fine-grained control over issue-attributes (see for a start e.g. issue #1919 and its relatives).

I agree that it depends on your policies but, in my opinion, to change the issue's version could mess a project in a way that it would be preferable to be radical and include an option to not allow attribute changes at all in the case above. Control over changes in issue version, at least, appears also in #1360 and #7694. Of course, as you said, a more fine-grained control would be perfect.

The point is that sometimes it could be better to approach the problem roughly than trying to cover it in all aspects directly. #1919 is very complete (considering #8050) but it is a 3 years-old ticket, though. Anyway, I trust in how the Redmine's development team will approach these issue.

Mischa The Evil wrote:

This issue actually seems to be an extend of such a feature. I'll adjust the issue subject to match the actual request.

In this case, shouldn't we link this issue to the other ones?

Luiz Carlos Junior wrote:

In this case, shouldn't we link this issue to the other ones?

Thanks for pointing it out. Relations added.

SPAM