工程管理

導入
サンプル・プロセス
要求の記録
マネージャーによる承認
購買部による処理
郵便室による処理
例の実行
プロセス(コンテナーとしての)
アクティビティ・ダイアログ
推移
推移アクション
アクティビティ
本の注文プロセスのパス
プロセス構成リファレンス
プロセス
プロセス構成
Name
CreateTime
CreateBy
ChangeTime
ChangeBy
State
StartActivity
StartActivityDialog
パス
アクティビティ
アクティビティ構成
Name
CreateTime
CreateBy
ChangeTime
ChangeBy
ActivityDialog(アクティビティ・ダイアログ)
ActivityDialog(アクティビティ・ダイアログ)
ActivityDialog(アクティビティ・ダイアログ)の構成
Name
CreateTime
CreateBy
ChangeTime
ChangeBy
フィールド
FieldOrder(フィールド順序)
SubmitAdviceText(アドバイス用テキストの送信)
SubmitButtonText(送信ボタンのテキスト)
Transition(推移)
Transition configuration(推移構成)
Name
CreateTime
CreateBy
ChangeTime
ChangeBy
Condition(条件)
推移アクション
推移アクション構成
Name
Module(モジュール)
Config(構成)
推移アクション・モジュールの再使用
利用可能な推移アクション
アクセス・コントロール・リスト(ACL)
ACL構成
001-ACL-ProcessProperties
プロセス
「可能」(Possible)/ 「不可能」(PossibleNot) アクティビティ・ダイアログ

導入

OTRSのこの機能により、チケット・システムでプロセス(ワークフロー)をモデル化することが可能です。この基本概念は再現するプロセスを定義可能にし、異なる人々に作業項目を任せるためのものです。またある基準に基づく異なる指示のプロセス進行をリードします。

サンプル・プロセス

より実地的なサンプルで見てみましょう。ここでは本の注文プロセスを定義します:

要求の記録

受注前に、従業員によって書物の需要が記録されます。以下の本がここでの例に必要となります:

タイトル:Prozessmanagement für Dummies、著者:Thilo Knuppertz、ISBN:3527703713

マネージャーによる承認

従業員の部長は注文に関して以下を決定する必要があります。否認の場合には、理由がマネージャーによって記録されるべきです。承認の場合には、オーダーが購買部に渡されます。

購買部による処理

購入するとは、本を最良の条件で本を注文する場所を見つける職務です。品切れの場合、注文に記録します。購入が成約した場合はサプライヤー、購入価格、配達日を記録します。

郵便室による処理

貨物が会社に入荷すると、貨物の入荷受付部は、その貨物をチェックし受領日を記録します。従業員はこの注文が到着を知らされ、貨物を取りに行く準備をするでしょう。

例の実行

チケットが、このワークフロー中で、 変更ノートを受け取ることができる添付書類のように作用すると考えれば、既にプロセス・チケットの明瞭な青写真を持っていることになります。

サンプル・プロセスの分析から、次の必須アイテムを識別することができます。

  • データを記録する可能性、それをアクティビティ・ダイアログと呼びます。

  • データ変更されたことに対して自動的に反応するチェック機構、それを推移(Transitions)と呼びます。

  • プロセス・チケットの推移が成功した後でプロセス・チケットに適用可能な変更、それを推移アクション(Transition Actions)と呼びます。

さらにそれほど明白でないかもしれない追加項目を必要とします:

  • 利用可能なアクティビティ・ダイアログをひとつ以上提供する可能性。ここでの例においては、マネージャーが「承認」「拒絶」の選択を持っていなければならない場合にこれ(提供する可能性)が必要です。これをアクティビティと呼びます。

さて、アクティビティ、アクティビティ・ダイアログ、推移と推移アクションにより、私たちは、私たちの例の個々のステップを形成するための必要なツールを持つことになります。私たちは、各々のワークフォローにとってステップの順番が指定されうるエリアをまだ見つけていません。これをプロセスと呼びましょう。これらのすべての実体(エンティティ)を後で参照することができるようにするために、それらを括弧中の略語で指定します。この省略は EntityIDs と呼ばれる内部識別メカニズムに基づきます。

エンティティIDs(EntityIDs)は、1個あるいは2個の文字(プロセス部分あるいは実体に依存します)と連続した番号で組み合わせて作られます。

  • プロセス(Process): 'P1', 'P2' ... 'Pn'.

  • アクティビティ(Activity): 'A1', 'A2' ... 'An'.

  • アクティビティ・ダイアログ(Activity Dialog): 'AD1', 'AD2' ... 'ADn'.

  • 推移(Transition): 'T1', 'T2' ... 'Tn'.

  • 推移アクション(Transition Action): 'TA1', 'TA2' ... 'TAn'.

プロセスとその部分の生成がシステムを準備するために必要とする前に、いくつかのSysConfigオプションのセット、キュー、ユーザー、動的フィールドを定義する必要があります。

次のキューを作成します:

  • 管理: Management

  • 顧客: Employees

  • 購買:Purchasing

  • 郵便局: Post office

次のユーザーを作成します。

  • 管理者:Manager

  • 顧客:Employee

次の動的フィールドを作成します。

  • タイトル

    ラベルタイトル
    タイプテキスト
    オブジェクトチケット
  • 著者

    ラベル著者
    タイプテキスト
    オブジェクトチケット
  • ISBN

    ラベルISBN
    タイプテキスト
    オブジェクトチケット
  • 状態

    ラベル状態
    タイプドロップダウン
    オブジェクトチケット
    可能な値
    • 承認

    • 承認拒否

    • 承認済

    • 注文拒否

    • 発注済

    • 貨物受取済

    ノート: フィールド設定の「キー」と「値」は的確に使用して下さい。

  • サプライヤー

    ラベルサプライヤー
    タイプテキスト
    オブジェクトチケット
  • 価格

    ラベル価格
    タイプテキスト
    オブジェクトチケット
  • 配達日(DeliveryDate)

    ラベル配達日
    タイプ日付
    オブジェクトチケット
  • 受領日(DateOfReceipt)

    ラベル受領日
    タイプ日付
    オブジェクトチケット

次のSysConfigの設定をセットします:

  • 'Ticket::Responsible': はい

  • 'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups':

    キー:コンテンツ:
    タイトル、著者、ISBN
    一般状態
    注文価格、サプライヤー、配達日
    配送受領日(DateOfReceipt)
  • 'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField':

    キー:コンテンツ:
    著者1
    受領日(DateOfReceipt)1
    配達日(DeliveryDate)1
    ISBN1
    価格1
    状態1
    サプライヤー1
    タイトル1

それでは、実際のプロセス管理職員で開始しましょう。次のステップで、必要とする個々の実体を定義します。

プロセス(コンテナーとしての)

管理者パネル中のシステム管理ボックスの中の「プロセス・マネジメント」リンクをクリックする際には、新しいプロセスを作成することが必要です。これはプロセス・マネジメント概要への通じます。プロセスの生成の後、他のすべての実体(あるいはプロセス部分)を作成することができます。

注記

1つのプロセスの中で定義されたアクティビティ、アクティビティ・ダイアログ、推移および推移アクションは、システムでのすべてのプロセスに利用可能になります。

図:OTRS管理者画面 - システム管理

アクション・ボックスから「新しいプロセスを作成する」アクションをクリックしてください。

図:新しいプロセスの追加

プロセス情報を記入し、プロセス名と摘要を設定し、全てのタスクが終了するまでプロセスの状態を「不活性」のままにしておきます。プロセスを保存します。

図:新しいプロセスの追加

アクティビティ・ダイアログ

プロセス・マネジメント概要画面にあるの新しいプロセス名をクリックします。それから「利用可能なプロセス構成要素」の中で「アクティビティ・ダイアログ」をクリックします。(このアクションはアクティビティ・ダイアログ・オプションを拡張し、他の全てを壊し押しつぶすでしょう。)次に「新しいアクティビティ・ダイアログを作成」をクリックします。

図:新しいアクティビティ・ダイアログ・ボタンの作成

「摘要(短)」フィールドと同様に、開いたポップ・アップ・画面に「アクティビティ・ダイアログ名」を 記入します。この例では全ての他のフィールドをデフォルトのままにしておきます。アクティビティ・ダイアログにフィールドを指定するために、必要なフィールドを「利用可能なフィールド」プールから「指定されたフィールド」へドラッグします。「指定されたフィールド」プールの順序は フィールドが画面にあるような順序です。プール内のフィールドをドラッグ&ドロップして順序を変更し、正しい位置に再配置します。

図:新規アクティビティ・ダイアログの追加

フィールドが「指定されたフィールド」プールにドロップされるとすぐに、別のポップ・アップ・画面が開き、フィールドに関するいくつかの詳細が表示されます。デフォルト・オプションはそのままとして、また記事フィールドのみに関しては、記事タイプ・フィールドが「ノート内部:(note-internal)」にセットされることを確かめねばなりません。

図:フィールド詳細(記事)の編集

全てのフィールドが指定された後で、変更を保存するためにメインのポップアップ画面にて、送信ボタンをクリックします。

この例では、私たちは記事フィールドをコメントに使用します。しかし、別のオプションはTextAreaタイプ動的フィールドを作成できます。下記のラインの言及されたフィールドの残りは、私たちが事前に定義する動的フィールドです。

この画面では動的フィールドは、「DynamicField_Title」の中に接頭辞「DynamicField_」を持つことにご留意願います。タイトルフィールドとチケット・タイトルとを混同しないようにして下さい。

次のアクティビティ・ダイアログを作成してください:

  • 「依頼の記録」(AD1)

    注文のために収集されるデータ用の全ての必須フィールドを含むアクティビティ・ダイアログ(タイトル、著者、ISBN)と、「承認」を選択する可能性を持つ状態フィールド。

  • 「承認拒否」(AD2)

    コメント・フィールド(記事)を持つアクティビティー・フィールドとオプション「承認拒否」を備えた状態フィールド

  • 「承認済」(AD3)

    ここでは「承認済」オプションを持つ状態フィールドが必要となります。

  • 「注文拒否」 (AD4)

    購入時不可能な注文(在庫切れの本)を拒否することを可能可能にするアクティビティ・ダイアログ。ここでは「注文拒否」オプションを持つ状態フィールドが必要となります。

  • 「発注」(AD5)

    購入時のフィールド・サプライヤー、価格、配達日、及び「注文拒否」オプションを持つ状態フィールドを、持つアクティビティ・ダイアログ。

  • 「貨物受取」(AD6)

    「受取日のフィールドを備えた郵便室」および「貨物受取」オプションを備えた状態・フィールド用のアクティビティ。

各々のアクティビティ・ダイアログ用の状態フィールドを制限するために、いくつかのACLの追加を必要とします。ACLを追加する場所はKernel/Config.pmの中またはKernel/Config/Filesの中にある新しいperlファイルです。

    $Self->{TicketAcl}->{'P1-AD1-1'} = {
        Properties => {
            Process => {
                ActivityDialogEntityID => ['AD1'],
            },
        },
        Possible => {
            Ticket => {
                DynamicField_Status => ['Approval'],
            },
        },
    };

    $Self->{TicketAcl}->{'P1-AD2-1'} = {
        Properties => {
            Process => {
                ActivityDialogEntityID => ['AD2'],
            },
        },
        Possible => {
            Ticket => {
                DynamicField_Status => ['Approval denied'],
            },
        },
    };

    $Self->{TicketAcl}->{'P1-AD3-1'} = {
        Properties => {
            Process => {
                ActivityDialogEntityID => ['AD3'],
            },
        },
        Possible => {
            Ticket => {
                DynamicField_Status => ['Approved'],
            },
        },
    };

    $Self->{TicketAcl}->{'P1-AD4-1'} = {
        Properties => {
            Process => {
                ActivityDialogEntityID => ['AD4'],
            },
        },
        Possible => {
            Ticket => {
                DynamicField_Status => ['Order denied'],
            },
        },
    };

    $Self->{TicketAcl}->{'P1-AD5-1'} = {
        Properties => {
            Process => {
                ActivityDialogEntityID => ['AD5'],
            },
        },
        Possible => {
            Ticket => {
                DynamicField_Status => ['Order placed'],
            },
        },
    };

    $Self->{TicketAcl}->{'P1-AD6-1'} = {
        Properties => {
            Process => {
                ActivityDialogEntityID => ['AD6'],
            },
        },
        Possible => {
            Ticket => {
                DynamicField_Status => ['Shipment received'],
            },
        },
    };
                    

推移

「推移」で「利用可能なプロセス要素」をクリックして、その後、「新しい推移の作成」をクリックしてください。

図:新規推移ボタンの作成

開いたポップ・アップ・画面中に「推移名」を記入します。それからこの条件では、この例に対してひとつの条件とひとつのフィールドを使います。その両方に対してリンクのタイプを「and」のままにします。そしてフィールド一致タイプ値として「String」を使います。

図: 新規推移の追加

全ての条件を設定後、変更を保存するために送信ボタンをクリックします。

次の推移を作成してください:

  • 「承認」(T1)

    状態フィールドが「承認」にセットされるかどうかをチェックする推移。

  • 「承認拒否」(T2)

    状態フィールドが「「承認拒否」にセットされるかどうかをチェックする推移。

  • 「承認済」(T3)

    状態フィールドが着手されるかどうかをチェックする推移は「承認済」

  • 「注文拒否」 (T4)

    状態フィールドが「注文拒否」にセットされるかどうかをチェックする推移。

  • 「発注」 (T5)

    状態フィールドが「発注」にセットされるかどうかをチェックする推移。

  • 「貨物受取」 (T6)

    状態フィールドが「貨物受取」にセットされるかどうかをチェックする推移。

推移アクション

「利用可能なプロセス要素」中の「推移アクション」をクリックして、次に、「新規推移アクションの作成」をクリックしてください。

図:新規推移アクションボタンの作成

開かれたポップ・アップ・画面の中で「推移名」および「推移アクション・モジュール」を記入して下さい。それから、必須及び任意のパラメタと値を追加して下さい。

全ての推移アクション・モジュールは、Kernel/System/ProcessManagement/TransitionActionに存在します。また、推移アクションと以下は下記は、バンドルされた推移アクションのリストで、このリリースに含まれます。

  • DynamicFieldSet (動的フィールドのセット)

  • TicketArticleCreate(チケット記事の作成)

  • チケット作成

  • TicketCustomerSet(チケット・顧客・セット)

  • TicketLockSet(チケット・ロック・セット)

  • TicketOwnerSet(チケット・所有者・セット)

  • TicketQueueSet(チケット・キュー・セット)

  • TicketResponsibleSet(チケット・責任者・セット)

  • TicketServiceSet(チケット・サービス・セット)

  • TicketSLASet(チケット・SLA・セット)

  • TicketStateSet(チケット・状態・セット)

  • TicketTitleSet(チケット・タイトル・セット)

  • TicketTypeSet(チケット・タイプ・セット)

モジュールはそれぞれそれ自身のものおよび異なるパラメーターを持っています。全ての必須及び任意のパラメタを知るためにモジュール・ドキュメンテーションをレビューして下さい。 

注記

From OTRS 4.0.1, parameters are not longer mandatory fixed values, but instead, they can inherit from the original ticket using format: <OTRS_Ticket_property>.

From OTRS 4.0.6, the format <OTRS_TICKET_property> is now supported, older format is still usable, but deprecated as it will be dropped in further versions.

新規推移アクションの追加

全ての条件を設定後、変更を保存するために送信ボタンをクリックします。

次の推移アクションを作成してください:

  • 「「管理」キューへプロセス・チケットを移動」(TA1)

    このアクションは推移「承認」(T1)が適用される時、実行されると思われます。

  • 「チケットの責任者を「マネージャ」に変更」」 (TA2)

    推移「承認」(T1)の適用時、実行されるべきです。

  • 「「従業員」キューへのプロセス・チケットの移動」(TA3)

    以下の場合実行されるべきです:

    • 推移: 「否認」(T2)が適用された

    • 推移: 「注文拒否」(T4)が適用された

    • 推移:「出荷受取」(T6)が適用された

  • 「チケットの責任者を「従業員」へ変更」(TA4)

    以下の場合実行されるべきです:

    • 推移:「承認拒否」(T2)が適用された

    • 推移:「注文拒否」(T4) が適用された

    • 推移:「貨物受取」(T6) が」適用された

  • 「プロセス・チケットを「購入」キュー」(TA5)へ移動する

    推移「承認済」(T3)が適用された場合に実行されるべきです。

  • 「プロセス・チケットを「郵便局」キューへ移動」(TA6)

    推移「発注」(T5)が適用されたら実行されるべきです。

  • 「チケットが正しく完了しました(TA7)」

    以下の場合実行されるべきです:

    • 推移:「貨物受取」(T6) が」適用された

  • 「チケットが正しく完了しませんでした」(TA8)

    以下の場合実行されるべきです:

    • 推移:「承認拒否」(T2)が適用された

    • 推移:「注文拒否」(T4) が適用された

ご覧のように、同じ推移アクションが実行されるべき場所があります。したがって、それらを再使用することができるように推移アクションと推移とを自由にリンクすることを可能にすることは合理的なやり方です。

アクティビティ

アクティビティをひとつのバスケットとみなすアプローチを選択します。それは単数または複数のアクティビティ・ダイアログを含むことができます。

「利用可能なプロセス要素」中の「アクティビティ」をクリックして、次に、「新規アクティビティの作成」をクリックしてください。

図:新規アクティビティボタンの作成

開かれたポップ・アップ・画面中で「アクティビティ名」を記入して下さい。次に、必要なアクティビティ・ダイアログを”利用可能なアクティビティ・ダイアログ”プールからドラッグして、「割り当てされたアクティビティ・ダイアログ」プールへドロップします。このダイアログはチケット・ズーム画面で同じ順序で表示されるでしょう。その順序とは最上部から最下部、左から右へ推移するこの画面で定義されたものです。 

この順序は特に最初のアクティビティで重要です。というのは、このアクティビティのための最初のアクティビティ・ダイアログはそれがプロセスが開始する時に表示されるただひとつのものだからです。

次のアクティビティを作成しましょう。

  • 「依頼(要求)の記録」(A1)

    アクティビティ・ダイアログ「依頼(要求)の記録」を含みます(AD1)

  • 「承認」(A2)

    アクティビティ・ダイアログ「承認」(AD3)と同様に「承認拒否」(AD2)を含みます。

  • 「注文」(A3)

    アクティビティ・ダイアログ「発注」(AD5)と同様に「注文拒否」(AD4)を含みます。(AD5)

  • 「入荷」(A4)

    アクティビティ・ダイアログ「貨物受取」(AD6)を含みます。

  • 「プロセス完了」(A5):これは可能なアクティビティ・ダイアログのないアクティビティです。「承認拒否」、「注文拒否」または「貨物受取」の後にセットされ、プロセスの終了を表します。

アクティビティが、プロセス・チケットの正確に定義された状態であることを明確に理解しました。成功した推移の後、プロセス・チケットはあるアクティビティから別のアクティビティへ遷移します。

本の注文プロセスのパス

フローの記述者としてのプロセス、パズルの最後の欠けた1ピースで私たちの例を終えることにしましょう。私たちのケースでは、これは全注文ワークフローです。他のプロセスは事務用品注文あるいは完全に異なるプロセスでありえます。

プロセスには、スタート・アクティビティおよびスタート・アクティビティ・ダイアログをから成る、出発点があります。任意の新しい本オーダーについては、スタート・アクティビティ・ダイアログ(最初のアクティビティのための第1のアクティビティ・ダイアログ)は、表示される最初の画面です。これが完成し保存されれば、プロセス・チケットは作成され、形成されたワークフローに続くことができます。

プロセスには、プロセス・チケットどのようにしてがプロセスを通過できるのかについての指示も含まれています。これを「パス」と呼びましょう。それは、スタート・アクティビティ、1つ以上の推移(恐らく推移アクションを持った)および他の活動から成ります。

アクティビティがすでにアクティビティ・ダイアログを割り当てしたと仮定すると、アクティビティをアコーデオン(画面左部)からドラッグします。そしてそれをキャンバスエリア(以下のプロセス情報)にドロップします。プロセス・スタート(緑の円)からアクティビティまでの矢印が自動的に置かれることに注目してください。(これは最初のアクティビティです。また、その最初のアクティビティ・ダイアログは プロセスが開始するときに表示される最初の画面です)。

図:キャンバスに第1のアクティビティをドラッグしてください

次に、キャンバスに別のアクティビティをドラッグしてください。キャンバスに2つのアクティビティを持つことになります。ひとつはスタート点に接続され、もう一方は接続点を持ちません。それぞれのアクティビティ上でマウスポインタを持っていくと、それらアクティビティ・ダイアログを確認することができます。

図:第二のアクティビティをキャンバスにドラッグします

それからこの2つのアクティビティ間の「パス」を作成しましょう、そのために推移を使います。アコーディオン状の推移をクリックし、推移をドラッグしそれを最初のアクティビティの内部にドロップします。アクティビティはその色が 推移が添付されたことを示して、変化することに気づいて下さい。推移が推移の端の矢印にドロップされるとすぐに、スタート開始点の隣に置かれるでしょう。 アクティビティ間の接点を作成するために、推移の矢印の終了点をドラッグしてそれを他のアクティビティの内部にドロップします。

図:キャンバスに推移をドラッグします。

アクション間の「パス」が今定義されたので、次に推移に推移アクションを割り当てする必要があります。推移ラベル(キャンバス中の)をダブルクリックし、新しいポップアップ・ウィンドウを開きます。

図:推移を使用して、アクティビティを接続します

必要な推移アクションを利用可能な推移アクションプールからドラッグし、それらを割り当てした推移アクションプールにドロップし、送信ボタンをクリックします。

図:推移アクションを割り当てます

メインプロセス編集画面に戻って(キャンバス下にある他のすべての変更を保存するための)保存ボタンをクリックします。

次のアクティビティ、推移、推移アクションを追加することで「パス」を完成します。

「承認」まで依頼・要求を記録すること

  • 出発点:アクティビティ:依頼・要求の記録(A1)

  • 可能な推移:承認(T1)

    • この活動の条件が満たされれば、チケットはアクティビティに移ります:承認(A2)

    • さらに、次の推移アクションが実行されます:

      • 「「管理 」キューへチケットを移動させる」(TA1)

      • 「チケットの責任者を「マネージャー」に設定する」(TA2)

アクティビティ:「依頼・要求を記録する」(A1)が プロセス・チケットの定義されたステップです。そのステップでは、推移:「承認」(T1)の可能性があります。これが適用されれば、チケットは次のアクティビティ:「承認」(A2)に移ります。 そして推移アクション:「「管理」キューへチケットを移動させる」(TA1)こと、及び「チケットの責任者として「マネージャー」を設定する」(TA2)が実行されます。アクティビティの中で:「承認」(A2)(アクティビティ・ダイアログ)、「承認拒否」(AD2)そして、「承認済」(AD3)が利用可能です。

承認

  • 出発点:アクティビティ:「承認」(A2)

  • 可能な推移:

    • 「承認拒否」(T2)

      • これが一致すれば、プロセス・チケットはアクティビティに移ります:「プロセス完了」(A5)

      • さらに、次の推移アクションが実行されます:

        • 「「従業員」キューへプロセス・チケットを移動」(TA3)

        • 「チケットの責任者を「従業員」設定」(TA4)

        • 「チケットが正しく完了しませんでした」(TA8)

    • 「承認済」(T3)

      • これが一致すれば、プロセス・チケットはアクティビティ:「注文」に移ります(A3)

      • さらに次の推移アクションが実行されます

        • 「プロセス・チケットを「購入」キューに移動します。」(TA5)

プロセスチケットのステップを定義する現在のアクティビティを見ればわかることがあります。推移には1個以上の可能性があり、それはまさにひとつのターゲット・アクティビティです。(そしておそらく1個以上の推移アクションです。)

注文

  • 開始点:アクティビティ「注文」(A3)

  • 可能な推移:

    • 「注文拒否」 (T4)

      • これが一致すれば、プロセス・チケットはアクティビティに移ります:「プロセス完了」(A5)

      • さらに、次の推移アクションが実行されます:

        • 「「従業員」キューへプロセス・チケットを移動」(TA3)

        • 「チケットの責任者を「従業員」設定」(TA4)

        • 「チケットが正しく完了しませんでした」(TA8)

    • 「発注」 (T5)

      • これが一致すれば、プロセス・チケットはアクティビティに移るでしょう:「入信」(A5)

      • さらに次の推移アクションが実行されます

        • 「「郵便局」キューにプロセス・チケットを移動させてください」(TA6) 

Incoming(入信)

  • 出発点:アクティビティ「入信」A4

  • 可能な推移:

    • 「貨物受取」 (T6)

      • これが一致すれば、プロセス・チケットはアクティビティに移ります:「プロセス完了」(A5)

      • さらに、次の推移アクションが実行されます:

        • 「「従業員」キューへプロセス・チケットを移動」(TA3)

        • 「チケットの責任者を「従業員」設定」(TA4)

        • 「チケットが正しく完了しました(TA7)」

本の注文プロセスの完全なパスはこのように見えるでしょう。

図:本の注文の完全なプロセス・パス

プロセス・パスを終了した後、キャンバスの下方部分中の「セーブする」ボタンをクリックして、次に、「全てのプロセスを同期」ボタンをクリックしてください。これはデータベースからすべてのプロセス情報を収集しキャッシュ・ファイル(Perl言語で)を作成します。このキャッシュ・ファイルは実際、プロセス・チケットを作成するか使用するためにシステムが使用するプロセス・構成です。

プロセス(GUIの中の)に行なわれるどんな変更も、システムで変更を反映するために再度キャッシュ・ファイルを同期させる必要があります。

さらに、YAMLファイルから全工程をインポートすることは可能です。しかし、インポートの前に各プロセスによって必要な動的フィールド、ユーザ、キューなどをすべて作ることがまだ必要です。

プロセスがACLの使用を要求する場合、手動でセットされることも必要であることに注目してください。

以下は本の注文の処理例のための完全なYAMLファイルです:

---
Activities:
  A1:
    ActivityDialogs:
      - AD1
    ChangeTime: 2012-11-23 14:49:22
    Config:
      ActivityDialog:
        1: AD1
    CreateTime: 2012-11-23 11:49:38
    EntityID: A1
    ID: 151
    Name: Recording the demand
  A2:
    ActivityDialogs:
      - AD2
      - AD3
    ChangeTime: 2012-12-13 00:55:12
    Config:
      ActivityDialog:
        1: AD2
        2: AD3
    CreateTime: 2012-11-23 11:50:11
    EntityID: A2
    ID: 152
    Name: Approval
  A3:
    ActivityDialogs:
      - AD4
      - AD5
    ChangeTime: 2012-11-23 18:12:14
    Config:
      ActivityDialog:
        1: AD4
        2: AD5
    CreateTime: 2012-11-23 11:50:35
    EntityID: A3
    ID: 153
    Name: Order
  A4:
    ActivityDialogs:
      - AD6
    ChangeTime: 2012-11-23 18:12:35
    Config:
      ActivityDialog:
        1: AD6
    CreateTime: 2012-11-23 11:51:00
    EntityID: A4
    ID: 154
    Name: Incoming
  A5:
    ActivityDialogs: []
    ChangeTime: 2012-11-23 11:51:33
    Config: {}
    CreateTime: 2012-11-23 11:51:33
    EntityID: A5
    ID: 155
    Name: Process complete
ActivityDialogs:
  AD1:
    ChangeTime: 2012-12-06 02:16:21
    Config:
      DescriptionLong: ''
      DescriptionShort: Recoding the demand
      FieldOrder:
        - DynamicField_Author
        - DynamicField_ISBN
        - DynamicField_Title
        - DynamicField_Status
      Fields:
        DynamicField_Author:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_ISBN:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Status:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Title:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
      Interface:
        - AgentInterface
      Permission: ''
      RequiredLock: 0
      SubmitAdviceText: ''
      SubmitButtonText: ''
    CreateTime: 2012-11-23 14:34:43
    EntityID: AD1
    ID: 154
    Name: Recording the demand
  AD2:
    ChangeTime: 2012-11-23 14:57:41
    Config:
      DescriptionLong: ''
      DescriptionShort: Approval denied
      FieldOrder:
        - Article
        - DynamicField_Status
      Fields:
        Article:
          Config:
            ArticleType: note-internal
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Status:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
      Interface:
        - AgentInterface
      Permission: ''
      RequiredLock: 0
      SubmitAdviceText: ''
      SubmitButtonText: Deny Request
    CreateTime: 2012-11-23 14:36:39
    EntityID: AD2
    ID: 155
    Name: Approval denied
  AD3:
    ChangeTime: 2012-12-14 03:14:23
    Config:
      DescriptionLong: ''
      DescriptionShort: Approved
      FieldOrder:
        - DynamicField_Status
      Fields:
        DynamicField_Status:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
      Interface:
        - AgentInterface
      Permission: ''
      RequiredLock: 0
      SubmitAdviceText: ''
      SubmitButtonText: Approve Request
    CreateTime: 2012-11-23 14:37:35
    EntityID: AD3
    ID: 156
    Name: Approved
  AD4:
    ChangeTime: 2012-11-23 14:58:52
    Config:
      DescriptionLong: ''
      DescriptionShort: Order rejected
      FieldOrder:
        - Article
        - DynamicField_Status
      Fields:
        Article:
          Config:
            ArticleType: note-internal
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Status:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
      Interface:
        - AgentInterface
      Permission: ''
      RequiredLock: 0
      SubmitAdviceText: ''
      SubmitButtonText: Reject Order
    CreateTime: 2012-11-23 14:38:48
    EntityID: AD4
    ID: 157
    Name: Order rejected
  AD5:
    ChangeTime: 2012-12-06 02:20:12
    Config:
      DescriptionLong: ''
      DescriptionShort: Order placed
      FieldOrder:
        - DynamicField_DeliveryDate
        - DynamicField_Price
        - DynamicField_Supplier
        - DynamicField_Status
      Fields:
        DynamicField_DeliveryDate:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Price:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Status:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Supplier:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
      Interface:
        - AgentInterface
      Permission: ''
      RequiredLock: 0
      SubmitAdviceText: ''
      SubmitButtonText: Place Order
    CreateTime: 2012-11-23 14:41:28
    EntityID: AD5
    ID: 158
    Name: Order placed
  AD6:
    ChangeTime: 2012-11-23 14:42:43
    Config:
      DescriptionLong: ''
      DescriptionShort: Shipment received
      FieldOrder:
        - DynamicField_DateOfReceipt
        - DynamicField_Status
      Fields:
        DynamicField_DateOfReceipt:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
        DynamicField_Status:
          DefaultValue: ''
          DescriptionLong: ''
          DescriptionShort: ''
          Display: 1
      Interface:
        - AgentInterface
      Permission: ''
      RequiredLock: 0
      SubmitAdviceText: ''
      SubmitButtonText: ''
    CreateTime: 2012-11-23 14:42:43
    EntityID: AD6
    ID: 159
    Name: Shipment received
Process:
  Activities:
    - A1
    - A2
    - A3
    - A4
    - A5
  ChangeTime: 2012-12-06 02:31:59
  Config:
    Description: The process to order a book
    Path:
      A1:
        T1:
          ActivityEntityID: A2
          TransitionAction:
            - TA2
            - TA1
      A2:
        T2:
          ActivityEntityID: A5
          TransitionAction:
            - TA3
            - TA4
            - TA8
        T3:
          ActivityEntityID: A3
          TransitionAction:
            - TA5
      A3:
        T4:
          ActivityEntityID: A5
          TransitionAction:
            - TA3
            - TA4
            - TA8
        T5:
          ActivityEntityID: A4
          TransitionAction:
            - TA6
      A4:
        T6:
          ActivityEntityID: A5
          TransitionAction:
            - TA3
            - TA4
            - TA7
      A5: {}
    StartActivity: A1
    StartActivityDialog: AD1
  CreateTime: 2012-11-23 11:45:12
  EntityID: P1
  ID: 94
  Layout:
    A1:
      left: 172
      top: 63
    A2:
      left: 402
      top: 156
    A3:
      left: 649
      top: 255
    A4:
      left: 774
      top: 391
    A5:
      left: 194
      top: 410
  Name: Book ordering
  State: Active
  StateEntityID: S1
  TransitionActions:
    - TA1
    - TA2
    - TA3
    - TA4
    - TA8
    - TA5
    - TA3
    - TA4
    - TA8
    - TA6
    - TA3
    - TA4
    - TA7
  Transitions:
    - T1
    - T2
    - T3
    - T4
    - T5
    - T6
TransitionActions:
  TA1:
    ChangeTime: 2012-11-23 16:01:37
    Config:
      Config:
        Queue: Management
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet
    CreateTime: 2012-11-23 15:50:59
    EntityID: TA1
    ID: 61
    Name: Move the process ticket into the "Management" queue
  TA2:
    ChangeTime: 2012-11-23 16:02:12
    Config:
      Config:
        Responsible: manager
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet
    CreateTime: 2012-11-23 15:58:22
    EntityID: TA2
    ID: 62
    Name: Change ticket responsible to "manager"
  TA3:
    ChangeTime: 2012-11-24 14:27:02
    Config:
      Config:
        Queue: Employees
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet
    CreateTime: 2012-11-23 16:02:54
    EntityID: TA3
    ID: 63
    Name: Move the process ticket into the "Employees" queue
  TA4:
    ChangeTime: 2012-11-23 16:04:06
    Config:
      Config:
        Responsible: Employee
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet
    CreateTime: 2012-11-23 16:04:06
    EntityID: TA4
    ID: 64
    Name: Change ticket responsible to "Employee"
  TA5:
    ChangeTime: 2012-12-06 02:18:34
    Config:
      Config:
        Queue: Purchasing
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet
    CreateTime: 2012-11-23 16:04:54
    EntityID: TA5
    ID: 65
    Name: Move process ticket into the "Purchasing" queue
  TA6:
    ChangeTime: 2012-12-06 02:18:48
    Config:
      Config:
        Queue: Post office
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet
    CreateTime: 2012-11-23 16:06:20
    EntityID: TA6
    ID: 66
    Name: Move process ticket into the "Post office" queue
  TA7:
    ChangeTime: 2012-12-06 02:29:55
    Config:
      Config:
        State: closed successful
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet
    CreateTime: 2012-12-06 02:29:27
    EntityID: TA7
    ID: 67
    Name: Close ticket successfully
  TA8:
    ChangeTime: 2012-12-06 02:31:12
    Config:
      Config:
        State: closed unsuccessful
      Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet
    CreateTime: 2012-12-06 02:31:12
    EntityID: TA8
    ID: 68
    Name: Close ticket unsuccessfully
Transitions:
  T1:
    ChangeTime: 2012-11-23 15:12:20
    Config:
      Condition:
        1:
          Fields:
            DynamicField_Status:
              Match: Approval
              Type: String
          Type: and
      ConditionLinking: and
    CreateTime: 2012-11-23 11:53:52
    EntityID: T1
    ID: 94
    Name: Approval
  T2:
    ChangeTime: 2012-11-23 15:12:50
    Config:
      Condition:
        1:
          Fields:
            DynamicField_Status:
              Match: Approval denied
              Type: String
          Type: and
      ConditionLinking: and
    CreateTime: 2012-11-23 11:54:26
    EntityID: T2
    ID: 95
    Name: Approval denied
  T3:
    ChangeTime: 2012-11-23 15:13:29
    Config:
      Condition:
        1:
          Fields:
            DynamicField_Status:
              Match: Approved
              Type: String
          Type: and
      ConditionLinking: and
    CreateTime: 2012-11-23 11:54:54
    EntityID: T3
    ID: 96
    Name: Approved
  T4:
    ChangeTime: 2012-11-23 15:14:08
    Config:
      Condition:
        1:
          Fields:
            DynamicField_Status:
              Match: Order denied
              Type: String
          Type: and
      ConditionLinking: and
    CreateTime: 2012-11-23 11:55:25
    EntityID: T4
    ID: 97
    Name: Order denied
  T5:
    ChangeTime: 2012-11-23 18:30:33
    Config:
      Condition:
        1:
          Fields:
            DynamicField_Status:
              Match: Order placed
              Type: String
          Type: and
      ConditionLinking: and
    CreateTime: 2012-11-23 11:56:15
    EntityID: T5
    ID: 98
    Name: Order placed
  T6:
    ChangeTime: 2012-11-23 15:15:30
    Config:
      Condition:
        1:
          Fields:
            DynamicField_Status:
              Match: Shipment received
              Type: String
          Type: and
      ConditionLinking: and
    CreateTime: 2012-11-23 11:56:48
    EntityID: T6
    ID: 99
    Name: Shipment received

                

プロセス構成リファレンス

プロセス

1つのプロセスはワークフロー/プロセスのパスを形成します。このパス上の中間地点はアクティビティまたは推移になりえます。これらについては後程お話します。

プロセス構成

プロセス構成は、ファイル Kernel/Config.pm中で行われます。しかし Kernel/Config/Files/MyProcess.pm のような新しいファイルを作成することが強く推奨されます。GUIがファイル Kernel/Config/File/ZZZProcessManagement を生成することに気づいて下さい。そのファイル名を使用することは回避してください。そうでなければ、同期プロセスの際ににそれは上書きされるでしょう。例:プロセス構成(プロセス・キャッシュ・ファイルからの)を見ましょう:

$Self->{'Process'} = {
    'P1' => {
        Name                => '本の注文',
        CreateTime          => '16-02-2012 13:37:00',
        CreateBy            => '1',
        ChangeTime          => '17-02-2012 13:37:00',
        ChangeBy            => '1',
        State               => 'Active',
        StartActivity       => 'A1',
        StartActivityDialog => 'AD1',
        Path => {
            'A1' => {
                'T1' => {
                    ActivityEntityID => 'A2',
                },
            },
            'A2' => {
                'T2' =>  {
                    ActivityEntityID => 'A3',
                },
            },
        },
    },
    'P2' => {
        Name                => 'IT 注文',
        CreateTime          => '26-02-2012 13:37:00',
        CreateBy            => '1',
        ChangeTime          => '27-02-2012 13:37:00',
        ChangeBy            => '1',
        State               => 'Active',
        StartActivity       => 'A2',
        StartActivityDialog => 'AD2',
        Path => {
            'A2' => {
                'T3' => {
                    ActivityEntityID => 'A4',
                },
            },
        },
    }
};
                    

Name

プロセスの名前、新しいプロセス・チケットを作成する場合、担当者はこれを選択することができます。

CreateTime

プロセスの作成時刻。

CreateBy

プロセスを作成するユーザのUID

ChangeTime

プロセスの変更時刻

ChangeBy

プロセスの最終変更ユーザのUID

State

プロセスの状態を定義します。可能な値:

  • 「Active(アクティブ)」は、新しいプロセス・チケットの中で使用することができる全てのプロセスです。

  • 「FadeAway(消失)」は、 もはやさらなる新規チケットを選択できないプロセスです。既存チケットはまだプロセスを使用可能です。

  • 「Inactive」(インアクティブ)は、不活性化されたプロセスです。新規も既存チケットも使用できません。

StartActivity

新しいプロセス・チケットを作成する場合、StartActivityを定義しなければいけません。チケットが作成されるとすぐに、このアクティビティは最初の推移チェック用の基礎としてセットされ使用されるでしょう。

StartActivityDialog

新しいプロセス・チケットでは、StartActivityDialogは定義されなければいけません。新しいプロセス・チケット(プロセスが選択された後)を作成する時、これが示されるでしょう。このポイントでは、チケットはまだ存在しません、それはStartActivityDialogを提出した後に作成されるでしょう。

パス

パスは、現在のプロセスのために、アクティビティの構造およびそれらの間の可能な推移を含みます。そしてさらに発生する推移アクションは移行時に起こります。これは、プロセス・チケットがとることができる方法をコントロールします。

'A1' => {
    'T1' => {
        ActivityEntityID => 'A2',
    },
    'T2' => {
        ActivityEntityID => 'A3',
    },
    'T3' => {
        ActivityEntityID => 'A4',
        TransitionAction => ['TA1', 'TA2'],
    },
},
                    

プロセス・チケットがアクティビティ('A1')にある場合、それには別の活動に到着する3つの可能な方法がある。推移(「T1」)に、「T3」に、条件は定義され、プロセス・チケットは別のアクティビティへの遷移を完了しなければならない。

この場合、推移「T2」に必要とされるプロセス・チケットおよびその動的なフィールドの値がすべて正確ならば、チケットは活動「A1」から「A3」に移動されるだろう。ActivityDialogが提出されるか、あるいはチケットに他の変更が行なわれる後、それは現在のアクティビティからの可能な推移をチェックされるだろう。複数の推移が可能ならば、最初のものが使用されるだろう(TransitionIDsをソートする数値ソートに基づく)。

さらに、パス設定中の推移に推移アクションを割り当てることは可能です。これらは成功した推移の後に実行されるモジュールである。それらは例でのような配列形式で指定しなければならない。詳細は後述します。

アクティビティ

アクティビティは1つ以上のアクティビティ・ダイアログを含んでおり、プロセスの「ステップ」をモデル化します。現在のアクティビティの全てのアクティビティダイアログはチケット・ズームで表示され、推移の条件が満たされるまで使用することができます。

アクティビティ構成

サンプルのアクティビティ構成を見ましょう:

$Self->{'Process::Activity'} =
{
    'A1' => {
        Name       => 'Activity 1 optional',
        CreateTime => '16-02-2012 13:37:00',
        CreateBy   => '1',
        ChangeTime => '17-02-2012 13:37:00',
        ChangeBy   => '1',
        ActivityDialog => {
            1 => 'AD1',
        },
    },
    'A2' => {
        Name       => 'Activity 2 optional',
        CreateTime => '16-02-2012 13:37:00',
        CreateBy   => '1',
        ChangeTime => '17-02-2012 13:37:00',
        ChangeBy   => '1',
        ActivityDialog => {
            1 => 'AD5',
            2 => 'AD6',
            3 => 'AD1',
        },
    },
};
                

Name

アクティビティの名前

CreateTime

アクティビティの作成時刻

CreateBy

アクティビティの作成ユーザーのユーザのUID

ChangeTime

アクティビティの変更時刻

ChangeBy

アクティビティの最終変更ユーザのユーザのUID

ActivityDialog(アクティビティ・ダイアログ)

アクティビティダイアログは、このアクティビティにおいて利用可能なアクティビティ・ダイアログのリストを含んでいます。現在のアクティビティの全てのアクティビティ・ダイアログはチケット・ズームで表示されます。それらの順序は、構成の中の順序でここでセットされます「AD5」は「AD6」および「AD1」の前に示されます。

ActivityDialog(アクティビティ・ダイアログ)

アクティビティ・ダイアログは特別の画面で、異なるアクティビティの中で使用することができます。

ActivityDialog(アクティビティ・ダイアログ)の構成

サンプルのコンフィグを見ましょう。

$Self->{'Process::ActivityDialog'} = {
    'AD1' => {
        Name             => 'ActivityDialog 1 optional',
        DescriptionShort => '基本情報',
        DescriptionLong  => 'IT注文に関する必要な基本情報を挿入して下さい。',
        CreateTime       => '28-02-2012 13:37:00',
        CreateBy         => '1',
        ChangeTime       => '29-02-2012 13:37:00',
        ChangeBy         => '1',
        Fields => {
            PriorityID => {
                DescriptionShort => '優先度 ID',
                DescriptionLong  => '優先度をここに入力して下さい。',
                Display          => 2,
            },
        },
        FieldOrder       => [ 'PriorityID' ],
        SubmitAdviceText => 'ノート:フォームを送信したい場合は...',
        SubmitButtonText => '要求を送信',
    },
    'AD2' => {
        Name => 'ActivityDialog 2 optional',
        DescriptionShort => '基本情報',
        DescriptionLong  => '本の注文に関する必要な基本情報を挿入して下さい。',
        CreateTime       => '28-02-2012 13:37:00',
        CreateBy         => '1',
        ChangeTime       => '29-02-2012 13:37:00',
        ChangeBy         => '1',
        Fields => {
            StateID => {
                DescriptionShort => '状態 ID',
                DescriptionLong  => '状態をここに入力して下さい。',
                Display          => 2,
                DefaultValue     => '2',
            },
            Queue => {
                DescriptionShort => 'キュー ID',
                DescriptionLong  => 'キューをここに入力して下さい。',
                Display          => 2,
                DefaultValue     => 'Raw',
            },
            Title => {
                DescriptionShort => 'タイトル',
                DescriptionLong  => 'タイトルをここに入力して下さい。',
                Display          => 1,
                DefaultValue     => 'Default Title',
            },
            DynamicField_Anzahl => {
                DescriptionShort    => '金額',
                DescriptionLong     => '金額をここに入力して下さい。',
                Display             => 2,
                DefaultValue        => '4',
            },
        },
        FieldOrder       => [ 'DynamicField_Anzahl', 'StateID', 'Queue', 'Title' ],
        SubmitAdviceText => 'ノート:フォームを送信する場合...',
        SubmitButtonText => '要求を送信',
    },
};
                    

Name

アクティビティ・ダイアログの名前

CreateTime

アクティビティ・ダイアログ作成時刻

CreateBy

このアクティビティ・ダイアログを作成したユーザのUID

ChangeTime

アクティビティ・ダイアログの最終変更時刻

ChangeBy

このアクティビティダイアログの最終変更者のユーザのUID

フィールド

このアクティビティダイアログで表示することができる全てのフィールドを含んでいます。次のフィールドは現在使用することができます:

    Title
    State
    StateID
    Priority
    PriorityID
    Lock
    LockID
    Queue
    QueueID
    Customer
    CustomerID
    CustomerNo
    CustomerUserID
    Owner
    OwnerID
    Type
    TypeID
    SLA
    SLAID
    Service
    ServiceID
    Responsible
    ResponsibleID
    PendingTime
    DynamicField_$FieldName  # 全ての動的フィールド用
                    

単一のフィールド構成の例:

StateID => {
    DescriptionShort => 'State ID',
    DescriptionLong  => 'Enter the state here',
    Display          => 2,
    DefaultValue     => '2',
},
                    

フィールド「記事」は特殊なケースです。それが「フィールド」構成の中にあれば、アクティビティ・ダイアログは件名フィールドおよび添付ファイル取扱い可能な機能を持った完全なリッチテキスト・エディターを内蔵します。その後、入力されたテキストは、記事としてチケットに加えられ、電子メールで送られます。サンプルの記事フィールド構成を見ましょう:

Article => {
    DescriptionShort => 'ここにコメントを挿入して下さい',
    DescriptionLong => '',
    Display         => 1,
    Config          => {
        ArticleType  => 'note-internal',
        LabelSubject => '',
        LabelBody    => '',
    },
},
                    

フィールド構成オプションを見ましょう:

DescriptionShort(短い摘要)

フィールドタイトルで表示される短い摘要(オプション)。

DescriptionLong(長い摘要)

マウスがフィールド上に乗る時、表示されるより長い摘要(オプション)。フィールドの入力方法についての例示アドバイス。

Display(表示)

フィールドが示される かつ、または 必須の場合のコントロール。可能な値:

  • '0': フィールドは不可視です。フィールド値が自動的にセットならより便利でしょう。構成されたDefaultValueはこのケースでは格納されるでしょう。

  • '1' :フィールドは可視ですが任意です。

  • '2': fフィールドは可視でかつ必須です。次のフィールドが単に不可視にも必須にもなりえます:

        QueueID
        Queue
        State
        StateID
        Lock
        LockID
        Priority
        PriorityID
        Type
        TypeID
                                    

フィールドが任意として設定され、ユーザが値を送信しなければ、アクティビティ・ダイアログがユーザによって送信される時、デフォルト値が保存されます。

DefaultValue(デフォルト値)

「ID'」(QueueID、OwnerIDのように)を備えたフィールドに関して、これは、値のデータベースIDを参照します。'ID'(キュー、オーナーのように)のない他のフィールドについては、DefaultValueは値自体を含んでいなければいけません。例:

Queue => {
    DescriptionShort => 'Queue',
    DescriptionLong  => 'Enter the queue here',
    Display          => 2,
    DefaultValue     => 'Raw',
},
                        

FieldOrder(フィールド順序)

ここで、フィールドの表示順序は設定されます。重要:保存する時単に設定されたフィールドが考慮されるので、目に見えないフィールドはさらにここで設定されなければいけません。設定されないフィールドは保存されないでしょう。

SubmitAdviceText(アドバイス用テキストの送信)

補足的ヘルプかアドバイス用テキストのための送信ボタン上に示される任意のテキスト。

SubmitButtonText(送信ボタンのテキスト)

送信ボタンのための任意のカスタム・テキスト。

Transition(推移)

推移は、設定可能な条件に基づいて決定します。プロセス中でパスが取得されているような条件です。。(例えば プロセス・チケットが移動されうるアクティビティへのパスです)  

Transition configuration(推移構成)

サンプルを見ましょう:

$Self->{'Process::Transition'} = {
    'T1' => {
        Name => 'Transition 1',
        CreateTime => '14-03-2012 13:37:00', # optional
        CreateBy   => '1',                   # optional
        ChangeTime => '15-03-2012 13:37:00', # optional
        ChangeBy   => '15-03-2012 13:37:00', # optional
        Condition  => {
            Cond1  => {
                Fields => {
                    StateID => {
                        Type  => 'String',
                        Match => '1',
                    },
                },
            },
        },
    },
    'T2' => {
        Name       => 'Transition 2 optional',
        CreateTime => 'DATE',   # optional
        CreateBy   => 'USERID', # optional
        ChangeTime => 'DATE',   # optional
        ChangeBy => 'USERID',   # optional
        Condition => {
            Cond1 => {
                Queue               => 'Raw',
                DynamicField_Farbe  => '2',
                DynamicField_Anzahl => '1',
            },
        },
    },
};
                    

Name

推移の名前。

CreateTime

アクティビティ・ダイアログ作成時刻

CreateBy

この推移を作成したユーザのUID。

ChangeTime

アクティビティ・ダイアログの最終変更時刻

ChangeBy

この推移の最終変更者のユーザのUID。

Condition(条件)

Contains all conditions that are necessary for this Transition to take effect. Example:

Condition => {
    Type  => 'and',
    Cond1 => {
        Type   => 'and',
        Fields => {
            StateID => {
                Type  => 'String',
                Match => '1',
            },
            DynamicField_Marke => {
                Type  => 'String',
                Match => 'VW',
        },
    },
    Cond2 => {
        Type => 'and',
        Fields => {
            Queue => {
                Type  => 'String',
                Match => 'Raw',
            },
        },
    },
},
                    

構成の条件を詳細に見ましょう。

タイプ (条件)

異なる条件要素が互いに接続される方法を指定します。可能な値:

  • 'and': これはデフォルトです。推移が有効になるために条件をすべて満たさなければなりません。

  • 'or': 少なくとも1つの条件は一致しなければいけません。

  • 'xor': 1つの条件のみ一致しなければいけません。

Cond1

これはサンプルの条件の名前です。それは自由に選ぶことができます。条件はソート順に評価されます。

タイプ(Cond)

この条件の個々のフィールド試験が互いに接続される方法を指定します。可能な値:

  • 'and': これはデフォルトです。全てのフィールド・テスト条件をすべて満たさなければなりません。

  • 'or': 少なくとも1つの条件は一致しなければいけません。

  • 'xor': 1つの条件のみ一致しなければいけません。

フィールド

その値がテストされるべき特別のフィールドを指定します。私たちの例から:

Fields => {
    StateID => {
        Type  => 'String',
        Match => '1',
    },
                        

StateID

フィールド名の例。次のチケット・フィールドが使用されます。:

    Title
    State
    StateID
    Priority
    PriorityID
    Lock
    LockID
    Queue
    QueueID
    Customer
    CustomerID
    CustomerNo
    CustomerUserID
    Owner
    OwnerID
    Type
    TypeID
    SLA
    SLAID
    Service
    ServiceID
    Responsible
    ResponsibleID
    DynamicField_$FieldName # for all DynamicFields
                        

「ID」(SLAIDのように)を備えたフィールドをテストする時、フィールドのデータベースIDは、実際の値がそのために使用される他のフィールド(SLAのような)のための試験に使用されます。

タイプ

フィールド試験の種類を決定します。可能な値:

  • 「String」: フィールド値を「Match」で指定されたStringと比較します。それらが正確に同じである場合マッチします。

  • 「ハッシュ(Hush)」:フィールド値(ハッシュ)を「Match」で指定されたハッシュと比較します。ハッシュ値はすべて同じでなければいけない。

  • 「配列(array)」:フィールド値(配列)を「Match」で指定された配列と比較します。両方のリストは同じでなければならない。

  • 「Regex:」:フィールド値は正規表現でテストすることができます。「Match」が基本的条件としてqr{}xmsを含むことは重要です。{}間に、実際の正規表現を記述することができます。

  • 「モジュール:」:条件チェックのためにperlモジュールを使用することができます。チェックが1を返すならば、チェックは成功です。Kernel/System/ProcessManagement/TransitionValidation/ValidateDemo.pm. でサンプル・モジュールを見つけることができます。

推移アクション

推移アクションは、推移がうまく適用された後で、きっかけとなるアクションです。(プロセス・チケットがひとつのアクティビティから別のアクティビティへ移る場合)これらの推移アクションはチケットで異なる変更を実施するために使われます。(例えば、キューまたはチケットのオーナーの変更)そうすれば、さらに、他の複雑な変更を行なうために自分の推移アクションを作成することができます。

推移アクション構成

例を見ましょう::

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Queue Move',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',
        Config => {
            Queue  => 'Junk',
            UserID => 123,
        },
    },
};
                    

Name

推移アクションの名前。

Module(モジュール)

使用されるパール・モジュールを指定します。

Config(構成)

このパラメーターは、モジュールに必要なセッティングをすべて含んでいます。その内容は、使用される特定の推移アクション・モジュールに依存します。詳細については、個々のモジュールのドキュメンテーションを参照してください。私たちの例において、キューだけが指定されねばなりません。

推移アクションの「構成」パラメタ内部のUserIDの使用は、全ての推移アクション(OTRS 3.2.4以来の)によって認めてられています。この例では、推移を引き起こすユーザーが、チケットを「ジャンク」キューへ移動する権限を持っているかどうかが、特に重要になりえます。ユーザーID 123を持つユーザーが持っているかもしれませんが。。

推移アクション・モジュールの再使用

推移アクション・モジュールを複数回使用するためには、単に構成中でいくつかTransitionActionsを指定してください。例:

    $Self->{'Process::TransitionAction'} = {
        'TA1' => {
            Name   => 'Queue Move Junk',
            Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',
            Config => {
                Queue => 'Junk',
            },
        },
        'TA2' => {
            Name   => 'Queue Move Raw',
            Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',
            Config => {
                Queue => 'Raw',
            },
        },
    };
                    

ここで、同じモジュールは、「未対応」キューにプロセス・チケット移動するために、そしてある時はジャンクキューへそれを移動するために、使用されます。特別の推移に使用されることが求められる推移アクションは、プロセス構成の「パス」設定から決定されます。

利用可能な推移アクション

OTRSは、あなたのプロセスで使用できるいくつかの推移アクションを搭載しています。ここでは、それらのドキュメンテーション、およびどのようにしてそれらを設定する必要があるかを見つけることができます。

DynamicFieldSet (動的フィールドのセット)

プロセス・チケットで1つ以上の動的フィールドをセットします。

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set DynamicField Master to Master and Approved to 1',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::DynamicFieldSet',
        Config => {
            MasterSlave => 'Master',
            Approved    => '1',

        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「MasterSlave」と「Approved:承認済」は DynamicField名のサンプルを付与されます。フィールド値 (「Master'」and 「1」) はこの推移アクションによってセットされます。

TicketArticleCreate(チケット記事の作成)

記事を作成し、ノートあるいは電子メール返答を作成するために使用することができます。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Article Create Note Internal',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketArticleCreate',
        Config => {
            ArticleType      => 'note-internal',                                        # note-external|phone|fax|sms|...
                                                                                        #   excluding any email type
            SenderType       => 'agent',                                                # agent|system|customer
            ContentType      => 'text/plain; charset=ISO-8859-15',                      # or optional Charset & MimeType
            Subject          => 'some short description',                               # required
            Body             => 'the message text',                                     # required
            HistoryType      => 'OwnerUpdate',                                          # EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|...
            HistoryComment   => 'Some free text!',
            From             => 'Some Agent <email@example.com>',                       # not required but useful
            To               => 'Some Customer A <customer-a@example.com>',             # not required but useful
            Cc               => 'Some Customer B <customer-b@example.com>',             # not required but useful
            ReplyTo          => 'Some Customer B <customer-b@example.com>',             # not required
            InReplyTo        => '<asdasdasd.12@example.com>',                           # not required but useful
            References       => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # not required but useful
            NoAgentNotify    => 0,                                                      # if you don't want to send agent notifications
            AutoResponseType => 'auto reply',                                           # auto reject|auto follow up|auto reply/new ticket|auto remove

            ForceNotificationToUserID   => [ 1, 43, 56 ],                               # if you want to force somebody
            ExcludeNotificationToUserID => [ 43, 56 ],
                 # if you want full exclude somebody from notfications,
                 # will also be removed in To: line of article,
                 # higher prio as ForceNotificationToUserID
            ExcludeMuteNotificationToUserID => [ 43, 56 ],
                 # the same as ExcludeNotificationToUserID but only the
                 # sending gets muted, agent will still shown in To:
                 # line of article
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。それは自由に選ぶことができますが、設定されたアクションの目的を反映するべきです。

「ArticleType」は、作成される記事のタイプを定義します。可能な値:電話、ファックス、sms、webrequest、ノート内部、ノート外部およびノート報告書。

「SenderType」は送り手タイプの記事を定義します。可能な値:担当者、システム、顧客。

「ContentType」は、記事のコンテンツ・タイプを定義します。可能な値:'プレインテキスト;charset=ISO-8859-15'又は他の有効なcharsetとMIMEタイプ。

「Subject」は記事タイトルを定義します。必須項目。

「Body」は記事内容を定義します。必須項目。

「HistoryType」は、履歴エントリーのタイプを定義します。可能な値:AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent,EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart,EscalationResponseTimeStop,EscalationSolutionTimeNotifyBefore,EscalationSolutionTimeStart, EscalationSolutionTimeStop,EscalationUpdateTimeNotifyBefore,EscalationUpdateTimeStart, EscalationUpdateTimeStop,FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, NewTicket, OwnerUpdate,PhoneCallAgent, PhoneCallCustomer,PriorityUpdate, Remove, ResponsibleUpdate,SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply,SendCustomerNotification, ServiceUpdate, SetPendingTime, SLAUpdate, StateUpdate,Subscribe, SystemRequest, TicketDynamicFieldUpdate, TicketLinkAdd, TicketLinkDelete,TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.

「HistoryComment」は、履歴エントリーの内容を定義します。

上で指定した表記法で'From', 'To', 'Cc' and 'ReplyTo'はEメール・アドレスをとります。

「InReplyTo」および「References」はEメール・メッセージIDをとります。

「NoAgentNotify」-1にセットされれば、担当者への電子メール通知は送られません。

「AutoResponseType」は次の値をとることができます:自動フォローアップ、自動拒否、自動削除、自動応答、自動返答/新規チケット。

'ForceNotificationToUserID', 'ExcludeNotificationToUserID','ExcludeMuteNotificationToUserID' は、ユーザーIDのリストをとることができます。そのリストとは、「常に通知」、「非通知」、または「通知されるが実際には通知メールを送らない、です。

チケット作成

Creates a ticket with an article, the new ticket can be linked with process ticket. Example:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Ticket Create',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketCreate',
        Config => {

            # ticket required:
            Title         => 'Some Ticket Title',
            Queue         => 'Raw',              # or QueueID => 123,
            Lock          => 'unlock',
            Priority      => '3 normal',         # or PriorityID => 2,
            State         => 'new',              # or StateID => 5,
            CustomerID    => '123465',
            CustomerUser  => 'customer@example.com',
            OwnerID       => 'someuserlogin',    # or OwnerID => 123,

            # ticket optional:
            TN              => $TicketObject->TicketCreateNumber(), # optional
            Type            => 'Incident',            # or TypeID => 1, not required
            Service         => 'Service A',           # or ServiceID => 1, not required
            SLA             => 'SLA A',               # or SLAID => 1, not required
            ResponsibleID   => 123,                   # not required
            ArchiveFlag     => 'y',                   # (y|n) not required
            PendingTime     => '2011-12-23 23:05:00', # optional (for pending states)
            PendingTimeDiff => 123 ,                  # optional (for pending states)

            # article required:
            ArticleType      => 'note-internal',                        # note-external|phone|fax|sms|...
                                                                        #   excluding any email type
            SenderType       => 'agent',                                # agent|system|customer
            ContentType      => 'text/plain; charset=ISO-8859-15',      # or optional Charset & MimeType
            Subject          => 'some short description',               # required
            Body             => 'the message text',                     # required
            HistoryType      => 'OwnerUpdate',                          #
            EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|...
            HistoryComment   => 'Some free text!',

            # article optional:
            From             => 'Some Agent <email@example.com>',       # not required but useful
            To               => 'Some Customer A <customer-a@example.com>', # not required but useful
            Cc               => 'Some Customer B <customer-b@example.com>', # not required but useful
            ReplyTo          => 'Some Customer B <customer-b@example.com>', # not required
            MessageID        => '<asdasdasd.123@example.com>',          # not required but useful
            InReplyTo        => '<asdasdasd.12@example.com>',           # not required but useful
            References       => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # not required but useful
            NoAgentNotify    => 0,                                      # if you don't want to send agent notifications
            AutoResponseType => 'auto reply'                            # auto reject|auto follow up|auto reply/new ticket|auto remove

            ForceNotificationToUserID   => [ 1, 43, 56 ],               # if you want to force somebody
            ExcludeNotificationToUserID => [ 43,56 ],                   # if you want full exclude somebody from notifications,
                                                                        # will also be removed in To: line of article,
                                                                        # higher prio as ForceNotificationToUserID
            ExcludeMuteNotificationToUserID => [ 43,56 ],               # the same as ExcludeNotificationToUserID but only the
                                                                        # sending gets muted, agent will still shown in To:
                                                                        # line of article
            TimeUnit                        => 123

            # other:
            DynamicField_NameX => $Value,
            LinkAs => $LinkType,                                        # Normal, Parent, Child, etc. (respective original ticket)
            UserID => 123,                                              # optional, to override the UserID from the logged user
        }
                        

「Name」は、設定された推移アクション名前を指定します。それは自由に選ぶことができますが、設定されたアクションの目的を反映するべきです。

'Title' The ticket title.

'Queue' or 'QueueID' specifies the name or id of the queue to be used in the new ticket.

'Lock' or 'LockID' sets the lock status of the ticket.

'Priority' or 'PriorityID' specifies the name or od if the priority to be used in the new ticket.

'State' or 'StateID' specifies the name or id of the state to be used in the new ticket.

'CustomerID', the customer id to be set for the new ticket.

'CustomerUser', the login of the customer that will be assigned in the ticket.

'Owner' or 'OwnerID', specifies the login or id of the agent that will be the new ticket owner.

'TN', custom number for the new ticket.

'Type' or 'TypeID' specifies the name or id of the ticket type to be used in the new ticket.

'Service' or 'ServiceID' specifies the name or id of the service to be used in the new ticket.

'SLA' or 'SLaID' specifies the name or id of the SLA to be used in the new ticket.

'ResponsibleID', the ID of the agent that will be the new ticket responsible.

'PendingTime', a predefined date to set the Ticket Pending Times, when the ticket state belongs to a pending state type

'PendingTimeDiff', a dynamically date ( expressed in seconds from current date/time ) to set the Ticket Pending Times, when the ticket state belongs to a pending state type

「ArticleType」は、作成される記事のタイプを定義します。可能な値:電話、ファックス、sms、webrequest、ノート内部、ノート外部およびノート報告書。

「SenderType」は送り手タイプの記事を定義します。可能な値:担当者、システム、顧客。

「ContentType」は、記事のコンテンツ・タイプを定義します。可能な値:'プレインテキスト;charset=ISO-8859-15'又は他の有効なcharsetとMIMEタイプ。

「Subject」は記事タイトルを定義します。必須項目。

「Body」は記事内容を定義します。必須項目。

'HistoryType' defines the type of the history entry. Possible values: AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent, EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart, EscalationResponseTimeStop, EscalationSolutionTimeNotifyBefore, EscalationSolutionTimeStart, EscalationSolutionTimeStop, EscalationUpdateTimeNotifyBefore, EscalationUpdateTimeStart, EscalationUpdateTimeStop, FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, NewTicket, OwnerUpdate, PhoneCallAgent, PhoneCallCustomer, PriorityUpdate, Remove, ResponsibleUpdate, SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply, SendCustomerNotification, ServiceUpdate, SetPendingTime, SLAUpdate, StateUpdate, Subscribe, SystemRequest, TicketDynamicFieldUpdate, TicketLinkAdd, TicketLinkDelete, TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.

「HistoryComment」は、履歴エントリーの内容を定義します。

上で指定した表記法で'From', 'To', 'Cc' and 'ReplyTo'はEメール・アドレスをとります。

「InReplyTo」および「References」はEメール・メッセージIDをとります。

「NoAgentNotify」-1にセットされれば、担当者への電子メール通知は送られません。

「AutoResponseType」は次の値をとることができます:自動フォローアップ、自動拒否、自動削除、自動応答、自動返答/新規チケット。

'ForceNotificationToUserID', 'ExcludeNotificationToUserID','ExcludeMuteNotificationToUserID' は、ユーザーIDのリストをとることができます。そのリストとは、「常に通知」、「非通知」、または「通知されるが実際には通知メールを送らない、です。

'TimeUnit' the time invested in the current ticket article expressed in seconds, minutes, hours, etc.

'DynamicField_NameX' where DynamicField_ is a required prefix and NameX is the name of a Dynamic Field to be set in the new ticket (on ticket level, not article levels)

'LinkAs' to define the new ticket relation with originator ticket, from the new ticket point of view, for example Normal, Parent, Child etc.

TicketCustomerSet(チケット・顧客・セット)

顧客にプロセス・チケットをセットします。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Customer Set Customer to test',
        Module => 'Kernel::System::Process::TransitionAction::TicketCustomerSet',
        Config => {
            No      => 'test',
            User    => 'client-user-123',
            # or in other words
            # CustomerID     => 'client123',
            # CustomerUserID => 'client-user-123',

        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

No あるいは、CustomerIDは、顧客の顧客IDをセットします。

ユーザまたはCustomerUserIDは、顧客のユーザー名をセットします。

TicketLockSet(チケット・ロック・セット)

プロセス・チケットのロックを変更します。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set Lock to lock',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketLockSet',
        Config => {
            Lock   => 'lock',
            # or
            LockID => 2,
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Lock」は、プロセス・チケットの新しいロックを定義します。

「LockID」は、新しいロックの内部IDを定義します。

TicketOwnerSet(チケット・所有者・セット)

プロセス・チケットの所有者を変更します。

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Owner Set root@localhost',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketOwnerSet',
        Config => {
            Owner => 'root@localhost',
            # or
            OwnerID => 1,
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Owner」は、新しい所有者のログイン名を指定します。

「OwnerID」は、新しい所有者の内部IDを指定します。

TicketQueueSet(チケット・キュー・セット)

ターゲット・キューにチケットを移動します。

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Queue Move Raw',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',
        Config => {
            Queue => 'Raw',
            # or
            # QueueID => '2',
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Queue」は、対象のキューの名前を指定します。

「QueueID」は、対象のキューの内部IDを指定します。

TicketResponsibleSet(チケット・責任者・セット)

プロセス・チケットの責任者を変更します。

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Responsible Set root@localhost',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet',
        Config => {
            Responsible => 'root@localhost',
            # or
            ResponsibleID => 1,
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Responsible」は、新しい責任者のログイン名を指定します。

「ResponsibleID」は新しい責任者の内部IDを指定します。

TicketServiceSet(チケット・サービス・セット)

プロセス・チケットにサービスを割り当てます。チケットは顧客を持つことを要求します。そしてそのサービスは、顧客に割り当てなければいけません。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set MyService service',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketServiceSet',
        Config => {
            Service   => 'MyService',
            # or
            ServiceID => 123,
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Service」は、プロセス・チケットの新しいサービスを定義します。姓名は必要です(例えばGramdFatherService::FatherService::SonService)。

「ServiceID」は、新しいサービスの内部IDを定義します。

TicketSLASet(チケット・SLA・セット)

プロセス・チケットにサービスレベル合意を割り当てます。チケットはサービスを持つために要求します。また、SLAはそのサービスに割り当てられなければいけません。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set MySLA SLA',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketSLASet',
        Config => {
            SLA   => 'MyService',
            # or
            SLAID => 123,
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「SLA」は、プロセス・チケットの新しいサービスレベル合意を定義します。

「SLAID」は、新しいSLAの内部IDを定義します。

TicketStateSet(チケット・状態・セット)

プロセス・チケットの状態を変更します。

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set State to open',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketStateSet',
        Config => {
            State   => 'open',
            # or
            StateID => 4,

            PendingTimeDiff => 123,
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「State」は、プロセス・チケットの新しい状態を定義します。

「StateID」は、新しい状態の内部IDを定義します。

Typeの状態が保留の時のみ使用する「PendingTimeDiff」は、チケットのの保留時間を設定するために(例えば保留時間3600は、推移アクションの実行後、一時間を意味します)、秒単位での時差(推移アクション実行時間に関連して)を定義します。

TicketTitleSet(チケット・タイトル・セット)

プロセス・チケットのチケット・タイトルをセットします。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set Ticket Title to Ticket-title',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTitleSet',
        Config => {
            Title => 'Ticket-title',
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Title」は、チケットの新しいタイトルを指定します。

TicketTypeSet(チケット・タイプ・セット)

チケット・タイプのプロセス・チケットをセットします。例:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set Ticket Type to default',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTypeSet',
        Config => {
            Type     => 'default',
            # or
            # TypeID => '1',
        },
    },
};
                        

「Name」は、設定された推移アクション名前を指定します。

「Type」は、チケット・タイプの名前を指定します。

「TypeID」は、チケット・タイプの内部IDを指定します。

アクセス・コントロール・リスト(ACL)

ACLの支援によって、プロセス・チケット中の選択可能な値を制限することができます。チケットACLシンタックスの詳細記述については、さらにACLリファレンスを参照ください。

ACL構成

ACLは単にKernel/Config.pmに定義することができます。例:

$Self->{TicketAcl}->{'001-ACL-ProcessProperties'} = {
    Properties => {
        Process => {
            ProcessEntityID        => ['P1'],
            ActivityEntityID       => ['A1'],
            ActivityDialogEntityID => ['AD1'],
        }
    },
    Possible => {
        ActivityDialog => ['AD1', 'AD3'],
    },
    PossibleNot => {
        ActivityDialog => ['AD3'],
    },
};
                    

001-ACL-ProcessProperties

ACL規則の名前。ACL規則一般についてのさらに詳しい情報については、ACLマニュアルを調べてください:

プロセス

これはACLが適用されなければいけないかどうかをチェックするために使用されるセクションです。それが指定された値を持っている場合、規則が適用されます。次の値は使用することができます:

ProcessEntityID

プロセスのID、プロセス。チケットがこのプロセスに割り当てられる場合マッチします。

ActivityEntityID

プロセス・チケットが現在割り当てられるアクティビティのID。

ActivityDialogEntityID

プロセス・チケットには現在開いているアクティビティ・ダイアログのID。

「可能」(Possible)/ 「不可能」(PossibleNot) アクティビティ・ダイアログ

ここでは、アクティビティ・ダイアログIDのリストを指定することができます。このリストは、チケット・ズーム・マスク中のユーザに提示される可能なアクティビティ・ダイアログを制限するでしょう。

「Possible(可能)」は、許可されるアクティビティ・ダイアログをリストします。上記のセッティングは、設定されたアクティビティ・ダイアログのリストの「AD1」および「AD3」のみを許可するでしょう。

「PossibleNot(不可能)」は、許可されないアクティビティ・ダイアログをリストします。上記の例において、セッティングは設定されたアクティビティ・ダイアログのリストから「AD3」を取り除くでしょう。

「可能」と「不可能」の両方が指定されれば、設定されたアクティビティ・ダイアログのリストはまず「可能」でフィルタされます。サンプルではAD1とAD3のみそのまま残してあります。つぎに「不可能」が適用されます。「AD3」はフィルタで除外され、それゆえに「AD1」のみが残り、ユーザが使える可能なアクティビティ・ダイアログとして表示されます。

複数のACL規則がマッチすればしたら、すべてのマッチング規則の共通部分は可能なアクティビティ・ダイアログを決定するために計算されます。例:

設定されたアクティビティ・ダイアログ:「AD1」、「AD2」、「AD3」、「AD4」、「AD5」、「AD6」、「AD7」

$Self->{TicketAcl}->{'001-ACL-Status'} = {
    Properties => {
        Ticket => {
            Status => 'new',
        }
    },
    Possible => {
        ActivityDialog => ['AD1', 'AD2', 'AD3', 'AD6', 'AD7'],
    },
};
$Self->{TicketAcl}->{'002-ACL-Queue'} = {
    Properties => {
        Ticket => {
            Queue => ['Raw']
        }
    },
    Possible => {
        ActivityDialog => ['AD2', 'AD3', 'AD4', 'AD7'],
    },
};
$Self->{TicketAcl}->{'003-ACL-Priority'} = {
    Properties => {
        Ticket => {
            Priority => ['3 normal']
        }
    },
    PossibleNot => {
        ActivityDialog => ['AD3', 'AD4'],
    },
};
                    

プロセス・チケットが状態「new」を持ち、それが「未対応」キューにあり優先度「3 普通」を持つならば、その後、すべてのACL規則がマッチします。

第一のルールはアクティビティ・ダイアログを 'AD1', 'AD2', 'AD3', 'AD4', 'AD5', 'AD6', 'AD7'から'AD1', 'AD2', 'AD3', 'AD6', 'AD7' に減らし、'AD4' and 'AD5'を禁止します。

第二のルールはさらに残っているアクティビティ・ダイアログを減らし、ここでの例の'AD2','AD3', 'AD7'が残ります。。

3番目の規則は、さらに「不可能」によってリストを縮小するでしょう。「AD3」はリストから取り除かれます。それがリストの第一位に載っていなかったので、「AD4」は削除されません。最後に、「AD2」および「AD7」は、ユーザが利用することができる可能なアクティビティ・ダイアログとして残ります。

「新規プロセス・チケット」画面で表示可能なプロセスを限定することは可能です。その機能は、ACLは単にユーザに基づくことができるという唯一の例外をもってActivitiyDialogs(アクティビティ・ダイアログ)を限定することに似ています。

以下のサンプルを御覧ください。

$Self->{TicketAcl}->{'200-ACL-Process'} = {
    # match properties
    Properties => {
        User => {
            UserID => [2, 3],
        },
    },
    Possible => {
       Process => ['P1', 'P2', 'P3'],
    },
    PossibleNot => {
        Process => ['P4'],
    },
};
                    

$Self->{TicketAcl}->{'201-ACL-Process'} = {
    # match properties
    Properties => {
        User => {
            Group_rw => [ 'MyGroup' ],
        },
    },
    Possible => {
       Process => ['P1', 'P2', 'P3'],
    },
    PossibleNot => {
        Process => ['P4'],
    },
};
                    

$Self->{TicketAcl}->{'202-ACL-Process'} = {
    # match properties
    Properties => {
        User => {
            Role => [ 'MyRole' ],
        },
    },
    Possible => {
       Process => ['P1', 'P2', 'P3'],
    },
    PossibleNot => {
        Process => ['P4'],
    },
};