Feature #5991

Tracker should have it's own default issue status

Added by Lubor Nosek over 7 years ago. Updated about 3 years ago.

Status:ClosedStart date:2010-07-29
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Issues workflow
Target version:3.0.0
Resolution:Fixed

Description

Currently you're not able to set different default issue statuses to different trackers.


Related issues

Related to Redmine - Feature #5816: New issue initial status should be settable in workflow Closed 2010-07-05
Related to Redmine - Feature #973: Assign different status sets and workflows for separate p... New 2008-04-02
Related to Redmine - Patch #18898: Back migration for 20141029181824_remove_issue_statuses_i... Closed
Duplicated by Redmine - Feature #6832: FR Define different default status per tracker Closed 2010-11-04
Duplicated by Redmine - Feature #13797: per tracker configurable default status and better usabi... Closed

Associated revisions

Revision 13535
Added by Jean-Philippe Lang about 3 years ago

Default status per tracker (#5991).

Revision 13536
Added by Jean-Philippe Lang about 3 years ago

Adds :field_default_status to locales (#5991).

Revision 13570
Added by Toshi MARUYAMA about 3 years ago

remove duplicated IssuesControllerTest#test_new_should_select_default_status (#5991, #18305)

History

#1 Updated by James Robertson over 6 years ago

+1 We love the ability to assign a different default issue status per tracker type.

#2 Updated by James Robertson over 6 years ago

James Robertson wrote:

+1 We would love the ability to assign a different default issue status per tracker type.

#3 Updated by Nicholas Kulikov over 6 years ago

+1 :)

#4 Updated by Steve Davis about 6 years ago

+1

#5 Updated by Oliver Loy almost 6 years ago

+1

#6 Updated by Terence Mill almost 6 years ago

Each tracker shall be able to have its onw start and stop status

#7 Updated by K. Scott Tripp over 5 years ago

+1

#8 Updated by Roman Lukmanov almost 5 years ago

+1

#9 Updated by Filou Centrinov almost 5 years ago

Category: Issues Workflow

#10 Updated by Toshi MARUYAMA almost 5 years ago

  • Category set to Issues workflow

#11 Updated by Dipan Mehta almost 5 years ago

+1. Useful.

#12 Updated by Eric Ashman over 4 years ago

+1 - would help a lot for differentiating new bugs vs requested issues

#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?

#14 Updated by Terence Mill over 4 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.

#15 Updated by Jethro Yu over 4 years ago

+1 !

#16 Updated by benoit deleris over 4 years ago

+1

#17 Updated by druidPollux - over 4 years ago

+1

#19 Updated by Domingo Galdos almost 4 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.

#20 Updated by Toshi MARUYAMA almost 4 years ago

  • Related to Feature #973: Assign different status sets and workflows for separate projects added

#21 Updated by Jeff Pierson over 3 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.

#22 Updated by Jean-Philippe Lang about 3 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.

#23 Updated by Jean-Philippe Lang about 3 years ago

  • Related to Patch #18898: Back migration for 20141029181824_remove_issue_statuses_is_default doesn't work added

#24 Updated by Go MAEDA almost 3 years ago

  • Duplicated by Feature #13797: per tracker configurable default status and better usability for ui added

Also available in: Atom PDF