Redmine

If the proposed new row about initial statuses will be implemented, there is no use of the "Default value" column in Administration / Issue Statuses

+1
I want more than only one default status.
Now it's not only one default: also this default will be used in every tracker, so as if this default status relates to every workflow:(

A couple of different issues here.

As pointed out in the related report, it's quite possible as in my current use case that there is no one status that applies to all our trackers.

Therefore it should not be a requirement to have a single global "Default status", and that would be IMO easy to do away with. If the desire is simply to ensure there is a status on every issue, then an easy fix would be to check that when the issue gets saved.

Another way to go would be to present a dialog with a list of tracker types when "New Issue" is pressed, which would fit in OK with the idea of having a separate default for each tracker. However, the idea of forcing a subset of status's to be the only ones allowed at issue creation time seems overly complicated to me - I'm not saying there aren't use cases for it, just that it seems to me such a change would have further ramifications that need to be thought through.

Yeah, this is a big problem for us too.

We need different status sets in our trackers, so different start and finish status per tracker. At the moment there is one start status for all tracker's

This issue is duplicated by #558

Nikolay Kotlyarov wrote:

+1
I want more than only one default status.
Now it's not only one default: also this default will be used in every tracker, so as if this default status relates to every workflow:(

I like this idea. It would help to improve redmines configurability!

+1

+1

+1

+1

+1

I'm in the process of implementing Redmine as a new tracking system where I work (small team of 4 devs), this specific feature was one of the biggest concerns from management while I was giving a product demo...

So, here's a big +1 from me.

+1

+1

+1

+1 -> we're planning to move from trac to Redmine and this feature is also a concern for our team

+1

I have made a fix for this. You can find a plugin here: https://github.com/Jaeder42/InitialStatusRedminePlugin

The plugin adds an initial status "Initital". It will be set as the first and as the default issue. You will need to assign statuses to it's workflow.

Once this is done, when you create a new issue, only the statuses which you have assigned in the workflow can be selected for the issue but one must be. As long as you do not link to the initial status it can't be set to this. The plugin also only alters the view for creating a new item.

Please try it and tell me if you have any trouble running it.

Johan Jäderblom wrote:

The plugin adds an initial status "Initital". It will be set as the first and as the default issue. You will need to assign statuses to it's workflow.

Interesting workaround.. Since Redmine allows new issues to use the selected "Default" status or any status that the default can move to in one step, hiding the "Default" status is quite literally the only way to get the UI to only show one status option for new issues.

Doesn't quite close the issue in question here, but I'll most definitely be using your plugin in the meantime.. :)

For that matter, new issues should be settable only those tracker-types that are configured for the role.

I envision this workflow as follows:
(1) Administrator creates a role (let's call it role A)
(2) Administrator assigns a user (or group) role A.
(3) Through the implementation of this feature, the administrator will be able to define which tracker-types that role A is capable of creating (so long as role A has been assigned the "add issue" permission)
(4) When the user possessing role A (and also having the "add issue" permission) clicks the "New Issue" tab, the user will see only those trackers which were defined as "can create this tracker" to role A.
(5) If the user has multiple roles with "can create this tracker" defined, each having their own set of permissible trackers, the user will be able to create the super-set of all trackers from all assigned roles.

This feature would greatly enhance Redmine's flexibility in configuration.