Project

General

Profile

Actions

Patch #16364

open

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

Added by Tadashi Hirata about 10 years ago. Updated almost 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues workflow
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Please refer the recent discussion on #13560 also.


Files

workflow_bugfix.patch (513 Bytes) workflow_bugfix.patch Tadashi Hirata, 2014-03-17 06:25
workflow_bugfix-master-2015-06-16.diff (2.1 KB) workflow_bugfix-master-2015-06-16.diff Alexander Stehlik, 2015-06-16 19:04

Related issues

Related to Redmine - Feature #13560: Force status transition on issue updateNew

Actions
Related to Redmine - Defect #5593: Grey out workflow checkboxes for transitions to the same statusClosedJean-Philippe Lang2010-05-25

Actions
Related to Redmine - Feature #15837: Reply to closed ticket changes status to "reopen" designated statusNew

Actions
Related to Redmine - Feature #22280: change automatically the status A to B (and the assignee) when an user add a noteNew

Actions
Actions #1

Updated by Tadashi Hirata about 10 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.

Actions #2

Updated by Toshi MARUYAMA almost 10 years ago

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

Updated by Jose Juan Montes almost 10 years ago

+1. Also, the patch works for me.

Actions #4

Updated by Alexander Stehlik over 9 years ago

Thank you very much, works as expected.

Migration script seems to be a good idea though :)

Actions #5

Updated by VD DV about 9 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

Actions #6

Updated by Alexander Stehlik almost 9 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.
Actions #7

Updated by Tadashi Hirata almost 9 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.

Actions #8

Updated by Alexander Stehlik almost 9 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
Actions #9

Updated by Alexander Stehlik almost 9 years ago

The attached patch should solve the usability issues.

Actions #10

Updated by Go MAEDA about 7 years ago

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

Updated by Olivier Houdas almost 7 years 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).

Actions #12

Updated by Toshi MARUYAMA almost 7 years ago

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

Updated by Toshi MARUYAMA almost 7 years ago

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

Updated by Olivier Houdas over 6 years 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.

Actions #15

Updated by Stéphane Lavergne over 6 years 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. :)

Actions #16

Updated by Olivier Houdas almost 6 years 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.

Actions

Also available in: Atom PDF