View Issue Details

IDProjectCategoryView StatusLast Update
0020682mantisbtbugtrackerpublic2016-08-28 01:12
ReportercproensaAssigned Tocproensa 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0-rc.2 
Target Version1.3.1Fixed in Version1.3.1 
Summary0020682: Workflow transitions not consistent with bug action "change status to"
Description

When configuring a status that has no "outbound" status, this is, in workflow configuration, there is no other status marked as allowed to move to.

In practice, this means that any transition, from this status to any other, is allowed (this probably is implemented for not locking an issue in a dead end status)

However, in view_bug, even if the transition is possible, the option for "change status to" is not present.

I'd rather have the possibility to configure a status that cant be transitioned into any other.
Some use cases for this:

  • A closed/archived status, that I intentionally want to not be modified
  • A special status that is managed by a plugin. I dont want the standard workflow to be able to change this status, it only will be transitioned by the plugin functionality

Note that these use cases are not satisfied by the options "Minimum Access Level to Change to this Status", becasue they'd need to be "changing FROM this status"

Additionally: A status without a transitions row, which is defaulted to all transitions, it still shows:
"You cannot move an issue out of this status"
In manage_config_workflow_page.php

TagsNo tags attached.

Relationships

has duplicate 0020257 closedcproensa In workflow config, better explain for status not used 
related to 0021203 closedcproensa option auto_set_status_to_assigned can change status even if not allowed by workflow 

Activities

cproensa

cproensa

2016-07-05 18:09

developer   ~0053516

Any opinions on this?
I am having several issues, as part of developing complex plugins, by needing some strict configurations. And this issue is blocking the consistence of these.

IMO, transistions should comply strictly to the workflow settings:
a status withouth any outbound status configured, should not allow transitions.

cproensa

cproensa

2016-08-01 08:01

developer   ~0053736

@vboctor @dregad @atrol
Anny support for it?

vboctor

vboctor

2016-08-01 09:08

manager   ~0053737

This seems like a breaking change and may confuse users when all of a sudden they are not able to do things that they were able to do before. So it may be worth exploring other options.

One option is to enable plugins to filter the valid target statuses for an issue. This may be dependent on plugin logic, issue details beyond status, etc.

cproensa

cproensa

2016-08-01 09:23

developer   ~0053738

Se the attached screenshot for a bug in such status.
The change status control is not showed.
The status may be changed by group actions though, as that shows all status (regadless of workflow settings)

So one issue, is that the status selector should be available, according to current logic.

A secondary issue, but no less important:
There is no way to configure a status that has no valid transitions.



Selección_036.png (12,542 bytes)
Selección_036.png (12,542 bytes)
cproensa

cproensa

2016-08-01 11:45

developer   ~0053739

@vboctor
The empty option check was introduced here: 0014013
commit
241ae23b4912dbd83da3fa9e611322a1646e50b7

regarding defaults:
"By default, there is no workflow defined, which means that all states are accessible from any other, by anyone."

This is from config_defaults_inc
$g_status_enum_workflow = array().

Note this inconsistency again:
manage_config_workflow_page.php, for the default array(), shows all status checked. If saved, a local config is created with the filled matrix, even if no change is made.

I suggest setting this semantics:
1) IF status_enum_workflow == array() RETURN true
This means all transitions are valid, to keep this default working.

2) If any row is not set
Keep this check, for the case where new status are introduced, and still not updated in the config matrix

if ( !isset( $t_status_enum_workflow[$p_bug_status] ) ) {
        return true;
    }
  • However, manage workflow page should show this case as a row with all status checked, same logic as (1)

3) make the workflow config save an empty array if no status are checked, so tha:
there exists a row $t_status_enum_workflow[$p_bug_status] (which is empty)
MantisEnum::hasValue( $t_allowed_states, $p_wanted_status ) returns false naturally

I have tested that hardcoding status_enum_workflow[STATUS] = ''
works in my expected way, where no transitions are allowed

cproensa

cproensa

2016-08-04 13:05

developer   ~0053749

Updated description with another inconsistency:

A status without a transitions row, which is defaulted to all transitions, it still shows:
"You cannot move an issue out of this status"
In manage_config_workflow_page.php

cproensa

cproensa

2016-08-04 13:48

developer   ~0053750

submitted PR: https://github.com/mantisbt/mantisbt/pull/836
with the changes.

It does not break current configurations and behaviour.

Related Changesets

MantisBT: master-1.3.x c2bee49c

2016-08-04 12:54:07

cproensa


Committer: dregad Details Diff
Modify empty and default cases for workflow configuration

Fix several inconsistencies with the treatment of status_enum_workflow
configuration.

1. Fix showing a non existant status row in workflow config array. This
is interpreted as if that status allows all transitions, but in the
config page, the checks were shown unmarked, which can be confusing.
Now the checks appear marked in this situation.

2. As consequence of (1), the message "You cannot move an issue out
of this status" is not show anymore in that situation.

3. When a status row is saved with all transitions unchecked, an empty
enum string is saved, meaning effectively that no transitions are
allowed from that status. This specific configuration was previously
unavailable from the workflow config page.

Fixes 0020682

Signed-off-by: Damien Regad <dregad@mantisbt.org>

Original commit message reworded and formatted
mod - core/workflow_api.php Diff File
mod - manage_config_workflow_set.php Diff File

Issue History

Date Modified Username Field Change
2016-03-09 18:32 cproensa New Issue
2016-07-05 18:04 cproensa Relationship added duplicate of 0021203
2016-07-05 18:09 cproensa Note Added: 0053516
2016-07-05 18:35 cproensa Relationship deleted 0021203
2016-07-05 18:35 cproensa Relationship added related to 0021203
2016-08-01 08:01 cproensa Note Added: 0053736
2016-08-01 09:08 vboctor Note Added: 0053737
2016-08-01 09:23 cproensa File Added: Selección_036.png
2016-08-01 09:23 cproensa Note Added: 0053738
2016-08-01 11:45 cproensa Note Added: 0053739
2016-08-04 13:04 cproensa Description Updated View Revisions
2016-08-04 13:05 cproensa Note Added: 0053749
2016-08-04 13:48 cproensa Note Added: 0053750
2016-08-04 17:39 cproensa Assigned To => cproensa
2016-08-04 17:39 cproensa Status new => assigned
2016-08-05 05:39 dregad Changeset attached => MantisBT master-1.3.x c2bee49c
2016-08-05 05:39 dregad Assigned To cproensa => dregad
2016-08-05 05:39 dregad Status assigned => resolved
2016-08-05 05:39 dregad Resolution open => fixed
2016-08-05 05:39 dregad Fixed in Version => 1.3.1
2016-08-05 05:43 dregad Assigned To dregad => cproensa
2016-08-05 05:43 dregad Target Version => 1.3.1
2016-08-20 20:36 cproensa Relationship added has duplicate 0020257
2016-08-28 01:12 vboctor Status resolved => closed