Context Navigation

Changes between Version 1 and Version 2 of TracWorkflow

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

Legend:

: Unmodified
: Added
: Removed
: Modified

TracWorkflow

-              v1
+              v2
 == デフォルトのワークフロー == #TheDefaultTicketWorkflow
 === 0.10 からアップグレードした Environment === #Environmentsupgradedfrom0.10
+`trac-admin <env> upgrade` を実行したとき、`trac.ini` に `[ticket-workflow]` セクションが追加され、 0.10 でのワークフロー (original ワークフロー) と同様のアクションをするようにデフォルトの設定値が設定されます。
+`trac-admin <env> upgrade` を実行したとき、`trac.ini` に `[ticket-workflow]` セクションが追加され、
+.10 でのワークフロー (original ワークフロー) と同様のアクションをするようにデフォルトの設定値が設定されます。
 original ワークフローは下図を参照してください:
+[[Image(htdocs:../common/guide/original-workflow.png)]]
+original ワークフローにはいくつかの重要な "欠点" があります; 新しいチケットを承認 (accept) したときにステータスは 'assigned' に設定されますが、 'assigned' のチケットを再割り当て (reassign) するとステータスは 'new' に設定され、直観的ではありません。
+これは original ワークフローから "basic" ワークフローに移行することで解決します; original ワークフローから basic ワークフローへの移行には [http://trac.edgewall.org/browser/trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] が役に立つかもしれません。
+{{{#!Workflow width=500 height=240
+leave = * -> *
+leave.operations = leave_status
+leave.default = 1
+accept = new -> assigned
+accept.permissions = TICKET_MODIFY
+accept.operations = set_owner_to_self
+resolve = new,assigned,reopened -> closed
+resolve.permissions = TICKET_MODIFY
+resolve.operations = set_resolution
+reassign = new,assigned,reopened -> new
+reassign.permissions = TICKET_MODIFY
+reassign.operations = set_owner
+reopen = closed -> reopened
+reopen.permissions = TICKET_CREATE
+reopen.operations = del_resolution
+}}}
+original ワークフローにはいくつかの重要な "欠点" があります。 新しいチケットを承認 (accept) したときにステータスは 'assigned' に設定されますが、 'assigned' のチケットを再割り当て (reassign) するとステータスは 'new' に設定され、直観的ではありません。
+これは original ワークフローから "basic" ワークフローに移行することで解決します。 original ワークフローから basic ワークフローへの移行には [http://trac.edgewall.org/browser/trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] が役に立つかもしれません。
 === 0.11 で新規作成した Environment === #Environmentscreatedwith0.11
 …
 basic ワークフローは下図を参照してください:
+[[Image(htdocs:../common/guide/basic-workflow.png)]]
+{{{#!Workflow width=700 height=300
+leave = * -> *
+leave.operations = leave_status
+leave.default = 1
+accept = new,assigned,accepted,reopened -> accepted
+accept.permissions = TICKET_MODIFY
+accept.operations = set_owner_to_self
+resolve = new,assigned,accepted,reopened -> closed
+resolve.permissions = TICKET_MODIFY
+resolve.operations = set_resolution
+reassign = new,assigned,accepted,reopened -> assigned
+reassign.permissions = TICKET_MODIFY
+reassign.operations = set_owner
+reopen = closed -> reopened
+reopen.permissions = TICKET_CREATE
+reopen.operations = del_resolution
+}}}
 == そのほかのワークフロー == #AdditionalTicketWorkflows
 Trac のソースにはいくつかのワークフローの例が含まれています; [http://trac.edgewall.org/browser/trunk/contrib/workflow contrib/workflow] の `*.ini` ファイル内のコンフィグセクションを参照してください。それらの一つはあなたが求めているものとマッチするかもしれません。 `*.ini` ファイル内のコンフィグセクションは、 `trac.ini` の `[ticket-workflow]` セクションに貼り付けて使用することができます。しかしながら、既に存在するチケットで、新しいワークフローに存在しないステータスのものがある場合は問題を来すかもしれません。
 これらの例の [http://trac.edgewall.org/wiki/WorkFlow/Examples ダイヤグラム] を見ることができます。
+Trac のソースツリーの中でいくつかのワークフローのサンプルを提供しています。 [trac:source:trunk/contrib/workflow contrib/workflow] の `.ini` コンフィグセクションを探してみてください。その中のひとつにあなたが探しているものがあるでしょう。それらをあなたの `trac.ini` ファイルの `[ticket-workflow]` セクションに貼り付けてください。しかし、もしあなたがすでに起票済みのチケットをもっていて、それらのチケットのステータスが新しいワークフローに含まれていない場合に、問題が生じるでしょう。
+これらの例の [trac:WorkFlow/Examples ダイヤグラム] を見ることができます。
 == 基本的なワークフローのカスタマイズ == #BasicTicketWorkflowCustomization
 …
 ''actionname''`.operations` で使用できる値は以下の通りです:
+ - del_owner -- チケットの所有者を削除します。
+ - set_owner -- チケットの所有者を選択された所有者か入力された所有者に設定します。
+   - ''actionname''`.set_owner` カンマ区切りのリストか1つの値を設定することができます。
+ - set_owner_to_self -- チケットの所有者をログインユーザに設定します。
+ - del_resolution -- チケットの解決方法を削除します。
+ - set_resolution -- チケットの解決方法を選択された解決方法か入力された解決方法に設定します。
+   - ''actionname''`.set_resolution` カンマ区切りのリストか1つの値を設定することができます。
+{{{
+例:
+ - del_owner -- チケットの所有者を削除します
+ - set_owner -- チケットの所有者を選択された所有者か入力された所有者に設定します
+   - ''actionname''`.set_owner` カンマ区切りのリストか1つの値を設定することができます
+ - set_owner_to_self -- チケットの所有者をログインユーザに設定します
+ - del_resolution -- チケットの解決方法を削除します
+ - set_resolution -- チケットの解決方法を選択された解決方法か入力された解決方法に設定します
+   - ''actionname''`.set_resolution` カンマ区切りのリストか1つの値を設定することができます。 例:
+     {{{
 resolve_new = new -> closed
 resolve_new.name = resolve
 …
 resolve_new.permissions = TICKET_MODIFY
 resolve_new.set_resolution = invalid,wontfix
 }}}
  - leave_status -- "変更しない 現在のステータス: <現在のステータス>" (英語版では "leave as <current status>") を表示してチケットへの変更を行いません。
+     }}}
+ - leave_status -- "変更しない 現在のステータス: <現在のステータス>" (英語版では "leave as <current status>") を表示してチケットへの変更を行いません
 '''Note:''' `set_owner` と `del_owner` などのように相反する操作を同時に指定した場合の動作は不定です。
 …
 実行結果は `trac.pdf` として出力されます。 (`trac.ini` 同じディレクトリに出力されます。)
 ワークフローパーザのオンライン版が http://foss.wush.net/cgi-bin/visual-workflow.pl で利用できます。
 ワークフローを変更した後に、 Apache (サーバ) を再起動する必要があります。サーバの再起動が行われるまでは変更が適用されず変更前のワークフローが実行されることになります。
+http://foss.wush.net/cgi-bin/visual-workflow.pl でワークフローのパーサのオンラインでのコピーができます。
+ワークフローを変更したあと、変更を適用するために Apache を再起動する必要があります。これは大切なことです。なぜならあなたがスクリプトを起動したとき、それでも変更箇所は現れますが、すべての古いワークフローがサーバの再起動がされるまで残ってしまうからです。
 == 例: ワークフローにテストを追加する == #Example:AddingoptionalTestingwithWorkflow
 …
 }}}
+=== `tracopt.ticket.commit_updater` と testing ワークフローの組み合わせる方法 === #Howtocombinethetracopt.ticket.commit_updaterwiththetestingworkflow
+[[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] は Trac 0.12 で [[TracRepositoryAdmin#trac-post-commit-hook|古い trac-post-commit-hook を置き換える]] オプションのコンポーネントです。
+デフォルトで、このコンポーネントはチェンジセットのログメッセージの中の ''close'' や ''fix'' などのキーワードに反応し、対応するワークフローのアクションを実行します。
+もし、上記で述べたような testing ステージがあるような複雑なワークフローを使用していて、キーワードに ''closes'' があった場合にステータスを ''closed'' にする代わりに、 ''testing'' に移したいならば、かなりコードを改変させる必要があるでしょう。
+`trac-post-commit-hook` については、 [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 レシピ]] を参照して下さい。このコンポーネントの修正方法がいくらかわかるでしょう。
 == 例: レビュー状態を追加する == #Example:Addsimpleoptionalgenericreviewstate
 …
 leave.default = 1
 leave.operations = leave_status
 reassign = new,assigned,reopened -> new
+reassign = new,assigned,accepted,reopened -> assigned
 reassign.operations = set_owner
 reassign.permissions = TICKET_MODIFY
 …
 (訳注: この項はワークフローシステムの実装に関するアイデア集です。現在実装されているものではないので、プラグインを作成するときなどに参考にしてください)
 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.
+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 [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations.
 If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket.
 …
 ''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.''
  * operations could be anything: sum up the time used for the activity, or just write some statistical fields like
+ * operations could be anything: sum up the time used for the activity, or just write some statistical fields like
 ''A workflow plugin can add an arbitrary workflow operation, so this is already possible.''
 …
  * Actions should be selectable based on the ticket type (different Workflows for different tickets)
+''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.''
+''Look into the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin]'s `triage` operation.''
+ * 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?
+''Have a look at [http://trac-hacks.org/wiki/TicketCreationStatusPlugin TicketCreationStatusPlugin] and [http://trac-hacks.org/wiki/TicketConditionalCreationStatusPlugin TicketConditionalCreationStatusPlugin]''
+ * 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.
+ * I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state.