TracWorkflow のバージョン 1 とバージョン 2 との変更


以下の違いを無視:
日時:
2012/01/16 5:19:14 (13年前)
更新者:
trac
コメント:

--

凡例:

未変更
追加
削除
更新

  • TracWorkflow

    v1 v2  
    1313 
    1414original ワークフローにはいくつかの重要な "欠点" があります; 新しいチケットを承認 (accept) したときにステータスは 'assigned' に設定されますが、 'assigned' のチケットを再割り当て (reassign) するとステータスは 'new' に設定され、直観的ではありません。 
    15 これは original ワークフローから "basic" ワークフローに移行することで解決します; original ワークフローから basic ワークフローへの移行には `contrib/workflow/migrate_original_to_basic.py` が役に立つかもしれません。 
     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] が役に立つかもしれません。 
    1616 
    1717=== 0.11 で新規作成した Environment === #Environmentscreatedwith0.11 
    … …  
    2424== そのほかのワークフロー == #AdditionalTicketWorkflows 
    2525 
    26 Trac のソースにはいくつかのワークフローの例が含まれています; `contrib/workflow` の `*.ini` ファイル内のコンフィグセクションを参照してください。それらの一つはあなたが求めているものとマッチするかもしれません。 `contrib/workflow` の `*.ini` ファイル内のコンフィグセクションは、 `trac.ini` の `[ticket-workflow]` セクションに貼り付けて使用することができます。 
     26Trac のソースツリーの中でいくつかのワークフローのサンプルを提供しています; [trac:source:trunk/contrib/workflow contrib/workflow] の `.ini` コンフィグセクションを探してみてください。その中のひとつにあなたが探しているものがあるでしょう。それらをあなたの `trac.ini` ファイルの `[ticket-workflow]` セクションに貼り付けてください。しかし、もしあなたがすでに起票済みのチケットをもっていて、それらのチケットのステータスが新しいワークフローに含まれていない場合に、問題が生じるでしょう。 
     27 
     28これらの例の [http://trac.edgewall.org/wiki/WorkFlow/Examples ダイヤグラム] を見ることができます。 
    2729 
    2830== 基本的なワークフローのカスタマイズ == #BasicTicketWorkflowCustomization 
     31 
     32Note: チケットの "ステータス群 (Statuses or states)" は独立した状態で定義することはできません。チケットがとりうるステータスはワークフローで定義された状態遷移から自動生成されます。つまり、チケットを新規作成するためには、ワークフローで開始状態と終了状態を持つ状態遷移を定義せねばなりません。 
    2933 
    3034`trac.ini` に `[ticket-workflow]` セクションを作成します。 
    … …  
    8993実行結果は `trac.pdf` として出力されます。 (`trac.ini` 同じディレクトリに出力されます。) 
    9094 
    91 ワークフローを変更した後に、 Apache (サーバ) を再起動する必要があります。サーバの再起動が行われるまでは変更が適用されず変更前のワークフローが実行されることになります。 
     95http://foss.wush.net/cgi-bin/visual-workflow.pl でワークフローのパーサのオンラインでのコピーができます。 
     96 
     97ワークフローを変更したあと、変更を適用するために Apache を再起動する必要があります。これは大切なことです。なぜならあなたがスクリプトを起動したとき、それでも変更箇所は現れますが、すべての古いワークフローがサーバの再起動がされるまで残ってしまうからです。 
    9298 
    9399== 例: ワークフローにテストを追加する == #Example:AddingoptionalTestingwithWorkflow 
    … …  
    96102 
    97103{{{ 
    98 testing = new,accepted,needs_work -> testing 
     104testing = new,accepted,needs_work,assigned,reopened -> testing 
    99105testing.name = Submit to reporter for testing 
    100106testing.permissions = TICKET_MODIFY 
    … …  
    107113pass.operations = set_resolution 
    108114pass.set_resolution = fixed 
     115}}} 
     116 
     117=== `tracopt.ticket.commit_updater` と testing ワークフローの組み合わせる方法 === #Howtocombinethetracopt.ticket.commit_updaterwiththetestingworkflow 
     118 
     119[[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] は Trac 0.12 で [[TracRepositoryAdmin#trac-post-commit-hook|古い trac-post-commit-hook を置き換える]] オプションのコンポーネントです。 
     120 
     121デフォルトで、このコンポーネントはチェンジセットのログメッセージの中の ''close'' や ''fix'' などのキーワードに反応し、対応するワークフローのアクションを実行します。 
     122 
     123もし、上記で述べたような testing ステージがあるような複雑なワークフローを使用していて、キーワードに ''closes'' があった場合にステータスを ''closed'' にする代わりに、 ''testing'' に移したいならば、かなりコードを改変させる必要があるでしょう。 
     124 
     125`trac-post-commit-hook` については、 [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 レシピ]] を参照して下さい。これは、このコンポーネントを修正する方法についていくつかのアイディアをくれるでしょう。 
     126 
     127== 例: レビュー状態を追加する == #Example:Addsimpleoptionalgenericreviewstate 
     128 
     129"testing" ステータスが利用者によっては、異なる状況を指すような Trac の使い方をしている場合、実装固有の詳細な箇所は "testing" に分類せず、デフォルトのワークフローの `assigned` と `closed` ステータスの間に、必要に応じて分岐できるステータスを追加したいと考えるはずです。新しいステータスは `reviewing` とすべきでしょう。 "submitted for review" されたチケットは、どのようなステータスからでも reassigned になります。レビューが通過した場合、 `resolve` アクションを再利用して、チケットを close します。通過しない場合は `reassign` アクションを再利用して通常のワークフローに戻します。 
     130 
     131新しい `reviewing` ステータスは `review` アクションに関連付けます。以下のように記述してください: 
     132 
     133{{{ 
     134review = new,assigned,reopened -> reviewing 
     135review.operations = set_owner 
     136review.permissions = TICKET_MODIFY 
     137}}} 
     138 
     139デフォルトの Trac 0.11 ワークフローに統合するために、 `reviewing` ステータスを `accept` と `resolve` アクションに追加します。以下のようになります: 
     140 
     141{{{ 
     142accept = new,reviewing -> assigned 
     143[…] 
     144resolve = new,assigned,reopened,reviewing -> closed 
     145}}} 
     146 
     147必要に応じて `reviewing` からステータスを変更せずに、チケットの担当者 (owner) を変更するための新しいアクションを追加します。この設定を行うと、 `new` ステータスに遷移させることなくレビューの担当者を変更することができるようになります。 
     148 
     149{{{ 
     150reassign_reviewing = reviewing -> * 
     151reassign_reviewing.name = reassign review 
     152reassign_reviewing.operations = set_owner 
     153reassign_reviewing.permissions = TICKET_MODIFY 
     154}}} 
     155 
     156完全な `[ticket-workflow]` への設定は以下のようになります: 
     157 
     158{{{ 
     159[ticket-workflow] 
     160accept = new,reviewing -> assigned 
     161accept.operations = set_owner_to_self 
     162accept.permissions = TICKET_MODIFY 
     163leave = * -> * 
     164leave.default = 1 
     165leave.operations = leave_status 
     166reassign = new,assigned,reopened -> new 
     167reassign.operations = set_owner 
     168reassign.permissions = TICKET_MODIFY 
     169reopen = closed -> reopened 
     170reopen.operations = del_resolution 
     171reopen.permissions = TICKET_CREATE 
     172resolve = new,assigned,reopened,reviewing -> closed 
     173resolve.operations = set_resolution 
     174resolve.permissions = TICKET_MODIFY 
     175review = new,assigned,reopened -> reviewing 
     176review.operations = set_owner 
     177review.permissions = TICKET_MODIFY 
     178reassign_reviewing = reviewing -> * 
     179reassign_reviewing.operations = set_owner 
     180reassign_reviewing.name = reassign review 
     181reassign_reviewing.permissions = TICKET_MODIFY 
    109182}}} 
    110183 
    … …  
    131204プラグインを使用した拡張でさえも十分でないならば !ConfigurableTicketWorkflow のコンポーネントを無効にし、!ConfigurableTicketWorkflow  を完全に置き換える十分な機能を持ったプラグインを作成することも可能です。 
    132205 
     206== ワークフローのステータスをマイルストーンのプログレスバーに追加する == #AddingWorkflowStatestoMilestoneProgressBars 
     207 
     208新しいステータスをワークフローに追加した場合、マイルストーンのプログレスバーへの表示もカスタマイズできます。 [TracIni#milestone-groups-section TracIni] を参照してください。 
     209 
    133210== 次のステップに向けたアイデア集 == #someideasfornextsteps 
    134211 
    135212(訳注: この項はワークフローシステムの実装に関するアイデア集です。現在実装されているものではないので、プラグインを作成するときなどに参考にしてください) 
    136213 
    137 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. 
     214New 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. 
    138215 
    139216If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket. 
    … …  
    143220   * '''postops''': automatic, when leaving the state/activity 
    144221   * '''actions''': can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows. 
    145 This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement. 
     222''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.'' 
    146223 
    147224 * operations could be anything: sum up the time used for the activity, or just write some statistical fields like  
    148 A workflow plugin can add an arbitrary workflow operation, so this is already possible. 
     225''A workflow plugin can add an arbitrary workflow operation, so this is already possible.'' 
    149226 
    150227 * set_actor should be an operation allowing to set the owner, e.g. as a "preop": 
    151228   * either to a role, a person 
    152229   * entered fix at define time, or at run time, e.g. out of a field, or select. 
    153 This is either duplicating the existing `set_owner` operation, or needs to be clarified. 
     230''This is either duplicating the existing `set_owner` operation, or needs to be clarified.'' 
    154231 
    155232 * Actions should be selectable based on the ticket type (different Workflows for different tickets) 
    156 This is becoming a frequent request, with clear usecases.  The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point. 
     233''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.'' 
     234