•  
     
    story #12187 configure workflow pre & post actions at target state level
Summary
tracker admin
configure workflow pre & post actions at target state level

I get a easier interface to configure the worklow and I reduce risks of errors
 

Overview

The goal of this story is to propose, by default, the configuration of workflow pre-conditions and post-actions at target state globally instead of having to define it for each transition.

For instance I would configure what happens when artifact status becomes "On going", regardless of previous state, rather than having to define what happens when artifact goes from "new" to "On going" + "todo" to "On going" + "review" to "On going", etc.

As pre-conditions and post actions tends to be the same for a given state it reduces the risk of having one specific transition that, un-expectedly behaves diffrently.

The "per transition" configuration would remain possible (at minimum for backward compatibility) but not shown by default.

See live mockup: https://s.codepen.io/enalean/debug/dace752a350bcecdad1003e505bc9992

Functional overview

Tracker administrator point of view

The worflow configuration matrix overall design is improved to be easier to read

By default, a click on a transition cell only allow/disallow the transition it self (eg. I allow change from "To do" to "On going") but I don't have a "[details]" link.

The transition configuration screen is accessible by a click on the target state "On going".

A tracker administrator can activate "Advanced mode" where each transition can be configured independently. It's the default mode for all existing trackers. When tracker admin switch from "Simple mode" to "Advanced mode", all configurations are done at transition level (no longer at state level) and switch will copy all configurations (pre-conditions, post-actions that were defined at state level into each defined transition).

On workflow in "Advanced mode", a tracker administrator can activate "Simple mode" (to only have 1 configuration). In this case the first configuration in the target column is selected and applied the whole state. As this operation can break something, a warning message is displayed to ensure tracker admin is sure he wants to continue.

End user point of view

Nothing change. On artifact creation and update, the pre-conditions and post-actions are applied as soon as the target state is reached (given the transition exists in the workflow).

Technical Overview

REST routes

  • Get workflow field
  • Get configuration mode (advanced or simple)
  • Get transition rule activation
  • Get all transitions of a tracker

GET /trackers/:id with response content:

{
    "workflow": {
        "field_id": 0,
        "is_used": false,
        "transitions": [],
...
    },
}

Info: this route already exists

  • Set new workflow field:

PATCH /trackers/:id with request content:

{ workflow: {
  set_transitions_rules: {
    field_id: 123
  }
}}

Warning: "400 Bad Request" if a field is already defined.
Info: transition rule is disabled by default.

  • Remove current workflow field:

PATCH /trackers/:id with request content:

{ workflow: {
  delete_transitions_rules: true
}}

Info: this will remove all associated transitions and rules.

  • Enable / disable transition rules:

PATCH /trackers/:id with request content:

{ workflow: {
  set_transitions_rules: {
    is_used: true
  }
}}
  • Switch between simple and advanced mode:

PATCH /trackers/:id with request content:

{ workflow: {
  set_transitions_rules: {
    is_advanced: true
  }
}}

Info: when switching from advanced mode to simple mode, transitions rules are updated to have same rules by target state.

  • Add new transition

POST /tracker_workflow_transitions with request content:

{
    "tracker_id": int,
    "from": int,
    "to": int
}

with response content:

{
    "id": int,
    "uri": string
}

Info: when simple mode, rules of target state is added to this transition

  • Remove a transition

DELETE /tracker_workflow_transitions/:id

  • [advanced mode] Get conditions of a transition

GET /tracker_workflow_transitions/:id with response content:

{
    "id": int,
    "uri": string,
    "comment_not_empty": bool,
    "fields_not_empty": [ field_id ],
    "allowed_ugroups": [ ugroup_id ]
}

Note: tracker_id, from and to are note present here

  • [advanced mode] Get all actions of a transition

GET /tracker_workflow_transitions/id/actions with response content:

[
    {
        "id",
        "type",
        "settings": {}
    },
    ...
]
  • Update rules of a transition

PUT /tracker_workflow_transitions/id/actions with request content:

[ 
    { 
        "type", 
        "settings": {}
    },
    ...
]

with response content:

{
    "id": int,
    "uri": string
}

Info: in simple mode, this will update all other transitions with same target state.

  • [simple mode] Get conditions of all transitions to a state

Use "[advanced mode] Get conditions of a transition" with first transition of the state

  • [simple mode] Get all actions of all transitions to a state

Use "[advanced mode] Get all actions of a transition" with first transition of the state

  • Additional routes to create
OPTIONS /tracker_workflow_transitions
OPTIONS /tracker_workflow_transitions/:id

Frontend

Matrix + modale are made with vue/vuex

Warning: transition from "New artifact" -> XXX some pre-conditions cannot apply (comment not empty). Be carful to handle that properly

On "Simple" mode

The new "simple" mode is actually wrapped around the existing structure and data model where each transition owns pre-conditions and transations. This way there is no modification of workflow checking on the platform, the database layout is not changed, etc. This saves a lot of pain.

However, the backend must ensure the consistency, hence modification of one transition will be propagated to sibling transactions transparently.

When a pre-condition or post-action is applied on 1 transition, the backend force apply on all transitions by truncating existing values and re-creating.

Example, given the following configuration

|from/to    |        "on going"          |
|-----------|--------------------------- |
|"new"      |  [                         |
|           |   {1, int, {0}},           |
|           |   {2, jenkins, {"url1"}},  |
|           |   {3, jenkins, {"url2"}}   |
|           |  ]                         |
|--------------------------------------- |
|"on going" |           X                |
|--------------------------------------- |
|"done"     | [                          |
|           |   {10, int, {0}},          |
|           |   {11, jenkins, {"url1"}}, |
|           |   {12, jenkins, {"url2"}}  |
|           | ]                          |
|--------------------------------------- |

When there is a PATCH/PUT on /tracker_workflow_transitions/id/actions to set {2, jenkins, {"url10"}}

This applies to both "new" -> "on going" and "done" -> "on going" transitions and the second one is truncated, hence ids change:

|from/to    |        "on going"          |
|-----------|--------------------------- |
|"new"      |  [                         |
|           |   {1, int, {0}},           |
|           |   {2, jenkins, {"url10"}}, |
|           |   {3, jenkins, {"url2"}}   |
|           |  ]                         |
|--------------------------------------- |
|"on going" |           X                |
|--------------------------------------- |
|"done"     | [                          |
|           |   {15, int, {0}},          |
|           |   {16, jenkins, {"url10"}},|
|           |   {17, jenkins, {"url2"}}  |
|           | ]                          |
|--------------------------------------- |

Adding a new field value in Simple mode

When a new field value is added, there is no impact on the transitions themselves. Let say your workflow looks like the following matrix with pre-conditions and post-actions set on Done (materialized with the []).

     | Todo | [Done] |
-----|------|--------|
Todo |      |   x    |
-----|------|--------|
Done |      |        |
-----|------|--------|

When "Archived" state is added, the matrix looks like this

     | Todo | [Done] | Archived |
-----|------|--------|----------|
Todo |      |   x    |          |
-----|------|--------|----------|
Done |      |        |          |
-----|------|--------|----------|
Arch |      |        |          |
-----|------|--------|----------|

No transition is modified by the addition of this value. However if the transition Arch -> Done is added, the configuration made on [Done] must be applied on Arch -> Done transition.

     | Todo | [Done] | Archived |
-----|------|--------|----------|
Todo |      |   x    |          |
-----|------|--------|----------|
Done |      |        |          |
-----|------|--------|----------|
Arch |      |   x    |          |
-----|------|--------|----------|

Development

The new interface is developed in a new route alongside the existing one. The switch will be done when the new interface will be complete.

In order to not block people with unforeseen use cases and/or work around issues, the switch to the new interface will be progressive. First, there will be a feature flag configuration value to allow users access to the new interface for specific trackers. The old interface will be accessible again after unsetting the configuration value.
Once project admins have added new post actions to their workflow, they will not be able to see, edit or delete them in the old interface. If they want to go back to the old interface, they will first need to clear (delete) their workflow or remove the new post actions with the new interface.

Story split

  1. Introduce new page (the existing page is left untouched and is still used by default, one should know the new page URL to get access)
    1. New end-point for WF admin
    2. The breadcrumbs
    3. The 2 tab list (2 levels of menu for workflow admin)
    4. Ability to choose the field on which WF applies (REST PATCH)
    5. Ability to enable/disable the WF (REST PATCH)

        For 4 & 5 see the live mockup here https://s.codepen.io/enalean/debug/5c3599ce2bd94287bb30112569c2d85b#

  1. Read only matrix
    1. Display the matrix with CSS helps on big tables
    2. Display the transitions
  2. Transitions
    1. click to activate & desactivate transition
    2. REST route to save that
  3. Modale
    1. Introduce modale to edit transitions. Only pre-conditions can be set
  4. Modale full
    1. Modale can be used to configura post-actions
    2. Introduce a configuration value "feature flag" to allow specific trackers to switch to the new UI. Once set, the "Transitions" button links to the new UI.
  5. Finalise with "Simple" mode
    1. Introduce UI to switch from Simple to Advanced mode
    2. Update REST routes to take into account propagation is "Advanced" mode
    3. Deprecate old UI
Benjamin Dauton (bdauton)
Status
On going
Development
Empty
Empty
Details
#12187
Manuel Vacelet (vaceletm)
2019-01-15 12:42
2018-08-27 16:10
3366

References

List of items referenced by or referencing this item.

Git commit

Follow-ups

  • User avatar
    gerrit #13640 integrated into Tuleap 10.9.99.78
  • User avatar
    gerrit #13607 integrated into Tuleap 10.9.99.69
  • User avatar
    gerrit #13649 integrated into Tuleap 10.9.99.62.
  • User avatar
    gerrit #13647 integrated into Tuleap 10.9.99.60
  • User avatar
    gerrit #13645 integrated into Tuleap 10.9.99.53
  • User avatar
    gerrit #13621 integrated into Tuleap 10.9.99.51
  • User avatar
    gerrit #13619 integrated into Tuleap 10.9.99.47
  • User avatar
    gerrit #13625 integrated into Tuleap 10.9.99.45
  • User avatar
    gerrit #13624 integrated into Tuleap 10.9.99.44
  • User avatar
    gerrit #13588 integrated into Tuleap 10.9.99.42
  • User avatar
    gerrit #13620 integrated into Tuleap 10.9.99.37
  • User avatar
    gerrit #13604 integrated into Tuleap 10.9.99.32
  • User avatar
    gerrit #13610 integrated into Tuleap 10.9.99.29
  • User avatar
    • Acceptance criteria
  • User avatar
    gerrit #13550 integrated into Tuleap 10.9.99.17
  • User avatar
    gerrit #13587 integrated into Tuleap 10.9.99.14
  • User avatar
    gerrit #13583 integrated into Tuleap 10.9.99.12
  • User avatar
    gerrit #13574 integrated into Tuleap 10.9.99.6
  • User avatar
    gerrit #13571 integrated into Tuleap 10.9.99.4
  • User avatar
    gerrit #13573 integrated into Tuleap 10.9.99.2
  • User avatar
    gerrit #13584 integrated into Tuleap 10.9.99.1
  • User avatar
    gerrit #13565 integrated into Tuleap 10.8.99.159.
  • User avatar
    gerrit #13557 integrated into Tuleap 10.8.99.149.
  • User avatar
    gerrit #13522 integrated into Tuleap 10.8.99.139
  • User avatar
    gerrit #13499 integrated into Tuleap 10.8.99.127
  • User avatar
    gerrit #13496 integrated into Tuleap 10.8.99.123
  • User avatar
    • Acceptance criteria
  • User avatar
    last edited by: Joris MASSON (jmasson) 26 days ago
    gerrit #13482 integrated into Tuleap 10.8.99.118
  • User avatar
    gerrit #13442 integrated into Tuleap 10.8.99.109
  • User avatar
    gerrit #13470 integrated into Tuleap 10.8.99.105
  • User avatar
    gerrit #13464 integrated into Tuleap 10.8.99.95
  • User avatar
    gerrit #13463 integrated into Tuleap 10.8.99.89
  • User avatar
    gerrit #13448 integrated into Tuleap 10.8.99.87
  • User avatar
    gerrit #13261 integrated into Tuleap 10.8.99.84
  • User avatar
    gerrit #13428 integrated into Tuleap 10.8.99.65
  • User avatar
    gerrit #13433 integrated into Tuleap 10.8.99.61
  • User avatar
    gerrit #13427 integrated into Tuleap 10.8.99.58
  • User avatar
    gerrit #13296 integrated into Tuleap 10.8.99.57
  • User avatar
    gerrit #13231 integrated into Tuleap 10.8.99.41
  • User avatar
    gerrit #13336 integrated into Tuleap 10.8.99.37

    • Acceptance criteria
  • User avatar
    • Acceptance criteria
  • User avatar
    gerrit #13282 integrated into Tuleap 10.8.99.1
  • User avatar
    gerrit #13295 integrated into Tuleap 10.7.99.169
  • User avatar
    gerrit #13263 integrated into Tuleap 10.7.99.167
  • User avatar
    gerrit #13273 integrated into Tuleap 10.7.99.163
  • User avatar
    • Acceptance criteria
  • User avatar
    gerrit #13153 integrated into Tuleap 10.7.99.154
  • User avatar
    gerrit #13275 integrated into Tuleap 10.7.99.152
  • User avatar
    gerrit #13266 integrated into Tuleap 10.7.99.148
  • User avatar
    gerrit #13258 integrated into Tuleap 10.7.99.145
  • User avatar
    gerrit #13150 integrated into Tuleap 10.7.99.120
  • User avatar
    gerrit #13225 integrated into Tuleap 10.7.99.110
  • User avatar
    • Status changed from To be done to On going
  • User avatar
    gerrit #13222 integrated into Tuleap 10.7.99.101
  • User avatar
    gerrit #13162 integrated into Tuleap 10.7.99.99
  • User avatar
    gerrit #13221 integrated into Tuleap 10.7.99.98.
  • User avatar
    gerrit #13219 integrated into Tuleap 10.7.99.97.
  • User avatar
    gerrit #13209 integrated into Tuleap 10.7.99.84
  • User avatar
    gerrit #13199 integrated into Tuleap 10.7.99.83
  • User avatar
    gerrit #13200 integrated into Tuleap 10.7.99.81
  • User avatar
    gerrit #13163 integrated into Tuleap 10.7.99.70
  • User avatar
    • Acceptance criteria
  • User avatar
    • Acceptance criteria
  • User avatar
    gerrit #13124 integrated into Tuleap 10.7.99.63
  • User avatar
    gerrit #13151 integrated into Tuleap 10.7.99.50
  • User avatar
    gerrit #13155 integrated into Tuleap 10.7.99.49
  • User avatar
    gerrit #13118 integrated into Tuleap 10.7.99.42
  • User avatar
    gerrit #13139 integrated into Tuleap 10.7.99.37
  • User avatar
    gerrit #13113 integrated into Tuleap 10.7.99.34
  • User avatar
    gerrit #13108 integrated into Tuleap 10.7.99.26
  • User avatar
    gerrit #13102 integrated into Tuleap 10.7.99.21
  • User avatar
    gerrit #13109 integrated into Tuleap 10.7.99.20
  • User avatar
    gerrit #13106 integrated into Tuleap 10.7.99.19
  • User avatar
    • Acceptance criteria
    • Attachments error-modal.gif added
  • User avatar

    First contribution by @thimai & @jibidus (gerrit #13099) integrated into Tuleap 10.7.99.16.

    Welcome!

  • User avatar
    • Acceptance criteria
  • User avatar
  • User avatar
    • Acceptance criteria
  • User avatar
    • Acceptance criteria
  • User avatar
    • Acceptance criteria
  • User avatar

    Added live mock-up


    • Acceptance criteria
  • User avatar
    • Acceptance criteria
  • User avatar
    • So that
    • Acceptance criteria
    • CC list set to Benjamin Dauton (bdauton)