4.5.3.1 チケットのフィールド

チケットのフィールドは以下をカスタムすることができます。

Ops Iのチケット画面ではチケットの情報を変更する際、APIによってOTOBOと情報のやり取りを行います。 チケット画面に表示する項目「フィールド」を追加または削除する場合、使用するAPIの構成ファイルの編集が必要になります。ここでは使用するAPIを「カスタムAPI」と呼びます。フィールドを変更しない場合、カスタムAPI構成ファイルの変更は不要です。

フィールドの追加、削除はチケットタイプごとに設定でき、同じチケットタイプのすべてのチケットに反映されます。すでに作成済のチケットに対しては、追加されたフィールドは空欄で表示され、削除されたフィールドは表示されなくなります。
また、フィールドの追加、削除をチケットブラウザー画面のフィルタ機能に反映することができます。詳細は「フィルタへの反映」を参照してください。
チケット画面の詳細は「チケット」を参照してください。
フィールド名を変更することも可能です。詳細は「フィールド名の変更」を参照してください。

フィールドを追加、削除できるカスタムAPIは以下になります。

(表)フィールドを編集可能なカスタムAPI一覧

動作 API 関連する画面
チケット一覧取得 GET /capi/v1/tickets チケットブラウザー画面
チケットの詳細情報取得 GET /capi/v1/tickets/{id} チケット詳細画面
チケットブラウザー画面
チケットの作成 POST /capi/v1/tickets 新規チケット追加画面
チケットの一部情報更新 PATCH /capi/v1/tickets/{id} チケット詳細画面
チケットブラウザー画面
関連チケットの表示 GET /capi/v1/tickets/{id}/related-tickets チケットブラウザー画面
チケット詳細画面
※チケットブラウザー画面とチケット詳細画面の関連レコードのチケットタブに表示させる場合に、追加してください。

注意事項注意事項

フィールドの追加、編集、削除で文法やフィールド名などに誤りがあった場合、エラーは表示されませんが、正しく表示されないなど期待通りに機能しないことがあります。期待通りに機能しない場合は、文法や表記の誤りなどの確認をしてください。



変更手順を以下に示します。

(1)フィールドの追加

①OTOBOのダイナミック・フィールドを作成する

ITSMアプリケーションで以下の作業を実施します。この操作はITSMアプリケーションの[管理]機能で行うため、Primitiveロール「itsm_admin」の権限が必要です。

a. メインメニュー[管理]を選択し、[プロセス & 自動化]-[ダイナミック・フィールド]を開きます。
b. [操作]-[チケット]を選択し、選択肢から作成するフィールドのタイプを選択します。選択できるタイプは以下になります。それ以外はOps Iでの表示が非対応のため選択しないでください。
  • チェックボックス
  • 日付
  • 日時
  • ドロップダウン
  • 本文
  • テキストエリア
c. フィールドごとに必要な情報を入力し、保存します。入力情報の詳細はOTOBOのマニュアルを参照してください。OTOBOのマニュアルおよびバージョンについては付録「OSSのバージョンおよびエディション、参照先のマニュアル」を参照してください。また、「名前」に設定したフィールド名は②bでダイナミック・フィールド名として使用します。
d. 作成したフィールドが、ダイナミック・フィールド一覧に追加されます。

②チケット画面のカスタムAPI構成ファイルを編集する

OTOBOの情報をOps Iのチケット画面に反映するには、UIで定義されたカスタムAPIを実行します。カスタムAPIの構成ファイルの関係を以下に示します。

(図)チケット画面のカスタムAPI構成ファイル
(図)チケット画面のカスタムAPI構成ファイル (図)チケット画面のカスタムAPI構成ファイル

構成ファイルの中で、フィールド追加時に編集が必要なファイルは、JavaScriptファイル、JSON Schemaファイル、UIのYAMLファイルです。これらのファイルはあらかじめ登録されている「初期YAMLファイル」です。初期YAMLファイルの格納場所については「初期YAMLファイルのカスタム」を参照してください。

以下に編集が必要なファイルについて説明します。

a. JSON Schemaファイル

各カスタムAPIに対し、1または2種類のJSON Schemaファイルが存在し、それぞれ編集が必要です。編集が必要なファイルは「apps/datamodel/otobo-datasource-schemas/」に格納されています。

(表)編集が必要なJSON Schemaファイル

カスタムAPI JSON Schemaファイル 変更箇所
GET /capi/v1/tickets ticket-search-response.json content内のproperties
GET /capi/v1/tickets/{id} ticket-details-response.json 第1階層のproperties
POST /capi/v1/tickets リクエスト:
create-ticket-request-capi.json
レスポンス:
create-ticket-response-capi.json
第1階層のproperties
PATCH /capi/v1/tickets/{id} リクエスト:
update-ticket-request-patch.json
レスポンス:
update-ticket-response-patch.json
第1階層のproperties
GET /capi/v1/tickets/{id}/related-tickets list-related-ticket-response.json content内のproperties

JSON Schemaファイルの変更例を以下に示します。

(図)JSON Schemaファイルの変更例
(図)JSON Schemaファイルの変更例 (図)JSON Schemaファイルの変更例

UI側に渡すフィールドの一覧を定義している「properties」にOps I側のフィールド名と設定値(type、format、enum、default、formControl)を追加します。

  • Ops I側のフィールド名:任意の値を指定。ここで指定した値を、JavaScriptファイル、UIのYAMLファイルから参照。
  • フィールドの設定値:フィールドのタイプによって、必要な設定値(type、format、enum、default、formControl)を設定。詳細は「(表)フィールドのタイプと設定値の関係」参照。

(表)フィールドのタイプと設定値の関係

フィールドのタイプ type format enum default formControl
チェックボックス booleanかつnull - - - -
日付 string date - - -
日時 string date-time - - -
ドロップダウン string - 選択肢※1 初期値※2 -
本文 stringまたはnumber - - - -
テキストエリア string - - - text
※1:定義することを推奨
※2:enumの選択肢に空文字を含まない場合、「create-ticket-request-capi.json」にdefaultを設定する必要があります。enumの選択肢に含まれる値を初期値として設定してください。enumを設定しない場合は、defaultの設定も不要です。
また、すでにチケットが作成済みの状態でフィールドを追加する場合、既存のチケットでエラーが発生しないようにenumの選択肢には未選択を意味する「空文字」を含むようにしてください。


b. JavaScriptファイル

カスタムAPIにひもづくJavaScriptファイルに対して編集が必要です。
編集が必要なファイルは「apps/script/ticket-common/ticket_field_definition.js」です。

(表)編集が必要なJavaScriptファイル

カスタムAPI 変更箇所
GET /capi/v1/tickets TICKET_SEARCH_RESPONSEのresponse
GET /capi/v1/tickets/{id} TICKET_GET_DETAILS_RESPONSEのresponse
POST /capi/v1/tickets リクエスト:
CREATE_TICKET_REQUESTのextBody内のextra
レスポンス:
CREATE_TICKET_RESPONSEのresponse
PATCH /capi/v1/tickets/{id} リクエスト:
UPDATE_TICKET_PATCH_REQUESTのextBody内のextra
レスポンス:
UPDATE_TICKET_PATCH_RESPONSEのresponse
GET /capi/v1/tickets/{id}/related-tickets TICKET_GET_LIST_RELATIONS_RESPONSEのresponse
GET /tickets
POST /tickets
GET /tickets/{id}
PUT /tickets/{id}
PATCH /tickets/{id}
GET /tickets/{id}/related-tickets
CUSTOM_FIELDS_MAP
※カスタムしたチケットのフィールドをACLで使用しない場合は編集不要です。


変更箇所に①で作成したダイナミック・フィールドの情報を追加します。
「OTOBOからOps Iへのレスポンス」、「Ops IからOTOBOへのリクエスト」、および「CUSTOM_FIELDS_MAP」の場合で記載形式が異なります。「CUSTOM_FIELDS_MAP」はACLを使用する場合、設定してください。
以下にそれぞれの記載形式と記載例を示します。
  • Ops I側のフィールド名:JSON Schemaファイル内のpropertiesラベルに追加する名前
  • ダイナミック・フィールド名:①で追加したダイナミック・フィールドの名前
  • 任意:null、または処理の追加など、ユーザーが自由に設定可能。

(図)記載形式(OTOBOからOps Iへのレスポンス)

(図)記載形式(OTOBOからOps Iへのレスポンス) (図)記載形式(OTOBOからOps Iへのレスポンス)

<OTOBOからOps Iへのレスポンスの記載例>

opsi_checkbox1:   convertFormatFromNumToBool(ticket.extra?.OTOBO_CheckBox1),  // チェックボックスタイプ※1
opsi_date1:          ticket.extra?.OTOBO_Date1 || "",                              // 日付タイプ
opsi_datetime1:    toUtcDateTimeFormat(ticket.extra?.OTOBO_DateTime1),     // 日時タイプ※2
opsi_dropdown1:  ticket.extra?.OTOBO_DropDown1 || "",                       //ドロップダウンタイプ
opsi_text1:           ticket.extra?.OTOBO_Text1 || "",                                // string型の本文タイプ
opsi_text2:           Number(ticket.extra?.OTOBO_Text2) || 0,                   // number型の本文タイプ
opsi_textarea1:     ticket.extra?.OTOBO_TextArea1 || "",                         // string型のテキストエリアタイプ

※1:OTOBOではチェックボックスのデータをtrueとfalseではなく1と0で管理します。そのためチェックボックスを追加する際はOTOBOの形式(1と0)からOps I(trueとfalse)の形式に変換が必要です。
※2:日時を追加する場合は、記載例のようにOTOBOの形式(YYYY-MM-DD hh:mm:ss)からOps Iへの形式(YYYY-MM-DD HH:mm:ssZ)に変換が必要です。

(図)記載形式(Ops IからOTOBOへのリクエスト)
(図)Ops IからOTOBOへのリクエストでの記載形式 (図)Ops IからOTOBOへのリクエストでの記載形式

<Ops IからOTOBOへのリクエストの記載例>

OTOBO_CheckBox1:    convertFormatFromBoolToNum(body.opsi_checkbox1),           // チェックボックスタイプ※3
OTOBO_Date1:           body.opsi_date1,                                   // 日付タイプ
OTOBO_DateTime1:    formatDateTimeRequestToOtobo(body.opsi_datetime1),         // 日時タイプ※4
OTOBO_DropDown1:   body.opsi_dropdown1,                          // ドロップダウンタイプ
OTOBO_Text1:            body.opsi_text1,                                   // string型の本文タイプ
OTOBO_Text2:            body.opsi_text2?.toString(),                   // number型の本文タイプ
OTOBO_TextArea1:      body.opsi_textarea1,                            // string型のテキストエリアタイプ

※3:OTOBOではチェックボックスのデータをtrueとfalseではなく1と0で管理します。そのためチェックボックスを追加する際はOps I(trueとfalse)の形式からOTOBOの形式(1と0)に変換が必要です。
※4:日時を追加する場合は、記載例のようにOps Iへの形式(YYYY-MM-DD HH:mm:ssZ)からOTOBOの形式(YYYY-MM-DD hh:mm:ss)に変換が必要です。
また、日時を追加する場合はDATETIME_CUSTOM_FIELDS にOps I側のフィールド名を記載してください。

(図)記載形式(CUSTOM_FIELDS_MAP)
(図)CUSTOM_FIELDS_MAPでの記載形式 (図)CUSTOM_FIELDS_MAPでの記載形式

<CUSTOM_FIELDS_MAPの記載例>

"newField1": "newDynamicField1"
"newField2": "newDynamicField2"

また、選択したフィールドタイプがドロップダウンの場合、およびチェックボックスで画面表示にtrue/falseを用いたい場合はドロップダウン、またはチェックボックスの選択肢の設定が必要です。
編集が必要なファイルは「apps/script/ticket-common/ticket_mapping_definition.js」です。

  1. OTOBO_MAPPING_OpsI側のフィールド名を定義し、Ops Iの画面で表示する選択肢と(1)①で設定したダイナミック・フィールドの選択肢(チェックボックスの場合は0、1)をひもづけます。コロン(:)の左側にOps Iの画面で表示する選択肢を、右側にダイナミック・フィールドの選択肢を指定してください。
    ドロップダウンの場合:

    const OTOBO_MAPPING_NEWFIELD2 = {
     "opsi A" : "otobo a",
     "opsi B" : "otobo b",
     "opsi C" : "otobo c",
    };

    チェックボックスの場合:

    const OTOBO_MAPPING_NEWFIELD2 = {
     "true" : "1",
     "false" : "0",
    };

  2. CUSTOM_FIELDS_VALUE_MAPに、OpsI側のフィールド名とⅠで定義した「OTOBO_MAPPING_Ops I側のフィールド名」を以下のように定義します。「CUSTOM_FIELDS_VALUE_MAP」は、「OTOBO_MAPPING_Ops I側のフィールド名」より後に定義してください。

    const CUSTOM_FIELDS_VALUE_MAP = {
     "newField2": OTOBO_MAPPING_NEWFIELD2,
    };



c. UIのYAMLファイル

下表に従い、各画面について、UIのYAMLファイルを編集してください。
このとき、タスクアプリケーションとリクエストアプリケーションのうち、ダイナミック・フィールドを表示させたいアプリケーションのYAMLファイルを編集してください。

(表)編集が必要なUIのYAMLファイルと編集内容

画面 UIのYAMLファイル 変更対象/ 変更内容(斜体文字は実際の値で置換え)
チケット
詳細画面
タスクアプリケーション:
  • apps/ui/ticket_detail_タイプ名_agent/manifest.yaml

リクエストアプリケーション:
  • apps/ui/ticket_detail_タイプ名_requester/manifest.yaml
<更新対象コンポーネント>
ticket_detail_form

<変更内容>
以下の書式に従い、フォームのフィールド(fields)に要素を追加する。必須区分や入力チェックなど、必要に応じて「(表)Formのプロパティ(UIバージョン1.1)」に記載のfieldのプロパティを追加可能。
- name: 任意の名前
  source: api
  field:
    read: ticketDetails.Ops I側のフィールド名
    update: patchTicketCustom.Ops I側のフィールド名
  label: ラベル表示名

メモメモ
リクエストアプリケーションの場合、updateプロパティを記載しないでください。
<更新対象コンポーネント>
related_records_ticket(関連レコードのチケット一覧)

<変更内容>
以下の書式に従い、テーブルのカラム(columns)に要素を追加する。関連レコードのチケット一覧で、追加したカラムを初期表示させない場合は、hide属性のtrueを追加する。
- name: 任意の名前
  source: api
  column:
    read: ticketRelated.Ops I側のフィールド名
  label: ラベル表示名
新規
チケット
追加画面
タスクアプリケーション:
  • apps/ui/ticket_new_タイプ名_agent/manifest.yaml

リクエストアプリケーション:
  • apps/ui/ticket_new_タイプ名_requester/manifest.yaml
<更新対象コンポーネント>
ticket_creation_form

<変更内容>
以下の書式に従い、フォームのフィールド(fields)に要素を追加する。必須区分や入力チェックなど、必要に応じて「(表)Formのプロパティ(UIバージョン1.1)」に記載のfieldのプロパティを追加可能。
- name: 任意の名前
  source: api
  field:
    create: createTicketCustom.Ops I側のフィールド名
  label: ラベル表示名
チケット
ブラウザー画面
タスクアプリケーション:
  • apps/ui/ticket_browser_agent/manifest.yaml

リクエストアプリケーション:
  • apps/ui/ticket_browser_requester/manifest.yaml
<更新対象タブ>
  • ticket_filter_tab
    (全チケットタイプ用の一覧画面に追加する場合)
  • ticket_filter_タイプ名_tab
    (個々のチケットタイプ用の一覧画面に追加する場合)

<更新対象コンポーネント>
ticket_filter_table(チケット一覧)

<変更内容>
以下の書式に従い、テーブルのカラム(columns)に要素を追加する。チケット一覧で、追加したカラムを初期表示させない場合は、hide属性のtrueを追加する。Ops I側のフィールド名とダイナミック・フィールド名が異なる場合は、sortnameにダイナミック・フィールド名を指定する。
チケット一覧取得APIには更新対象タブごとに以下の値を指定する。
  • ticket_filter_tab: ticketSearchList
  • ticket_filter_incident_tab: ticketIncidentSearchList
  • ticket_filter_request_tab: ticketRequestSearchList
  • ticket_filter_task_tab: ticketTaskSearchList
  • ticket_filter_rfc_tab: ticketRfcSearchList
  • ticket_filter_problem_tab: ticketProblemSearchList
  • ticket_filter_release_tab: ticketReleaseSearchList
  • ticket_filter_case_tab: ticketCaseSearchList
  • ticket_filter_unclassified_tab: ticketUnclassifiedSearchList
- name: 任意の名前
  source: api
  column:
     read: チケット一覧取得API.Ops I側のフィールド名
   label: ラベル表示名
   sortable: true
   sortname: ダイナミック・フィールド名
<更新対象タブ>
ticket_detail_タイプ名_tab

<更新対象コンポーネント>
ticket_detail_form(チケット詳細)

<変更内容>
以下の書式に従い、フォームのフィールド(fields)に要素を追加する。必須区分や入力チェックなど、必要に応じて「(表)Formのプロパティ(UIバージョン1.1)」に記載のfieldのプロパティが追加可能。
- name: 任意の名前
  source: api
  field:
    read: ticketDetails.Ops I側のフィールド名
    update: patchTicketCustom.Ops I側のフィールド名
  label: ラベル表示名

メモメモ
リクエストアプリケーションの場合、updateプロパティを記載しないでください。
<更新対象タブ>
ticket_detail_タイプ名_tab

<更新対象コンポーネント>
related_records_ticket(関連レコードのチケット一覧)

<変更内容>
以下の書式に従い、テーブルのカラム(columns)に要素を追加する。関連レコードのチケット一覧で、追加したカラムを初期表示させない場合は、hide属性のtrueを追加する。
- name: 任意の名前
  source: api
  column:
    read: ticketRelated.Ops I側のフィールド名
  label: ラベル表示名
※タイプ名はincident、request、task、problem、rfc、release、case、unclassifiedからフィールド追加または削除したタイプを指定します。

UIのYAML定義の詳細については、「UI」を参照してください。

(2)フィールドの削除

①OTOBOのダイナミック・フィールドを無効化する

a. メインメニュー[管理]を選択し、[プロセス & 自動化]-[ダイナミック・フィールド]の一覧から無効化するフィールドを開きます。
b. [有効/無効]を「無効」にします。

②チケット画面のカスタムAPI構成ファイルを編集する

a. JSON Schemaファイル

UI側に渡すフィールドの一覧を定義している「properties」から、①で無効化したフィールドの部分を削除します。
変更箇所については「(表)編集が必要なJSON Schemaファイル」を参照してください。

b. JavaScriptファイル

カスタムAPIを整形している変更箇所から、①で無効化したフィールドの部分を削除します。
変更箇所については「(表)編集が必要なJavaScriptファイル」を参照してください。

c. UIのYAMLファイル

Formコンポーネント内の変更箇所から、①で無効化したフィールドの部分を削除します。
変更箇所については「(表)編集が必要なUIのYAMLファイルと編集内容」を参照してください。

d. フィルタ機能の関連ファイル

フィルタ機能の変更箇所から、①で無効化したフィールドの部分を削除します。
変更箇所については「フィルタへの反映」を参照してください。

(3)フィルタへの反映

チケットブラウザー画面のフィルタ機能を使用する場合は、「フィールドの追加」のファイルに加えて、下記ファイルの修正が必要になります。

a. JSON Schemaファイル

  • apps/datamodel/detamodels_for_ticket_detail_ui/filter-form-schema.json
<変更箇所>
  • 第1階層のproperties
<変更内容>

JSON Schemaファイル」でticket-search-response.jsonに追加したOps I側のフィールド名と設定値(type、format、enum、default、formControl)を追加してください。

<変更箇所>
  • filterItemsAgentENとfilterItemsAgentJA内のenum
    (タスクアプリケーションの全チケットタイプ用の一覧画面に追加する場合)
  • filterItemsAgentタイプ名ENとfilterItemsAgentタイプ名JA内のenum
    (タスクアプリケーションの個々のチケットタイプ用の一覧画面に追加する場合)
  • filterItemsRequesterENとfilterItemsRequesterJA内のenum
    (リクエストアプリケーションの全チケットタイプ用の一覧画面に追加する場合)
  • filterItemsRequesterタイプ名ENとfilterItemsRequesterタイプ名JA内のenum
    (リクエストアプリケーションの個々のチケットタイプ用の一覧画面に追加する場合)
※タイプ名はIncident、Request、Task、Problem、RFC、Release、Case、Unclassifiedから表示したいチケットタイプを選択してください。

<変更内容>

フィルタ項目の英語での表示名をfilterItemsxxxEN、日本語での表示名をfilterItemsxxxJAに追加してください。

b. JavaScriptファイル

  • apps/script/ticket-common/ticket_field_definition.js
<変更箇所>
  • TICKET_FILTER_MAPPING

<変更内容>

JSON Schemaファイル」でfilterItemsに追加した表示名がどのダイナミック・フィールドに対応するかを以下の形式で記載してください。
JSON Schemaファイル」で日本語と英語の表示名両方を追加した場合はそれぞれ記載してください。

filterItemsの表示名: ダイナミック・フィールド名



c. UIのYAMLファイル

  • apps/ui/ticket_browser_agent/manifest.yaml
  • apps/ui/ticket_browser_requester/manifest.yaml
<更新対象タブ>
  • ticket_filter_tab
    (全チケットタイプ用の一覧画面に追加する場合)
  • ticket_filter_タイプ名_tab
    (個々のチケットタイプ用の一覧画面に追加する場合)
※タイプ名はincident、request、task、problem、rfc、release、case、unclassifiedから表示したいチケットタイプを選択してください。

<更新対象コンポーネント>
  • ticket_filter_form
<変更内容>

以下の書式に従い、フォームのフィールド(fields)に要素を追加してください。

- name: ダイナミック・フィールド名
  source: schema
  field:
    all: filter.Ops I側のフィールド名
  label: ラベル表示名
  properties:
    visible: false
    operator: true
    checkbox: true
    xs: 12
    sm: 12
    md: 12
    lg: 12
    xl: 6

ただし、日付タイプ、日時タイプ、number型の本文タイプの場合、xl: 12にしてください。


(4)フィールド名の変更

既存のフィールド名を変更できます。
フィールド名を変更するには、チケットのUIのYAMLファイルのlabel(ラベル表示名)を編集します。編集対象のYAMLファイルは、 「フィールドの追加」の「②c.UIのYAMLファイル」を参照してください。