Changes between Version 2 and Version 3 of TracWorkflow


Ignore:
Timestamp:
12/02/2016 05:46:01 PM (13 months ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TracWorkflow

    v2 v3  
    77== The Default Ticket Workflow
    88
    9 === Environments upgraded from 0.10
    10 
    11 When you run `trac-admin <env> upgrade`, your `trac.ini` will be modified to include a `[ticket-workflow]` section.
    12 The workflow configured in this case is the original workflow, so that ticket actions will behave like they did in 0.10:
    13 
    14 {{{#!Workflow width=500 height=240
    15 leave = * -> *
    16 leave.operations = leave_status
    17 leave.default = 1
    18 accept = new -> assigned
    19 accept.permissions = TICKET_MODIFY
    20 accept.operations = set_owner_to_self
    21 resolve = new,assigned,reopened -> closed
    22 resolve.permissions = TICKET_MODIFY
    23 resolve.operations = set_resolution
    24 reassign = new,assigned,reopened -> new
    25 reassign.permissions = TICKET_MODIFY
    26 reassign.operations = set_owner
    27 reopen = closed -> reopened
    28 reopen.permissions = TICKET_CREATE
    29 reopen.operations = del_resolution
    30 }}}
    31 
    32 There are some significant caveats in this, such as accepting a ticket sets it to 'assigned' state, and assigning a ticket sets it to 'new' state. So you will probably want to migrate to "basic" workflow, see contrib/workflow/migrate_original_to_basic.py.
    33 
    34 === Environments created with 0.11
    35 
    36 When a new environment is created, a default workflow is configured in your trac.ini. This workflow is the basic workflow, such as specified in `basic-workflow.ini`, which is somewhat different from the workflow of the 0.10 releases:
     9When a new environment is created, a default workflow is configured in your trac.ini. This workflow is the basic workflow, such as specified in [trac:source:/trunk/trac/ticket/workflows/basic-workflow.ini basic-workflow.ini]:
    3710
    3811{{{#!Workflow width=700 height=300
     
    4013leave.operations = leave_status
    4114leave.default = 1
     15
     16create = <none> -> new
     17create.default = 1
     18
     19create_and_assign = <none> -> assigned
     20create_and_assign.label = assign
     21create_and_assign.permissions = TICKET_MODIFY
     22create_and_assign.operations = may_set_owner
     23
    4224accept = new,assigned,accepted,reopened -> accepted
    4325accept.permissions = TICKET_MODIFY
    4426accept.operations = set_owner_to_self
     27
    4528resolve = new,assigned,accepted,reopened -> closed
    4629resolve.permissions = TICKET_MODIFY
    4730resolve.operations = set_resolution
     31
    4832reassign = new,assigned,accepted,reopened -> assigned
    4933reassign.permissions = TICKET_MODIFY
    5034reassign.operations = set_owner
     35
    5136reopen = closed -> reopened
    5237reopen.permissions = TICKET_CREATE
     
    8166- **del_owner** -- Clear the owner field.
    8267- **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.
     68 - ''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. Groups and permissions may also be included in the list //(Since 1.1.3)//. When groups or permissions are specified the select is populated with all members of the group or all users that possess the permission.
    8469- **set_owner_to_self** -- Sets the owner to the logged in user.
     70- **may_set_owner** -- Sets the owner to the selected or entered owner. Defaults to the existing owner. //(Since 1.1.2)//.
    8571- **del_resolution** -- Clears the resolution field.
    8672- **set_resolution** -- Sets the resolution to the selected value.
     
    8874 {{{#!ini
    8975resolve_new = new -> closed
    90 resolve_new.name = resolve
     76resolve_new.label = resolve
    9177resolve_new.operations = set_resolution
    9278resolve_new.permissions = TICKET_MODIFY
     
    9783'''Note:''' Specifying conflicting operations, such as `set_owner` and `del_owner`, has unspecified results.
    9884
    99 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`:
     85In this example, we see the `.label` attribute used. The action here is `resolve_accepted`, but it will be presented to the user as `resolve`:
    10086
    10187{{{#!ini
    10288resolve_accepted = accepted -> closed
    103 resolve_accepted.name = resolve
     89resolve_accepted.label = resolve
    10490resolve_accepted.permissions = TICKET_MODIFY
    10591resolve_accepted.operations = set_resolution
    10692}}}
     93
     94In this example, we see the `.label` attribute used.  The action here is `resolve_accepted`, but it will be presented to the user as `resolve`. The `.label` attribute is new in Trac 1.1.3 and is functionally the same as the `.name` attribute, which is now deprecated. If neither `.label` or `.name` is specified, the action will be presented to the user as //resolve accepted//, the underscores having been replaced by whitespace (//Since 1.1.3//).
    10795
    10896For actions that should be available in all states, `*` may be used in place of the state. The obvious example is the `leave` action:
     
    116104If not specified for an action, `.default` is 0. The value may be negative.
    117105
    118 There 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.
     106The ticket create actions are specified by a transition from the special `<none>` state. At least one create action must be available to the user in order for tickets to be created. The create actions defined in the default workflow are:
     107{{{#!ini
     108create = <none> -> new
     109create.default = 1
     110
     111create_and_assign = <none> -> assigned
     112create_and_assign.label = assign
     113create_and_assign.permissions = TICKET_MODIFY
     114create_and_assign.operations = may_set_owner
     115}}}
     116
     117
     118There is one hard-coded constraints to the workflow: tickets are expected to have a `closed` state. The default reports/queries treat any state other than `closed` as an open state.
    119119
    120120The special `_reset` action is added by default for tickets that are in states that are no longer defined. This allows tickets to be individually "repaired" after the workflow is changed, although it's recommended that the administrator perform the action by batch modifying the affected tickets. By default the `_reset` action is available to users with the `TICKET_ADMIN` permission and reset tickets are put in the //new// state. The default `_reset` action is equivalent to the following `[ticket-workflow]` action definition:
     
    122122{{{#!ini
    123123_reset = -> new
    124 _reset.name = reset
     124_reset.label = reset
    125125_reset.operations = reset_workflow
    126126_reset.permissions = TICKET_ADMIN
     
    132132{{{#!ini
    133133_reset = -> new
    134 _reset.name = reset
     134_reset.label = reset
    135135_reset.operations = reset_workflow
    136136_reset.permissions = TICKET_MODIFY
     
    158158{{{#!ini
    159159testing = new,accepted,needs_work,assigned,reopened -> testing
    160 testing.name = Submit to reporter for testing
     160testing.label = Submit to reporter for testing
    161161testing.permissions = TICKET_MODIFY
    162162
    163163reject = testing -> needs_work
    164 reject.name = Failed testing, return to developer
     164reject.label = Failed testing, return to developer
    165165
    166166pass = testing -> closed
    167 pass.name = Passes Testing
     167pass.label = Passes Testing
    168168pass.operations = set_resolution
    169169pass.set_resolution = fixed
     
    204204{{{#!ini
    205205reassign_reviewing = reviewing -> *
    206 reassign_reviewing.name = reassign review
     206reassign_reviewing.label = reassign review
    207207reassign_reviewing.operations = set_owner
    208208reassign_reviewing.permissions = TICKET_MODIFY
     
    213213{{{#!ini
    214214[ticket-workflow]
     215create = <none> -> new
     216create.default = 1
     217create_and_assign = <none> -> assigned
     218create_and_assign.label = assign
     219create_and_assign.permissions = TICKET_MODIFY
     220create_and_assign.operations = may_set_owner
    215221accept = new,reviewing -> assigned
    216222accept.operations = set_owner_to_self
     
    233239reassign_reviewing = reviewing -> *
    234240reassign_reviewing.operations = set_owner
    235 reassign_reviewing.name = reassign review
     241reassign_reviewing.label = reassign review
    236242reassign_reviewing.permissions = TICKET_MODIFY
    237243}}}
     
    243249{{{#!ini
    244250resolve_new = new -> closed
    245 resolve_new.name = resolve
     251resolve_new.label = resolve
    246252resolve_new.operations = set_resolution
    247253resolve_new.permissions = TICKET_MODIFY
     
    265271== Ideas for next steps
    266272
    267 New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component.  You can also document ideas on the [trac:TracIdeas/TracWorkflow TracIdeas/TracWorkflow] page. Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations.
    268 
    269 Some of the ideas described here are originally proposed in [trac:NewWorkflow].
     273Enhancement ideas for the workflow system should be filed as enhancement tickets against the [trac:query:?status=assigned&status=new&status=reopened&keywords=~workflow&component=ticket+system ticket system] component.  You can also document ideas on the [trac:TracIdeas/TracWorkflow TracIdeas/TracWorkflow] page. Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations.