Feature #5991
closedTracker should have it's own default issue status
0%
Description
Currently you're not able to set different default issue statuses to different trackers.
Related issues
Updated by James Robertson over 13 years ago
+1 We love the ability to assign a different default issue status per tracker type.
Updated by James Robertson over 13 years ago
James Robertson wrote:
+1 We would love the ability to assign a different default issue status per tracker type.
Updated by Terence Mill over 12 years ago
Each tracker shall be able to have its onw start and stop status
Updated by Eric Ashman over 11 years ago
+1 - would help a lot for differentiating new bugs vs requested issues
Updated by Justin Leishman about 11 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?
Updated by Terence Mill about 11 years ago
You bot it, thats one reason and beyond that THW status 'closed' is fundamental different to 'refused', although both are stop status ones. That example shows also that mor than one Ende Statue can be useful.
Updated by Domingo Galdos over 10 years ago
+1
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.
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #973: Assign different status sets and workflows for separate projects added
Updated by Jeff Pierson over 10 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.
Updated by Jean-Philippe Lang almost 10 years ago
- Status changed from New to Closed
- Assignee set to Jean-Philippe Lang
- Target version set to 3.0.0
- Resolution set to Fixed
Feature added in r13535, default status is now defined for each tracker.
Updated by Jean-Philippe Lang over 9 years ago
- Related to Patch #18898: Back migration for 20141029181824_remove_issue_statuses_is_default doesn't work added
Updated by Go MAEDA over 9 years ago
- Has duplicate Feature #13797: per tracker configurable default status and better usability for ui added