自動化ルールでは、スマート値を使用して Jira フィールドを表示または操作できます。たとえば、ログ アクションでスマート値 {{issue.description}} を使用する場合は、次のようになります。

• ルール監査ログに課題の説明が次のように表示されているはずです。
  
• しかし、場合によっては、下の例のように、このスマート値 (またはその他のスマート値) が空の値を返すことがあります。
  

このナレッジ記事では、スマート値が空の値を返すシナリオをいくつか紹介し、それぞれの見分け方について説明します。

このリストはすべてを網羅しているわけではなく、今後さらにシナリオが追加される可能性があります。

このページの内容

• 根本原因 1: フィールドが空である
• 根本原因 2: フィールドが非表示に設定されている
• 根本原因 3: 複数のカスタム フィールドの名前が重複している
• 根本原因 4: 「課題のルックアップ」アクションが使用され、サポートされていないフィールドに lookupIssues スマート値経由でアクセスしている
• 根本原因 5: 「課題の削除時」トリガーが使用されており、使用できるフィールドが限定されている
• 根本原因 6: フィールドがサードパーティのアプリ由来であり、スマート値ではサポートされていない
• 根本原因 7: フィールドは元々空で、自動化ルール内で更新された
• 根本原因 8: ルールがアセット フィールドの属性にアクセスしようとしている
• 根本原因 9: ルールがブランチ内で作成された変数にアクセスしようとしている
• 根本原因 10: ルールがスマート値「webhookData.issues」にアクセスしようとしている
• 根本原因 11: ルールがスマート値「webhookResponse.body」または「webhookResponse.body.<key_name>」にアクセスしようとしている
• 根本原因 12: 変数が文字列操作関数で使用され、空白の値として扱われている
• 根本原因 13: issue.id スマート値が文字列操作関数で使用されている
• 根本原因 14: スマート値がアクセスするカスタム フィールドが英語以外の言語に翻訳されている
• 根本原因 15: 「課題の編集」アクションで「設定するフィールドを選択...」オプションとリスト タイプのフィールドとともにスマート値が使用されている

Environment requirements

Jira Data Center 10.0 以降、Jira Data Center (Software と Service Management の両方) の一部として Jira 自動化 (以前の Automation for Jira) を統合しました。これは、Jira または Universal Plugin Manager (UPM) 経由で便利にアップグレードできます。Jira 自動化のエクスペリエンスを最適化かつ強化するため、Jira 10.0 からは Jira 自動化をバンドル バージョンとしてのみ提供することにしました。

This guide assumes that you're using:

• Jira Data Center 8.0.0 or later
• Jira automation Data Center 7.4.0 or later

根本原因 1: フィールドが空である

フィールドが空の場合は、スマート値は空の値を返します。

たとえば、ルール監査ログに [説明] フィールドをログとして記録しようとしているとします。このフィールドが空の場合、監査ログにデータは表示されません。

根本原因 2: フィールドが非表示に設定されている

フィールド設定を特定の課題タイプに関連付けることによって、課題タイプに応じて動作や Jira 課題フィールドを変更できます。フィールドが特定の課題タイプで非表示に設定されている場合、自動化ルールはそのフィールドにアクセスできません。その結果、フィールドが空でなくても、このフィールドへのアクセスに使用されたスマート値は空の値を返します。

プロジェクトの特定の課題タイプに対してフィールドが設定され、非表示になっているかどうかを確認するには、次の手順を実行します。

1. プロジェクト管理ウィンドウで、[プロジェクト設定] > [フィールド] に移動します。
2. [フィールド設定] の横でフィールドを検索します。

[表示] というリンクがこのフィールドの横に表示されている場合は、このフィールドが非表示に設定されていることを意味します。下の例では、[ラベル] フィールドが非表示に設定されていることがわかります。

一部のフィールドは、非表示に設定されていると、予期しない動作をすることがあります。たとえば、[リンクされた課題] フィールドが非表示に設定されている場合、非表示になるべきであり、自動化ルールではアクセスできないにもかかわらず、このフィールドは引き続き [課題を表示] 画面に表示されます。このため、[課題を表示] 画面にフィールドが表示されているからといって、必ずしもそのフィールドが非表示に設定されていないわけではありません。フィールドが非表示になっているかどうかを確認するには、[フィールド設定] ページでご確認ください。詳細については、「「課題リンクを削除」アクションでリンクが削除されない」をご確認ください。

Jira フィールド値を操作または記録するときは、正確な構文を使用してください。構文の間違い (大文字と小文字の間違いなど) や、使用するカスタム フィールド ID に誤りがある場合、スマート値は空の値を返します。

例 1: Jira システム フィールド

Jira システム フィールドの一部にアクセスするための正しい構文は次のとおりです。

{{issue.key}}
{{issue.description}}
{{issue.url}}
{{issue.summary}}
{{issue.assignee.displayName}}
{{issue.reporter.displayName}}
{{issue.status.name}}
{{issue.issuetype.name}}
{{issue.resolution.name}}
{{issue.fixVersions.name}}
{{issue.created}}
{{issue.updated}}
{{issue.project.name}}

issuetype フィールドや fixVersions フィールドは、大文字と小文字を区別します。

• issuetype の代わりに issueType を使用すると、スマート値は空の値を返します
• fixVersions の代わりに fixversions を使用すると、スマート値は空の値を返します

例 2: カスタム フィールド

カスタム フィールドには、フィールド名または「customField_XXXXX」(XXXXX はフィールドの ID で、カスタム フィールドを設定する際に URL から取得可能) という構文を使用してアクセスできます。たとえば、カスタム フィールドの ID が 10500 であるが、ID が 10700 のフィールドがないとします。この場合、次のようになります。

• 次のスマート値はフィールドの内容を返します。

  {{issue.customField_10500}}

• 次のスマート値は空の値を返します。

  {{issue.customField_10700}}

根本原因 3: 複数のカスタム フィールドの名前が重複している

同じ名前のフィールドが複数ある場合、スマート値 {{issue.<field_name>}} はどのフィールド値を返すべきかを特定できないため、空の値を返します。

例として、[ストーリー ポイント] フィールドを見てみましょう。

• Jira では、管理者は名前が重複するフィールドを作成できます。一方のフィールドはカスタム テキスト フィールドであり、もう一方のフィールドは元の [ストーリー ポイント] フィールドで、フィールドのタイプは数値です。
  

• このような状況では、以下の構文を使用して [ストーリー ポイント] フィールドの内容を記録するように自動化ルールが設定されている場合、2 つの [ストーリー ポイント] フィールドのどちらが「正しい」フィールドかを識別できないため、このルールは空の値を記録します。

  {{issue.Story Points}}

  

提案: このような状況では、次のようにすることをお勧めします。

• 重複するフィールド (上の例ではカスタムの [ストーリー ポイント] フィールド) の名前を別の一意の名前に変更します。
• もう 1 つのオプションは、以下の構文でカスタム フィールド ID を使用して、正しいカスタム フィールドにアクセスする方法です (XXXXX をフィールド ID に置き換えます)。ただし、lookupIssues スマート値では customField_XXXXX 構文がサポートされていないため、この回避策は機能しません。
  

根本原因 4: 「課題のルックアップ」アクションが使用され、サポートされていないフィールドに lookupIssues スマート値経由でアクセスしている

lookupIssues でサポートされているフィールドのリストは限られています。たとえば、このアクションはカスタム フィールド、ラベル、コンポーネントをサポートしていません。

その結果、Jira 課題にコンポーネント フィールドなどのサポートされていないフィールドの値が含まれている場合でも、次のようになります。

• 以下の構文では空の値が返されます。

  {{lookupIssues.components}}

• しかし、以下の構文では値が返されます。

  {{issues.components}}

「lookupIssues」アクションでより多くのフィールドをサポートするためのオープンな機能リクエストがあります。 JIRAAUTOSERVER-877 - Lookup issue action - Add support for more fields Gathering Interest

根本原因 5: 「課題の削除時」トリガーが使用されており、使用できるフィールドが限定されている

「課題の削除時」トリガーを使用する際に、すべての Jira フィールドがスマート値を通じて利用できるわけではありません。

スマート値ではアクセスできないフィールドの例を以下に示します (リストは完全ではない場合があります)。

• 任意のバージョン タイプ フィールド (例: 修正バージョン)
• コンポーネント フィールド

その結果、「課題の削除時」トリガーと一緒に次のスマート値のいずれかを使用すると、空の値が返されます。

{{issue.components.name}}
{{issue.fixVersions.name}}

この制限は、次のオープンな機能リクエストで追跡されます。 JIRAAUTOSERVER-961 - Not all Jira fields are available via smart values when using the "Issue Deleted" trigger. Gathering Interest

根本原因 6: フィールドがサードパーティのアプリ由来であり、スマート値ではサポートされていない

サードパーティのアプリからのフィールドのうち、スマート値がサポートされていないタイプもあります。たとえば、ScriptRunner アプリのスクリプト フィールドはスマート値ではアクセスできず、これらのフィールドは空の値を返します。

ScriptRunner のスクリプト フィールドのサポートを追加するためのオープンな機能リクエストがあります。 JIRAAUTOSERVER-620 - Add support for ScriptRunner Script Fields to be detected via Smart Values Gathering Interest

根本原因 7: フィールドは元々空で、自動化ルール内で更新された

自動化ルールがトリガーされ、ルールによって設定されたフィールドが空の場合、この値にアクセスするスマート値は空になります。この動作が発生するのは、ルールがトリガーされたときにスマート値に課題フィールドの内容が反映されるためです。

すべてのフィールドの最新コンテンツにスマート値経由でアクセスできるようにするには (一部のフィールドがルールによって変更される可能性がある場合)、スマート値を使用する前に「課題データを再取得」アクションを追加します。このアクションにより、Jira 課題のすべてのフィールドが再読み込みされ、ルールにすべての Jira フィールドの最新の値が含まれるようになります。

たとえば、以下のスクリーンショットの自動化ルールを例に挙げてみましょう。

• 自動化ルールがトリガーされた時点では、[説明] フィールドは空です
• [説明] フィールドは自動化ルールによって設定されます
• [説明] フィールドを初めてログに記録すると、ルールに値を追加したにもかかわらず空の値が返されます。
• 2 回目に [説明] フィールドのログを記録すると、空でない値が返されます。これは、「課題データを再取得」アクションを使用したためです。

根本原因 8: ルールがアセット フィールドの属性にアクセスしようとしている

次の例のような構文を使用してフィールド属性にアクセスしようとすると、空の値が返されます。

• 例 1:

  issue.InsightField.<attribute>

• 例 2:

  issue.InsightField.object.<attribute>

この制限は、次のオープンな機能リクエストで追跡されます。 JIRAAUTOSERVER-313 - Support access of all Insight attributes through smart values Gathering Interest

根本原因 9: ルールがブランチ内で作成された変数にアクセスしようとしている

ルールのブランチ内で作成された変数は、ブランチ外ではアクセスできません。その結果、スマート値を介してブランチ外のこの変数にアクセスを試みた場合、スマート値は空の値を返します。

この制限は、次のオープンな機能リクエストで追跡されます。 JIRAAUTOSERVER-985 - Automation: Ability to use variable outside of a block - variable is not updated on main branch if created inside an if/else or branch block Gathering Interest

根本原因 10: ルールがスマート値「webhookData.issues」にアクセスしようとしている

Automation for Jira で受信 Webhook データを処理する際に、webhookData スマート値を使用して受信 Webhook ペイロードの情報を取得できます。

Webhook ペイロードにパラメーターとして issues が含まれている場合、このパラメーターの内容は {{webhookData}} スマート値から削除され、代わりに {{issues}} スマート値に移動します。

その結果、以下の式は常に空の出力を返します。

{{webhookData.issues}}

{
  "issues": [
    "GRD-4000"
  ],
  "data": {"releaseVersion":"5.3.2"}
}

根本原因 11: ルールがスマート値「webhookResponse.body」または「webhookResponse.body.<key_name>」にアクセスしようとしている

Web リクエストを送信アクションを使用すると、次のスマート値を使用して Webhook 応答データにアクセスできます。

{{webhookResponse.body}}

自動化ルールでこのスマート値を使用すると値が空になる理由にはさまざまなものが考えられます。理由の一覧については、「Automation for Jira: webhookResponse スマート値を使用すると空の値が返される」をご覧ください。

根本原因 12: 変数が文字列操作関数で使用され、空白の値として扱われている

Jira 自動化 9.0 では、「変数の作成」という名前の新しいアクションを実装しました。このアクションにより、スマート値の内容を変数内に保存できます。変数は、ブランチ内を含め、ルールの全範囲で使用できます。 

変数が文字列操作関数 (concat()、replace()、replaceAll() など) の内部で使用される場合、その変数は空白として扱われます (この変数がテキスト フィールドの値を含むように作成されたとしても)。この問題については、「文字列操作関数で変数を使用すると正しく動作しない」をご参照ください。

たとえば、ルールが以下のように構成されているとしましょう。

• 以下のスマート値を使用して課題の要約を含むように設定された variableContainingSummary という名前の変数を作成する。

  {{issue.summary}}

• ログ アクションで以下の構文を使用して変数を記録する。これは空白の出力を返します。

  {{issue.key.concat(variableContainingSummary)}}

  

変数を文字列操作関数内で使用するには、変数名の末尾に .trim() を追加します。これにより、変数が空白ではなく文字列として扱われます。構文を以下のように変更すると、concat 関数で変数を適切に使用できるようになります。

{{issue.key.concat(variableContainingSummary.trim())}}

根本原因 13: issue.id スマート値が文字列操作関数で使用されている

文字列操作関数で {{issue.id}} スマート値 ({{issue.summary}}、{{issue.description}} などの他の課題スマート値ではなく) を使用すると、空白の出力になります。

ログ アクションに以下のテキストを追加すると、このアクションは空白の出力を返します。

Issue Summary-ID: {{issue.summary.concat("-").concat(issue.id)}}

代わりに、以下の 2 つのアクションを含むルールを構成することをお勧めします。

• 変数の作成アクションを使用して issue.id スマート値を変数内に保存します (ここでは、この変数を variableContainingIssueId と呼びます)。

  {{issue.id}}

• 文字列操作関数で課題 ID にアクセスするには、変数の後に .trim() を使用します。

  Issue Summary-ID: {{issue.summary.concat("-").concat(variableContainingIssueId.trim())}}

文字列操作関数で課題 ID を使用するルールのユースケースについては、「添付ファイルのカスタマー向け URL を含むメールを送信するルールの作成方法」を参照してください。

根本原因 14: スマート値がアクセスするカスタム フィールドが英語以外の言語に翻訳されている

カスタム フィールドが他の言語に翻訳されている場合、ルール アクターのプロファイルが英語以外の言語を使用するように設定されていれば、このフィールドを参照するすべてのスマート値は空の値を返します。

たとえば、次のように仮定しましょう。

• ストーリー ポイントのカスタム フィールドがドイツ語に翻訳されるように構成されている。
• ルール実行者のプロファイル設定がドイツ語で構成されている。

• 以下のスマート値を介してストーリー ポイントのカスタム フィールドにアクセスするようにルールが構成されている。

  {{issue.Story Points}}
  {{triggerIssue.Story Points}}
  {{lookupIssues.Story Points}}

この場合、これらのスマート値はすべて空の値を返します。このようなことが起こらないように、ルール実行者を、英語知識を有するプロファイルのユーザーに変更することをお勧めします。この動作は、次のチケットでバグとして報告されました。 JIRAAUTOSERVER-1025 - If a custom field is translated to a language other than English, smart values that refer to this field might return an empty value Closed 。

根本原因 15: 「課題の編集」アクションで「設定するフィールドを選択...」オプションとリスト タイプのフィールドとともにスマート値が使用されている

[コンポーネント] フィールドなどのリスト タイプのフィールドが [設定するフィールドを選択...] オプションで設定されている場合、トリガー課題のコンポーネントに複数の値があると、以下の構文は空の値をコピーします。

{{#triggerIssue.components}}{{name}}{{/}}

この問題は、スマート値が「設定するフィールドを選択...」オプションでコンポーネント名のリストではなく文字列として扱われるために発生します。その結果、コンポーネントに複数の値が含まれている場合、コンポーネント名のリストは文字列に変換され、ルールは文字列値を [コンポーネント] フィールドにコピーしようとしますが、これは成功しません。その結果、[コンポーネント] フィールドは空の値に設定されます。この動作は、バグ JIRAAUTOSERVER-1072 - Unexpected behavior for "Edit issue" action with List fields depending on number of elements Gathering Impact で追跡されています。

[コンポーネント] フィールド (またはその他のリスト タイプのフィールド) が正しくコピーされるようにするには、スマート値を使用する代わりに、「値をコピーする課題」オプションを「トリガー課題」とともに使用します。