Changes between Version 1 and Version 2 of TracWorkflow


Ignore:
Timestamp:
06/03/10 15:59:46 (14 years ago)
Author:
zeiss
Comment:

Importing pages from "/var/lib/svn/trac/etsicheck2" using ​WikiImport plugin.

Legend:

Unmodified
Added
Removed
Modified

  • TracWorkflow

    v1 v2  
    1414 
    1515There are some significant "warts" in this; such as accepting a ticket sets it to 'assigned' state, and assigning a ticket sets it to 'new' state.  Perfectly obvious, right? 
    16 So you will probably want to migrate to "basic" workflow; [trac:source:trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] may be helpful. 
     16So you will probably want to migrate to "basic" workflow; `contrib/workflow/migrate_original_to_basic.py` may be helpful. 
    1717 
    1818=== Environments created with 0.11 === 
    … …  
    2525== Additional Ticket Workflows == 
    2626 
    27 There are several example workflows provided in the Trac source tree; look in [trac:source:trunk/contrib/workflow contrib/workflow] for `.ini` config sections.  One of those may be a good match for what you want. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. 
    28  
    29 Here are some [http://trac.edgewall.org/wiki/WorkFlow/Examples diagrams] of the above examples. 
     27There are several example workflows provided in the Trac source tree; look in `contrib/workflow` for `.ini` config sections.  One of those may be a good match for what you want. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. 
    3028 
    3129== Basic Ticket Workflow Customization == 
    32  
    33 Note: Ticket "statuses" or "states" are not separately defined. The states a ticket can be in are automatically generated by the transitions defined in a workflow. Therefore, creating a new ticket state simply requires defining a state transition in the workflow that starts or ends with that state. 
    3430 
    3531Create a `[ticket-workflow]` section in `trac.ini`. 
    … …  
    10197 
    10298{{{ 
    103 testing = new,accepted,needs_work,assigned,reopened -> testing 
     99testing = new,accepted,needs_work -> testing 
    104100testing.name = Submit to reporter for testing 
    105101testing.permissions = TICKET_MODIFY 
    … …  
    112108pass.operations = set_resolution 
    113109pass.set_resolution = fixed 
    114 }}} 
    115  
    116 == Example: Add simple optional generic review state == 
    117  
    118 Sometimes Trac is used in situations where "testing" can mean different things to different people so you may want to create an optional workflow state that is between the default workflow's `assigned` and `closed` states, but does not impose implementation-specific details. The only new state you need to add for this is a `reviewing` state. A ticket may then be "submitted for review" from any state that it can be reassigned. If a review passes, you can re-use the `resolve` action to close the ticket, and if it fails you can re-use the `reassign` action to push it back into the normal workflow. 
    119  
    120 The new `reviewing` state along with its associated `review` action looks like this: 
    121  
    122 {{{ 
    123 review = new,assigned,reopened -> reviewing 
    124 review.operations = set_owner 
    125 review.permissions = TICKET_MODIFY 
    126 }}} 
    127  
    128 Then, to integrate this with the default Trac 0.11 workflow, you also need to add the `reviewing` state to the `accept` and `resolve` actions, like so: 
    129  
    130 {{{ 
    131 accept = new,reviewing -> assigned 
    132 […] 
    133 resolve = new,assigned,reopened,reviewing -> closed 
    134 }}} 
    135  
    136 Optionally, you can also add a new action that allows you to change the ticket's owner without moving the ticket out of the `reviewing` state. This enables you to reassign review work without pushing the ticket back to the `new` status. 
    137  
    138 {{{ 
    139 reassign_reviewing = reviewing -> * 
    140 reassign_reviewing.name = reassign review 
    141 reassign_reviewing.operations = set_owner 
    142 reassign_reviewing.permissions = TICKET_MODIFY 
    143 }}} 
    144  
    145 The full `[ticket-workflow]` configuration will thus look like this: 
    146  
    147 {{{ 
    148 [ticket-workflow] 
    149 accept = new,reviewing -> assigned 
    150 accept.operations = set_owner_to_self 
    151 accept.permissions = TICKET_MODIFY 
    152 leave = * -> * 
    153 leave.default = 1 
    154 leave.operations = leave_status 
    155 reassign = new,assigned,reopened -> new 
    156 reassign.operations = set_owner 
    157 reassign.permissions = TICKET_MODIFY 
    158 reopen = closed -> reopened 
    159 reopen.operations = del_resolution 
    160 reopen.permissions = TICKET_CREATE 
    161 resolve = new,assigned,reopened,reviewing -> closed 
    162 resolve.operations = set_resolution 
    163 resolve.permissions = TICKET_MODIFY 
    164 review = new,assigned,reopened -> reviewing 
    165 review.operations = set_owner 
    166 review.permissions = TICKET_MODIFY 
    167 reassign_reviewing = reviewing -> * 
    168 reassign_reviewing.operations = set_owner 
    169 reassign_reviewing.name = reassign review 
    170 reassign_reviewing.permissions = TICKET_MODIFY 
    171110}}} 
    172111 
    … …  
    193132But if even that is not enough, you can disable the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it. 
    194133 
    195 == Adding Workflow States to Milestone Progress Bars == 
    196  
    197 If you add additional states to your workflow, you may want to customize your milestone progress bars as well.  See [TracIni#milestone-groups-section TracIni]. 
    198  
    199134== some ideas for next steps == 
    200135 
    201 New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component.  If desired, add a single-line link to that ticket here.  Also look at the [th:wiki:AdvancedTicketWorkflowPlugin] as it provides experimental operations. 
     136New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component.  If desired, add a single-line link to that ticket here. 
    202137 
    203138If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket. 
    … …  
    207142   * '''postops''': automatic, when leaving the state/activity 
    208143   * '''actions''': can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows. 
    209 ''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.'' 
     144This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement. 
    210145 
    211146 * operations could be anything: sum up the time used for the activity, or just write some statistical fields like  
    212 ''A workflow plugin can add an arbitrary workflow operation, so this is already possible.'' 
     147A workflow plugin can add an arbitrary workflow operation, so this is already possible. 
    213148 
    214149 * set_actor should be an operation allowing to set the owner, e.g. as a "preop": 
    215150   * either to a role, a person 
    216151   * entered fix at define time, or at run time, e.g. out of a field, or select. 
    217 ''This is either duplicating the existing `set_owner` operation, or needs to be clarified.'' 
     152This is either duplicating the existing `set_owner` operation, or needs to be clarified. 
    218153 
    219154 * Actions should be selectable based on the ticket type (different Workflows for different tickets) 
    220 ''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.'' 
     155This is becoming a frequent request, with clear usecases.  The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point.