Edgewall Software

Changes between Version 56 and Version 57 of TracWorkflow


Ignore:
Timestamp:
Aug 18, 2014, 9:01:09 AM (10 years ago)
Author:
Ryan J Ollos
Comment:

Minor changes. Mention the Workflow macro before the less user-friendly workflow_parser script. Add syntax highlighting to ini blocks. Bold the workflow operations.

Legend:

Unmodified
Added
Removed
Modified

  • TracWorkflow

    v56 v57  
    33[[TracGuideToc]]
    44
    5 The Trac issue database provides a configurable workflow.
     5The Trac ticket system provides a configurable workflow.
    66
    77== The Default Ticket Workflow ==
    … …  
    6969Within this section, each entry is an action that may be taken on a ticket.
    7070For example, consider the `accept` action from `simple-workflow.ini`:
    71 {{{
     71{{{#!ini
    7272accept = new,accepted -> accepted
    7373accept.permissions = TICKET_MODIFY
    … …  
    7979
    8080The available operations are:
    81  - del_owner -- Clear the owner field.
    82  - set_owner -- Sets the owner to the selected or entered owner. Defaults to the current user. When `[ticket] restrict_owner = true`, the select will be populated with users that have `TICKET_MODIFY` permission and an authenticated session.
    83    - ''actionname''`.set_owner` may optionally be set to a comma delimited list or a single value.
    84  - set_owner_to_self -- Sets the owner to the logged in user.
    85  - del_resolution -- Clears the resolution field
    86  - set_resolution -- Sets the resolution to the selected value.
    87    - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example:
    88      {{{
     81- **del_owner** -- Clear the owner field.
     82- **set_owner** -- Sets the owner to the selected or entered owner. Defaults to the current user. When `[ticket] restrict_owner = true`, the select will be populated with users that have `TICKET_MODIFY` permission and an authenticated session.
     83 - ''actionname''`.set_owner` may optionally be set to a comma delimited list of users that will be used to populate the select, or a single user.
     84- **set_owner_to_self** -- Sets the owner to the logged in user.
     85- **del_resolution** -- Clears the resolution field
     86- **set_resolution** -- Sets the resolution to the selected value.
     87 - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example:
     88 {{{#!ini
    8989resolve_new = new -> closed
    9090resolve_new.name = resolve
    … …  
    9292resolve_new.permissions = TICKET_MODIFY
    9393resolve_new.set_resolution = invalid,wontfix
    94      }}}
    95  - leave_status -- Displays "leave as <current status>" and makes no change to the ticket.
     94}}}
     95- **leave_status** -- Displays "leave as <current status>" and makes no change to the ticket.
    9696'''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results.
    9797
    98 {{{
     98In this example, we see the `.name` attribute used.  The action here is `resolve_accepted`, but it will be presented to the user as `resolve`.
     99
     100{{{#!ini
    99101resolve_accepted = accepted -> closed
    100102resolve_accepted.name = resolve
    … …  
    103105}}}
    104106
    105 In this example, we see the `.name` attribute used.  The action here is `resolve_accepted`, but it will be presented to the user as `resolve`.
    106 
    107107For actions that should be available in all states, `*` may be used in place of the state.  The obvious example is the `leave` action:
    108 {{{
     108{{{#!ini
    109109leave = * -> *
    110110leave.operations = leave_status
    … …  
    116116There 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.
    117117
    118 While 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.
    119 
    120 This can be done as follows (your install path may be different).
    121 {{{
     118Workflows can be visualized by rendering them on the wiki using the [WikiMacros#Workflow-macro Workflow macro].
     119
     120Workflows can also be visualized using the `contrib/workflow/workflow_parser.py` script.  The script outputs `.dot` files that [http://www.graphviz.org GraphViz] understands. The script can be used as follows (your install path may be different):
     121{{{#!sh
    122122cd /var/local/trac_devel/contrib/workflow/
    123123sudo ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini
    124124}}}
    125125And then open up the resulting `trac.pdf` file created by the script (it will be in the same directory as the `trac.ini` file).
    126 
    127 Workflows can also be rendered on the wiki using the [WikiMacros#Workflow-macro Workflow macro].
    128126
    129127After 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.
    … …  
    163161The new `reviewing` state along with its associated `review` action looks like this:
    164162
    165 {{{
     163{{{#!ini
    166164review = new,assigned,reopened -> reviewing
    167165review.operations = set_owner
    … …  
    171169Then, 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:
    172170
    173 {{{
     171{{{#!ini
    174172accept = new,reviewing -> assigned
    175173[…]
    … …  
    179177Optionally, 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.
    180178
    181 {{{
     179{{{#!ini
    182180reassign_reviewing = reviewing -> *
    183181reassign_reviewing.name = reassign review
    … …  
    188186The full `[ticket-workflow]` configuration will thus look like this:
    189187
    190 {{{
     188{{{#!ini
    191189[ticket-workflow]
    192190accept = new,reviewing -> assigned
    … …  
    216214== Example: Limit the resolution options for a new ticket ==
    217215
    218 The above resolve_new operation allows you to set the possible resolutions for a new ticket.  By modifying the existing resolve action and removing the new status from before the `->` we then get two resolve actions.  One with limited resolutions for new tickets, and then the regular one once a ticket is accepted.
    219 
    220 {{{
     216The above `resolve_new` operation allows you to set the possible resolutions for a new ticket.  By modifying the existing resolve action and removing the new status from before the `->` we then get two resolve actions.  One with limited resolutions for new tickets, and then the regular one once a ticket is accepted.
     217
     218{{{#!ini
    221219resolve_new = new -> closed
    222220resolve_new.name = resolve