Changes between Version 1 and Version 2 of TracWorkflow


Ignore:
Timestamp:
06/05/2014 06:41:08 PM (5 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TracWorkflow

    v1 v2  
    1111Graphically, that looks like this:
    1212
    13 [[Image(htdocs:../common/guide/original-workflow.png)]]
     13{{{#!Workflow width=500 height=240
     14leave = * -> *
     15leave.operations = leave_status
     16leave.default = 1
     17accept = new -> assigned
     18accept.permissions = TICKET_MODIFY
     19accept.operations = set_owner_to_self
     20resolve = new,assigned,reopened -> closed
     21resolve.permissions = TICKET_MODIFY
     22resolve.operations = set_resolution
     23reassign = new,assigned,reopened -> new
     24reassign.permissions = TICKET_MODIFY
     25reassign.operations = set_owner
     26reopen = closed -> reopened
     27reopen.permissions = TICKET_CREATE
     28reopen.operations = del_resolution
     29}}}
    1430
    1531There 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?
     
    2137Graphically, it looks like this:
    2238
    23 [[Image(htdocs:../common/guide/basic-workflow.png)]]
     39{{{#!Workflow width=700 height=300
     40leave = * -> *
     41leave.operations = leave_status
     42leave.default = 1
     43accept = new,assigned,accepted,reopened -> accepted
     44accept.permissions = TICKET_MODIFY
     45accept.operations = set_owner_to_self
     46resolve = new,assigned,accepted,reopened -> closed
     47resolve.permissions = TICKET_MODIFY
     48resolve.operations = set_resolution
     49reassign = new,assigned,accepted,reopened -> assigned
     50reassign.permissions = TICKET_MODIFY
     51reassign.operations = set_owner
     52reopen = closed -> reopened
     53reopen.permissions = TICKET_CREATE
     54reopen.operations = del_resolution
     55}}}
    2456
    2557== Additional Ticket Workflows ==
    2658
    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.
     59There 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. However if you have existing tickets then there may be issues if those tickets have states that are not in the new workflow.
    2860
    2961Here are some [http://trac.edgewall.org/wiki/WorkFlow/Examples diagrams] of the above examples.
    3062
    3163== Basic Ticket Workflow Customization ==
     64
     65Note: 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.
    3266
    3367Create a `[ticket-workflow]` section in `trac.ini`.
     
    5084 - del_resolution -- Clears the resolution field
    5185 - set_resolution -- Sets the resolution to the selected value.
    52    - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value.
    53 {{{
    54 Example:
    55 
     86   - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example:
     87     {{{
    5688resolve_new = new -> closed
    5789resolve_new.name = resolve
     
    5991resolve_new.permissions = TICKET_MODIFY
    6092resolve_new.set_resolution = invalid,wontfix
    61 }}}
     93     }}}
    6294 - leave_status -- Displays "leave as <current status>" and makes no change to the ticket.
    6395'''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results.
     
    83115There are a couple of hard-coded constraints to the workflow.  In particular, tickets are created with status `new`, and tickets are expected to have a `closed` state.  Further, the default reports/queries treat any state other than `closed` as an open state.
    84116
    85 While creating or modifying a ticket workfow, `contrib/workflow/workflow_parser.py` may be useful.  It can create `.dot` files that [http://www.graphviz.org GraphViz] understands to provide a visual description of the workflow.
     117While creating or modifying a ticket workflow, `contrib/workflow/workflow_parser.py` may be useful.  It can create `.dot` files that [http://www.graphviz.org GraphViz] understands to provide a visual description of the workflow.
    86118
    87119This can be done as follows (your install path may be different).
     
    92124And then open up the resulting `trac.pdf` file created by the script (it will be in the same directory as the `trac.ini` file).
    93125
     126An online copy of the workflow parser is available at http://foss.wush.net/cgi-bin/visual-workflow.pl
     127
    94128After you have changed a workflow, you need to restart apache for the changes to take effect. This is important, because the changes will still show up when you run your script, but all the old workflow steps will still be there until the server is restarted.
    95129
     
    99133
    100134{{{
    101 testing = new,accepted,needs_work -> testing
     135testing = new,accepted,needs_work,assigned,reopened -> testing
    102136testing.name = Submit to reporter for testing
    103137testing.permissions = TICKET_MODIFY
     
    112146}}}
    113147
     148=== How to combine the `tracopt.ticket.commit_updater` with the testing workflow ===
     149
     150The [[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] is the optional component that [[TracRepositoryAdmin#trac-post-commit-hook|replaces the old trac-post-commit-hook]], in Trac 0.12.
     151
     152By default it reacts on some keywords found in changeset message logs like ''close'', ''fix'' etc. and performs the corresponding workflow action.
     153
     154If you have a more complex workflow, like the testing stage described above and you want the ''closes'' keyword to move the ticket to the ''testing'' status instead of the ''closed'' status, you need to adapt the code a bit.
     155
     156Have a look at the [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 recipe]] for the `trac-post-commit-hook`, this will give you some ideas about how to modify the component.
     157
    114158== Example: Add simple optional generic review state ==
    115159
     
    151195leave.default = 1
    152196leave.operations = leave_status
    153 reassign = new,assigned,reopened -> new
     197reassign = new,assigned,accepted,reopened -> assigned
    154198reassign.operations = set_owner
    155199reassign.permissions = TICKET_MODIFY
     
    197241== some ideas for next steps ==
    198242
    199 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.
     243New 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 [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations.
    200244
    201245If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket.
     
    216260
    217261 * Actions should be selectable based on the ticket type (different Workflows for different tickets)
    218 ''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.''
     262''Look into the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin]'s `triage` operation.''
     263
     264 * I'd wish to have an option to perform automatic status changes. In my case, I do not want to start with "new", but with "assigned". So tickets in state "new" should automatically go into state "assigned". Or is there already a way to do this and I just missed it?
     265''Have a look at [http://trac-hacks.org/wiki/TicketCreationStatusPlugin TicketCreationStatusPlugin] and [http://trac-hacks.org/wiki/TicketConditionalCreationStatusPlugin TicketConditionalCreationStatusPlugin]''
     266
     267 * I added a 'testing' state. A tester can close the ticket or reject it. I'd like the transition from testing to rejected to set the owner to the person that put the ticket in 'testing'. The [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] is close with set_owner_to_field, but we need something like set_field_to_owner.
     268
     269 * I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state.