UI for editing workflow

[Dave Williss]

I like it!  I especially like having NEEDINFO as a state.  We have it in 
our bugzilla as "resolution" partly because it was easy to add that way, 
but mainly because when we started using bugzilla, we used 
RESOLVED/INVALID to mean the same thing.  But logically if a bug 
NEEDINFO, it's not resolved.

Gervase Markham wrote:
> LpSolit is working on custom statuses and editable workflow. I've 
> mocked up a UI for configuring what transitions are permitted.
>
> What we are basically doing here is configuring permitted and 
> forbidden transitions in a state machine. This particular application 
> cries out for a matrix where you mark a transition as yes/no at each 
> intersection.
>
> http://landfill.bugzilla.org/qa30pg/page.cgi?id=editworkflow.html
>
> [When you define a new status, you say whether it's an open status or 
> a closed one, and that drives the colour (and other things like 
> whether a resolution is required).]
>
> Note click behaviour and tooltips. I think this UI is good because you 
> can visually pick out patterns in the workflow, e.g.:
>
> * The big blue block in the top left shows you can move from any opened
>   state (apart from UNCO) to any other one - except you can't do
>   REOPENED -> NEW.
>
> * The vertical line of three in the middle shows that you can REOPEN
>   from any closed state apart from BURIED.
>
> * The diagonal line in the bottom right shows that RESOLVED -> VERIFIED
>   -> CLOSED -> BURIED is a progression.
>
> * The nearly-empty vertical line on the left shows there's no way back
>   to UNCONFIRMED.
>
> Other features:
>
> * Impossible or meaningless transitions are clearly marked by the lack
>   of a checkbox.
>
> * It easily answers the obvious questions in *both* directions - i.e.
>   "Where can I go from UNCONFIRMED", and "How can I get to VERIFIED". A
>   list-based system would only answer one of those easily.
>
> What do you think?
>
> Gerv
>
> ------------------------------------------------------------------------
>
> [% PROCESS "global/field-descs.none.tmpl" %]
>
> [% INCLUDE global/header.html.tmpl 
>    title = "Edit Workflow" 
>    style = '.col-header { width: 70px; }
>             .checkbox-cell { border: 1px black solid }
>             .open-status { color: green }
>             .closed-status { color: red }
>             .checked { background-color: lightblue }'
> %]
>
> [% open_statuses = ["UNCONFIRMED", "NEEDINFO", "NEW", "ASSIGNED", "REOPENED"] %]
> [% closed_statuses = ["RESOLVED", "VERIFIED", "CLOSED", "BURIED"] %]
> [% test_data = [ [ 1, 2, 0, 0, 0, 0, 0, 0, 0, 0 ],
>                  [ 0, 1, 2, 1, 1, 1, 0, 0, 0, 0 ],
>                  [ 1, 1, 1, 2, 1, 0, 0, 0, 0, 0 ],
>                  [ 0, 1, 1, 1, 2, 1, 0, 0, 0, 0 ],
>                  [ 0, 0, 0, 0, 0, 2, 1, 1, 1, 0 ],
>                  [ 2, 1, 1, 1, 1, 1, 2, 0, 0, 0 ],
>                  [ 2, 0, 0, 0, 0, 0, 1, 2, 0, 0 ],
>                  [ 2, 0, 0, 0, 0, 0, 0, 1, 2, 0 ],
>                  [ 2, 0, 0, 0, 0, 0, 0, 0, 1, 2 ],
>                ]
> %]
>
> [%# List concatenation in TT? %]
> [% statuses =  open_statuses.merge(closed_statuses) %]
>
> [% start = ["{Start}"] %]
> [% status_cols = start.merge(statuses) %]
>
> <script type="text/javascript">
>   function toggle_cell(cell)
>   {
>     if (cell.checked)
>     {
>       cell.parentNode.style.backgroundColor = "lightblue";
>     }
>     else
>     {
>       cell.parentNode.style.backgroundColor = "inherit";
>     }
>   }
> </script>
>
> <p>This page allows you to define which status transitions are valid in your workflow.</p>
>
> <table>
> <tr>
>   <td> </td>
>   <td> </td>
>   <td colspan="[% status_cols.size %]" align="center">
>     <h3>From</h3>
>   </td>
> </tr>
>
> <tr>
>   <th rowspan="[% status_cols.size %]" valign="center"><h3>To</h3></th>
>   <th></th>
>   [% FOREACH status = status_cols %]
>     <th class="col-header
>       [% closed_statuses.grep(status).0 ? " closed-status" : " open-status" %]
>     ">
>       [% status %]
>     </th>
>   [% END %]
> </tr>
>
> [% FOREACH status_row = statuses %]
>   <tr>
>     <th align="right" class="
>       [% closed_statuses.grep(status_row).0 ? " closed-status" : " open-status" %]
>     ">[% status_row %]</th>
>     [% row_index = loop.index %]
>     [% FOREACH status_col = status_cols %]
>       [% col_index = loop.index %]
>       <td align="center" class="checkbox-cell
>         [% " checked" IF test_data.$row_index.$col_index == 1 %]"
>       title="From [% status_col %] to [% status_row %]"
>       >
>         [% IF test_data.$row_index.$col_index != 2 %]
>           <input type="checkbox"
>             [% " checked='checked'" IF test_data.$row_index.$col_index == 1 %]
>             onclick="toggle_cell(this)"
>           >
>         [% END %]
>       </td>
>     [% END %]
>   </tr>
> [% END %]
>
> </table>
>
> <br>
>
> <p>[Note: this is the current Bugzilla workflow, with a couple of extra statuses (NEEDINFO, BURIED) thrown in for illustration purposes. Try clicking a checkbox. I believe this is all the UI that customised statuses would require. The presentation of the knob could be, in most cases, determined programmatically from the current state, the possible new states, and whether the transition was an open -> closed or not.]</p>
>
>
> <br>
>
> [% INCLUDE global/footer.html.tmpl %]
> ------------------------------------------------------------------------
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dwilliss@microimages.com>
>