Changes between Version 1 and Version 2 of TracWorkflow


Ignore:
Timestamp:
Aug 13, 2014, 12:08:17 AM (12 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • TracWorkflow

    v1 v2  
    66== デフォルトのワークフロー == #TheDefaultTicketWorkflow
    77=== 0.10 からアップグレードした Environment === #Environmentsupgradedfrom0.10
    8 `trac-admin <env> upgrade` を実行したとき、`trac.ini` に `[ticket-workflow]` セクションが追加され、 0.10 でのワークフロー (original ワークフロー) と同様のアクションをするようにデフォルトの設定値が設定されます。
     8`trac-admin <env> upgrade` を実行したとき、`trac.ini` に `[ticket-workflow]` セクションが追加され、
     90.10 でのワークフロー (original ワークフロー) と同様のアクションをするようにデフォルトの設定値が設定されます。
    910
    1011original ワークフローは下図を参照してください:
    1112
    12 [[Image(htdocs:../common/guide/original-workflow.png)]]
    13 
    14 original ワークフローにはいくつかの重要な "欠点" があります; 新しいチケットを承認 (accept) したときにステータスは 'assigned' に設定されますが、 'assigned' のチケットを再割り当て (reassign) するとステータスは 'new' に設定され、直観的ではありません。
    15 これは original ワークフローから "basic" ワークフローに移行することで解決します; original ワークフローから basic ワークフローへの移行には [http://trac.edgewall.org/browser/trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] が役に立つかもしれません。
     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}}}
     30
     31original ワークフローにはいくつかの重要な "欠点" があります。 新しいチケットを承認 (accept) したときにステータスは 'assigned' に設定されますが、 'assigned' のチケットを再割り当て (reassign) するとステータスは 'new' に設定され、直観的ではありません。
     32これは original ワークフローから "basic" ワークフローに移行することで解決します。 original ワークフローから basic ワークフローへの移行には [http://trac.edgewall.org/browser/trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] が役に立つかもしれません。
    1633
    1734=== 0.11 で新規作成した Environment === #Environmentscreatedwith0.11
    … …  
    2037basic ワークフローは下図を参照してください:
    2138
    22 [[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}}}
    2356
    2457== そのほかのワークフロー == #AdditionalTicketWorkflows
    2558
    26 Trac のソースにはいくつかのワークフローの例が含まれています; [http://trac.edgewall.org/browser/trunk/contrib/workflow contrib/workflow] の `*.ini` ファイル内のコンフィグセクションを参照してください。それらの一つはあなたが求めているものとマッチするかもしれません。 `*.ini` ファイル内のコンフィグセクションは、 `trac.ini` の `[ticket-workflow]` セクションに貼り付けて使用することができます。しかしながら、既に存在するチケットで、新しいワークフローに存在しないステータスのものがある場合は問題を来すかもしれません。
    27 
    28 これらの例の [http://trac.edgewall.org/wiki/WorkFlow/Examples ダイヤグラム] を見ることができます。
     59Trac のソースツリーの中でいくつかのワークフローのサンプルを提供しています。 [trac:source:trunk/contrib/workflow contrib/workflow] の `.ini` コンフィグセクションを探してみてください。その中のひとつにあなたが探しているものがあるでしょう。それらをあなたの `trac.ini` ファイルの `[ticket-workflow]` セクションに貼り付けてください。しかし、もしあなたがすでに起票済みのチケットをもっていて、それらのチケットのステータスが新しいワークフローに含まれていない場合に、問題が生じるでしょう。
     60
     61これらの例の [trac:WorkFlow/Examples ダイヤグラム] を見ることができます。
    2962
    3063== 基本的なワークフローのカスタマイズ == #BasicTicketWorkflowCustomization
    … …  
    4578
    4679''actionname''`.operations` で使用できる値は以下の通りです:
    47  - del_owner -- チケットの所有者を削除します。
    48  - set_owner -- チケットの所有者を選択された所有者か入力された所有者に設定します。
    49    - ''actionname''`.set_owner` カンマ区切りのリストか1つの値を設定することができます。
    50  - set_owner_to_self -- チケットの所有者をログインユーザに設定します。
    51  - del_resolution -- チケットの解決方法を削除します。
    52  - set_resolution -- チケットの解決方法を選択された解決方法か入力された解決方法に設定します。
    53    - ''actionname''`.set_resolution` カンマ区切りのリストか1つの値を設定することができます。
    54 {{{
    55 例:
    56 
     80 - del_owner -- チケットの所有者を削除します
     81 - set_owner -- チケットの所有者を選択された所有者か入力された所有者に設定します
     82   - ''actionname''`.set_owner` カンマ区切りのリストか1つの値を設定することができます
     83 - set_owner_to_self -- チケットの所有者をログインユーザに設定します
     84 - del_resolution -- チケットの解決方法を削除します
     85 - set_resolution -- チケットの解決方法を選択された解決方法か入力された解決方法に設定します
     86   - ''actionname''`.set_resolution` カンマ区切りのリストか1つの値を設定することができます。 例:
     87     {{{
    5788resolve_new = new -> closed
    5889resolve_new.name = resolve
    … …  
    6091resolve_new.permissions = TICKET_MODIFY
    6192resolve_new.set_resolution = invalid,wontfix
    62 }}}
    63  - leave_status -- "変更しない 現在のステータス: <現在のステータス>" (英語版では "leave as <current status>") を表示してチケットへの変更を行いません。
     93     }}}
     94 - leave_status -- "変更しない 現在のステータス: <現在のステータス>" (英語版では "leave as <current status>") を表示してチケットへの変更を行いません
    6495'''Note:''' `set_owner` と `del_owner` などのように相反する操作を同時に指定した場合の動作は不定です。
    6596
    … …  
    93124実行結果は `trac.pdf` として出力されます。 (`trac.ini` 同じディレクトリに出力されます。)
    94125
    95 ワークフローパーザのオンライン版が http://foss.wush.net/cgi-bin/visual-workflow.pl で利用できます。
    96 
    97 ワークフローを変更した後に、 Apache (サーバ) を再起動する必要があります。サーバの再起動が行われるまでは変更が適用されず変更前のワークフローが実行されることになります。
     126http://foss.wush.net/cgi-bin/visual-workflow.pl でワークフローのパーサのオンラインでのコピーができます。
     127
     128ワークフローを変更したあと、変更を適用するために Apache を再起動する必要があります。これは大切なことです。なぜならあなたがスクリプトを起動したとき、それでも変更箇所は現れますが、すべての古いワークフローがサーバの再起動がされるまで残ってしまうからです。
    98129
    99130== 例: ワークフローにテストを追加する == #Example:AddingoptionalTestingwithWorkflow
    … …  
    115146}}}
    116147
     148=== `tracopt.ticket.commit_updater` と testing ワークフローの組み合わせる方法 === #Howtocombinethetracopt.ticket.commit_updaterwiththetestingworkflow
     149
     150[[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] は Trac 0.12 で [[TracRepositoryAdmin#trac-post-commit-hook|古い trac-post-commit-hook を置き換える]] オプションのコンポーネントです。
     151
     152デフォルトで、このコンポーネントはチェンジセットのログメッセージの中の ''close'' や ''fix'' などのキーワードに反応し、対応するワークフローのアクションを実行します。
     153
     154もし、上記で述べたような testing ステージがあるような複雑なワークフローを使用していて、キーワードに ''closes'' があった場合にステータスを ''closed'' にする代わりに、 ''testing'' に移したいならば、かなりコードを改変させる必要があるでしょう。
     155
     156`trac-post-commit-hook` については、 [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 レシピ]] を参照して下さい。このコンポーネントの修正方法がいくらかわかるでしょう。
     157
    117158== 例: レビュー状態を追加する == #Example:Addsimpleoptionalgenericreviewstate
    118159
    … …  
    154195leave.default = 1
    155196leave.operations = leave_status
    156 reassign = new,assigned,reopened -> new
     197reassign = new,assigned,accepted,reopened -> assigned
    157198reassign.operations = set_owner
    158199reassign.permissions = TICKET_MODIFY
    … …  
    202243(訳注: この項はワークフローシステムの実装に関するアイデア集です。現在実装されているものではないので、プラグインを作成するときなどに参考にしてください)
    203244
    204 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.
     245New 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.
    205246
    206247If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket.
    … …  
    212253''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.''
    213254
    214  * operations could be anything: sum up the time used for the activity, or just write some statistical fields like 
     255 * operations could be anything: sum up the time used for the activity, or just write some statistical fields like
    215256''A workflow plugin can add an arbitrary workflow operation, so this is already possible.''
    216257
    … …  
    221262
    222263 * Actions should be selectable based on the ticket type (different Workflows for different tickets)
    223 ''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.''
     264''Look into the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin]'s `triage` operation.''
     265
     266 * 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?
     267''Have a look at [http://trac-hacks.org/wiki/TicketCreationStatusPlugin TicketCreationStatusPlugin] and [http://trac-hacks.org/wiki/TicketConditionalCreationStatusPlugin TicketConditionalCreationStatusPlugin]''
     268
     269 * 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.
     270
     271 * I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state.