Tracker should have it's own default issue status
|Assignee:||Jean-Philippe Lang||% Done:|
Currently you're not able to set different default issue statuses to different trackers.
#13 Updated by Justin Leishman over 4 years ago
Terence Mill wrote:
Each tracker shall be able to have its onw start and stop status
Why does each tracker need a "stop" status? Doesn't having a status "close" an issue provide the same basic idea, or do you have a situation where a single issue status is "open" for one tracker but "closed" for another tracker?
#19 Updated by Domingo Galdos about 4 years ago
We could really use this, along with #973 (either would help a lot of course) to allow different projects to have different workflows without driving the administrator crazy.
Ideally someday workflows could be set up by project owners without the central Redmine administrators having to be involved.
#21 Updated by Jeff Pierson almost 4 years ago
We ran into this problem just today after some status were added to our newly converted system in order to support some other projects with mutually exclusive sets of statuses related workflows. Somewhere in the process a status called New was entered and marked as default which caused all defects to to get entered with this status by default instead of the desired Unconfirmed status. To remedy this, the New status was make as longer the default status but without assigning another default status which then prevented us from entered any bugs due to an error when clicking on the New Issue menu item. In the end I employed a hack which was to set New status to the default status but set up workflow permissions for our defect tracker so that Subject is readonly for the New status which prevents any newly created issues from being entered with a New status.
I'm assuming a common workaround is to force all projects to have a reasonable common start status regardless of other statuses until issues like this are addressed. If there are any relevant wiki pages on the topic in terms of recommendations it would be useful in order to determine whether we are better off changing our process or pushing Redmine to adapt to the flexibility that we are trying to get out of it.