Feature #2208
closedWorkflow: only Issue Reporter can close
Added by Peter Steffek over 15 years ago. Updated almost 12 years ago.
0%
Description
we are using Redmine since this week, and I have the problem, that al lot of tickets are closed, before the bug is really fixed.
like Leonard (http://www.redmine.org/boards/2/topics/show/2989) I really need the possibility that only Issue Reporter can close the ticket.
I think best practise is a check box in the crating a ticket form, where you are able to define who can close the ticket
Like (If the problem is solved, return the ticked to me, I close it.). Depends on this check box you have a different workflow.
Are there more interests in this feature?
May we can speed up this feature by a donation ?
Peter
Updated by Ewan Makepeace over 15 years ago
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?
Updated by Leonard Brünings over 15 years ago
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.
Updated by Thomas Pihl over 15 years ago
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
Updated by Daniel Miller over 14 years ago
+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.
Updated by Thomas Pihl over 14 years ago
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
Updated by Bo Hansen over 13 years ago
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
Updated by Robert Hailey almost 13 years ago
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
Updated by Daniel Felix almost 12 years ago
This ticket could also be closed. The workflow system could handle this too. This is implemented by #8050
Updated by Jean-Philippe Lang almost 12 years ago
- Status changed from New to Closed