Redmine

Sorry, I sent it before I completed the description.

When you remove a check status_A/status_A crossing point in your
workflows, the workflows should prohibit to remain the status in
status_A when updating status_A issues. But because of this bug, the
current status always appears in selection lists, and workflows don't
work as you expected.

this one line patch is for the current trunk (r12972).

Please refer the recent discussion on #13560 also.

It would be good to provide db:migrate scripts in order to avoid
changing current projects' behavior.

+1. Also, the patch works for me.

Thank you very much, works as expected.

Migration script seems to be a good idea though :)

Please can you consider including this feature into 3.0 release? You might also make this feature optional by adding switch at global redmine settings (or individual project settings) that can be used to tun on or off this new feature (just in case you are considered how this feature would affect other redmine users).

Thank you

I just realized that there is a usability / validation issue, when the currently selected status is not allowed as new status.

The select field is rendered and does not contain the current status any more. But no value is selected by default which makes the browsers (Chrome / Firefox) render an empty option that is selected by default.

When the form is submitted with the empty option, the status does not change.

This indicates two problems:

1. Usability problem: if the current status is not available in the list the first status should be selected by default
2. Validation problem: when the form is submitted and the current state is not allowed any more there should be an error.

Alexander Stehlik wrote:

1. Usability problem: if the current status is not available in the list the first status should be selected by default
2. Validation problem: when the form is submitted and the current state is not allowed any more there should be an error.

Aren't they problems of workflow definition? Not of redmine.

Well, both problems show up when you really want to force workflow transition.

With the current patch both issues will hit you, when you want to force a state change during saving.

To solve those problems two additions are needed for the patch to work nicely:

• if the current state is not allowed as next state, the first option in the state select needs to get the "selected" attribute
• there needs to be a validation that makes sure that the submitted state is allowed as next state. So if the current state must be changed (forced transition) an empty state must not be an allowed value

I faced the same issue and I'm happy to find a fix here.
Is there any reason why this is not applied to the code of Redmine? Unchecking the transition status_A -> Status_A and still having it available in the issue edit status lists looks like a bug to me.

Note that #15837 and #22280 would benefit from this fix as well (it's all about forcing transitions).

I have tested this patch and I do not agree with one of the changes in the patch:
From
statuses << initial_status if statuses.empty?
to
statuses << initial_status unless statuses.empty?

This is a bug and should be deleted from the patch. It makes it impossible to remain on a given status even though the checkbox in the workflow is checked to allow leaving a status unchanged.

What we want is not to force changes of status, nor to always allow remaining on the existing status: what we want is to follow the choices made in the Workflow management screen.

Olivier Houdas wrote:

I have tested this patch and I do not agree with one of the changes in the patch:
From
statuses << initial_status if statuses.empty?
to
statuses << initial_status unless statuses.empty?

This is a bug and should be deleted from the patch.

Actually the patch is -unless +if from what I can tell, and that's what I needed here to get the behavior which my workflow prescribes.

What surprised me, however, was that inbound e-mails for existing issues with a non-New status started bouncing with:

MailHandler: Validation failed: Statut n'est pas valide

I had to do 2 things to finalize my implementation of mandatory status changes:

First, I excluded the errors.add :status_id portion from the patch, so that e-mails stopped bouncing.

Second, and this is surprising, but our Redmine 3.4.2 completely ignored --status arguments to the mail handler command in our aliases file. I commented out line 240 of app/models/mail_handler.rb to solve that. It looks like it should've been put in receive_issue() and not here in receive_issue_reply(), but I don't speak Ruby so this is as far as I dared go:

# ignore CLI-supplied defaults for new issues
#handler_options[:issue].clear

I hope this helps others who may run into the same dead-end I was in. :)

You're right, I inverted the order of the change in my comment.

This does not change the fact that the diagonal line of the workflow (status X -> Status X) has checkboxes which have no effect, and it is a bug.