Redmine

Perhaps you could remove the ability to move a task to closed from the workflow of your developers - Reporter could close (and presumably manager too) but everyone else would need to send the task back to the reporter to have it closed?

The problem is that everyone is a worker there is no distinction between reporter and developer.
So you can't remove the close right from them or else only the manager could close the issue.

Might this be better solved with education and instructions then limits in the system? You can track who misuse it and perhaps talk to them about it?

I am a big fan of more workflow-options (finer grained workflows per project/tracker), but I'd solve this one in a non-tech way.

/T

+1

I disagree with Thomas Pihl's assessment that this is always an educational issue. What is make & SCM at their essence: a way to move the human-domain yelling over the cubicle walls of "hey, I changed such-and-such, now everone needs to recompile" to the automation domain. One could argue that the entirety of Redmine could be replaced by education of how to use email tools better. But we know that their is value to institutionalizing this project's/company's way into automation. Redmine is not merely some cute presentation of text fields (although numerous of Redmine's OSS competitors are little more than such trivial feature-set). Redmine is getting close to taking on the duties of TechExcel's DevTrack or IBM Rational's ClearQuest. These duties are very much based on declaring & enforcing a useful work-flow, including any restrictions that the local project/company using Redmine might see fit (regardless of what someone outside of that project/company "would do").

Conversely, this feature should not be enforced at all times. First, it should be optional and turned off. Second, there are naturally some roles that by their very nature are inappropriate for this feature: interlopers outside of the project/company and people who are somehow no longer associated with the project/company. Requiring such people to come back out of the woodwork, perhaps years later, is impractical as a requirement to close an issue. Obviously, for some (inferior) roles, anyone in some other (superior) role can approve the issue as completely resolved. In default Redmine, the inferior role would be reporter and that superior role would be manager. I would argue that naturally you would want two kinds of reporter: one for testers/etc that are actively associated with the project/company and those that are mere interlopers. I would think that this feature's restriction would apply to the tester/etc-reporter but not to the interloper-reporter.

Daniel Miller wrote:

+1

I disagree with Thomas Pihl's assessment that this is always an educational issue. What is make & SCM at their essence: a way to move the human-domain yelling over the cubicle walls of "hey, I changed such-and-such, now everone needs to recompile" to the automation domain. One could argue that the entirety of Redmine could be replaced by education of how to use email tools better. But we know that their is value to institutionalizing this project's/company's way into automation. Redmine is not merely some cute presentation of text fields (although numerous of Redmine's OSS competitors are little more than such trivial feature-set). Redmine is getting close to taking on the duties of TechExcel's DevTrack or IBM Rational's ClearQuest. These duties are very much based on declaring & enforcing a useful work-flow, including any restrictions that the local project/company using Redmine might see fit (regardless of what someone outside of that project/company "would do").

Conversely, this feature should not be enforced at all times. First, it should be optional and turned off. Second, there are naturally some roles that by their very nature are inappropriate for this feature: interlopers outside of the project/company and people who are somehow no longer associated with the project/company. Requiring such people to come back out of the woodwork, perhaps years later, is impractical as a requirement to close an issue. Obviously, for some (inferior) roles, anyone in some other (superior) role can approve the issue as completely resolved. In default Redmine, the inferior role would be reporter and that superior role would be manager. I would argue that naturally you would want two kinds of reporter: one for testers/etc that are actively associated with the project/company and those that are mere interlopers. I would think that this feature's restriction would apply to the tester/etc-reporter but not to the interloper-reporter.

Please quote me correctly.

I did not state that this should always be an education issue. I did however, and still do, think that this in most cases should be a soft constraint. And I really think there are several areas that are more important to constrain than if only the exact creator of an issue may close it. But, as i wrote, i like more control in the workflow. I am for this feature but I would argue lower priority than for instance possibility to control what fields are open for a specific role in a specific state or who an issue might be assigned to based on current or changed state.

Please quote me correctly.

BR,
Thomas

Today I had a request for this feature for our internal workflow. As far as I understand it could be a permission like #2653 so it seems quite related to the private issues. Is this something considered for the next 1.2.0 release?

Best regards,
Bo

I think this feature has been implemented, because I was recently confused when I could not close a ticket, even though I was logged in as an admin & was a manager for the project in question (ticket author was also).

Tested on v1.2.1

This ticket could also be closed. The workflow system could handle this too. This is implemented by #8050