Patch #16364

Issue workflow doesn't force status transition though workflow is defined so

Added by Tadashi Hirata almost 5 years ago. Updated 8 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues workflow
Target version:-

Description

Please refer the recent discussion on #13560 also.

workflow_bugfix.patch Magnifier (513 Bytes) Tadashi Hirata, 2014-03-17 06:25

workflow_bugfix-master-2015-06-16.diff Magnifier (2.1 KB) Alexander Stehlik, 2015-06-16 19:04


Related issues

Related to Redmine - Feature #13560: Force status transition on issue update New
Related to Redmine - Defect #5593: Grey out workflow checkboxes for transitions to the same ... Closed 2010-05-25
Related to Redmine - Feature #15837: Reply to closed ticket changes status to "reopen" designa... New
Related to Redmine - Feature #22280: change automatically the status A to B (and the assignee)... New

History

#1 Updated by Tadashi Hirata almost 5 years ago

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.

#2 Updated by Toshi MARUYAMA over 4 years ago

  • Related to Feature #13560: Force status transition on issue update added

#3 Updated by Jose Juan Montes over 4 years ago

+1. Also, the patch works for me.

#4 Updated by Alexander Stehlik about 4 years ago

Thank you very much, works as expected.

Migration script seems to be a good idea though :)

#5 Updated by VD DV almost 4 years ago

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

#6 Updated by Alexander Stehlik over 3 years ago

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.

#7 Updated by Tadashi Hirata over 3 years ago

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.

#8 Updated by Alexander Stehlik over 3 years ago

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

#9 Updated by Alexander Stehlik over 3 years ago

The attached patch should solve the usability issues.

#10 Updated by Go MAEDA almost 2 years ago

  • Related to Defect #5593: Grey out workflow checkboxes for transitions to the same status added

#11 Updated by Olivier Houdas over 1 year ago

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).

#12 Updated by Toshi MARUYAMA over 1 year ago

  • Related to Feature #15837: Reply to closed ticket changes status to "reopen" designated status added

#13 Updated by Toshi MARUYAMA over 1 year ago

  • Related to Feature #22280: change automatically the status A to B (and the assignee) when an user add a note added

#14 Updated by Olivier Houdas over 1 year ago

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.

#15 Updated by St├ęphane Lavergne about 1 year ago

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. :)

#16 Updated by Olivier Houdas 8 months ago

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.

Also available in: Atom PDF