Project

General

Profile

Actions

Feature #5991

closed

Tracker should have it's own default issue status

Added by Lubor Nosek over 13 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Issues workflow
Target version:
Start date:
2010-07-29
Due date:
% Done:

0%

Estimated time:
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 workflowClosedJean-Philippe Lang2010-07-05

Actions
Related to Redmine - Feature #973: Assign different status sets and workflows for separate projectsNew2008-04-02

Actions
Related to Redmine - Patch #18898: Back migration for 20141029181824_remove_issue_statuses_is_default doesn't workClosedJean-Philippe Lang

Actions
Has duplicate Redmine - Feature #6832: FR Define different default status per trackerClosed2010-11-04

Actions
Has duplicate Redmine - Feature #13797: per tracker configurable default status and better usability for uiClosed

Actions
Actions #1

Updated by James Robertson almost 13 years ago

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

Actions #2

Updated by James Robertson almost 13 years ago

James Robertson wrote:

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

Actions #3

Updated by Nicholas Kulikov almost 13 years ago

+1 :)

Actions #4

Updated by Steve Davis about 12 years ago

+1

Actions #5

Updated by Oliver Loy almost 12 years ago

+1

Actions #6

Updated by Terence Mill almost 12 years ago

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

Actions #7

Updated by K. Scott Tripp over 11 years ago

+1

Actions #8

Updated by Roman Lukmanov about 11 years ago

+1

Actions #9

Updated by Filou Centrinov almost 11 years ago

Category: Issues Workflow

Actions #10

Updated by Toshi MARUYAMA almost 11 years ago

  • Category set to Issues workflow
Actions #11

Updated by Dipan Mehta almost 11 years ago

+1. Useful.

Actions #12

Updated by Eric Ashman over 10 years ago

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

Actions #13

Updated by Justin Leishman over 10 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?

Actions #14

Updated by Terence Mill over 10 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.

Actions #15

Updated by Jethro Yu over 10 years ago

+1 !

Actions #16

Updated by benoit deleris over 10 years ago

+1

Actions #17

Updated by druidPollux - over 10 years ago

+1

Actions #18

Updated by Benjamin Wassermann over 10 years ago

+1

Actions #19

Updated by Domingo Galdos about 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.

Actions #20

Updated by Toshi MARUYAMA almost 10 years ago

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

Updated by Jeff Pierson over 9 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.

Actions #22

Updated by Jean-Philippe Lang over 9 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.

Actions #23

Updated by Jean-Philippe Lang about 9 years ago

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

Updated by Go MAEDA almost 9 years ago

  • Has duplicate Feature #13797: per tracker configurable default status and better usability for ui added
Actions

Also available in: Atom PDF