ルールおよびルールの評価

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

ルールは、作業項目フィールドへの値の割り当てを設定する、または制限するために使用されます。 ルールには、大きく分けて、自動生成されたルールと、プロセスまたはプロジェクトに対して定義されたカスタム ルールの 2 種類があります。 自動生成されたルールにより、標準的な方法で動作するエリアに対してカスタム ルールを追加する必要を最小限に抑えられます。

カスタム ルールは、ビジネス ユース ケースをサポートするために定義します。 フィールドのデータ型に応じて、どのようなデータを入力できるかについてさまざまな制約を設定できます。 選択リスト (ドロップダウン メニュー) の値の指定、既定値の設定、エントリの消去、または変更の制限が可能です。 条件付きルールでは、異なるフィールド値の間の依存関係に基づいてルールを適用できます。 また、フィールドを変更できるユーザーを制限したり、あるグループにのみ規則を適用するようスコープを指定したりすることができます。

この記事を読んで、次の内容を理解してください。

• システムが自動生成されたルールを適用する方法
• システム フィールドのカスタム 規則の定義に適用される制限事項
• 適用できるさまざまな種類のカスタム 規則
• ルールの評価方法
• 継承プロセスに対して定義された規則とオンプレミスの XML プロセスの違い
• 定義するカスタム ルールの数を最小限に抑える必要がある理由

カスタム ルールを定義する前に、「 構成と Azure Boards のカスタマイズ」を読んで ビジネス ニーズに合わせて Azure Boards をカスタマイズする方法について幅広く理解してください。

ヒント

WIT に対して定義する規則の数を最小限に抑えます。 1 つの WIT に対し複数のルールを作成できますが、ルールの追加は、ユーザーが作業項目を追加したり変更するときにパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存すると、その作業項目の種類のフィールドに関連付けられているすべてのルールが検証されます。 特定の条件下では、ルールの検証式が複雑になり SQL で評価できません。

自動生成されたルール

自動生成されたルールにより、標準的な方法で動作するエリアに対してカスタム ルールを追加する必要を最小限に抑えられます。

状態遷移ルール

継承されたプロセスは、ワークフローに追加されたカスタム作業項目の種類とカスタム状態ごとに、任意の状態遷移ルールのセット全体を動的に生成します。 任意の状態から任意の状態への移行が有効です。

オンプレミスの XML プロセスの場合は、作業項目タイプ定義の WORKFLOW セクション内で有効な遷移を指定する必要があります。

状態遷移と By/Date フィールド ルール

By/Date フィールドは、 Created By/Date、 Activated By/Date、 Resolved By/Date、および Closed By/Date に対応します。

継承されたプロセスの場合、作業項目をある状態から別の状態に切り替えると、これらのフィールドは自動的に設定またはクリアされます。 [変更日時] フィールドは、作業項目の保存ごとに更新され、状態遷移とは無関係であるため、含まれません。

これらのフィールドを管理する既定のルールと動作は次のとおりです。

1. Closed状態は常に Completed 状態カテゴリに含まれます。
2. Completed状態カテゴリは構成できません。1 つと 1 つの State にのみ関連付けられています。
3. この Closed 状態は、アジャイルプロセスとCMMIプロセスでは常に Closed 、スクラムプロセスと Basic プロセスでは常に Done です。
4. これらのルールの自動生成は、ローカライズされた状態名がルール条件に含まれるため、ロケールの影響を受けます。 ロケールごとに異なるルールが生成されます。
5. これらのフィールドの自動生成ルールは、これらのフィールドを含む作業項目の種類にのみ指定されます。 作業項目の種類にこれらのフィールドを 1 つ以上含めないようにすることができます。
6. これらのルールは、作業項目の種類にカスタム状態がある場合、または作業項目の種類がカスタム作業項目の種類である場合に必要です。
7. これらの規則は、継承されたプロセスにのみ適用されます。ホストされた XML またはオンプレミスの XML プロセスに対して生成されることはありません。

ワークフローの状態は、ボード上のワークフローをサポートするために状態カテゴリに関連付けられます。 詳しくは、バックログとボードでワークフローの状態と状態カテゴリを使用する方法に関する記事をご覧ください。

状態変更日フィールド ルール

これらのルールは、特定の状態に依存しないため、技術的にはクローズ日/終了日ルールよりもはるかに簡単です。 どの作業項目の種類でも、同じルールが常に機能します。 一部の OOB 作業項目の種類には [状態の変更日] フィールドが含まれていないため、自動生成する必要があります。そのため、ユーザーがこのフィールドをカスタム作業項目の種類に追加する場合は、これらのルールも自動生成する必要があります。 この場合も、クローズ日/クローズ日ルールと同じ原則が適用されます。

カスタム規則

すべてのカスタム 規則は省略可能です。 継承されたプロセスの場合は、条件とアクションで構成されるルールを指定します。 オンプレミスの XML プロセスの場合は、フィールドまたはワークフロー内のルールを指定します。

2 つのプロセス間に 1 対 1 のマッピングはありません。 場合によっては、XML 要素ルールは、継承されたプロセスの Edit フィールド ダイアログ内で定義され、ルールとして定義されません。 FROZEN、MATCH、NOTSAMEASなどの他の XML 要素は、継承されたプロセスではサポートされていません。

次の点に注意してください。

• ルールは、フォームを操作する場合だけでなく、他のツールを介してやり取りする場合にも、常に適用されます。 たとえば、フィールドを読み取り専用として設定すると、作業項目フォームにルールが適用されるだけでなく、API と Excel Azure DevOps Server アドインを使用して適用されます。
• 継承されたプロセス エントリは、完全なルールを作成するための条件とアクションを指定します。 XML 要素では、これらの区別は行われません。
• フィールド ルールでは、他の 2 つのフィールドの合計である値の割り当てや、他の数学的計算の実行はサポートされていません。 ただし、 TFS アグリゲーター (Web サービス) Marketplace 拡張機能を使用して、ニーズに合ったソリューションを見つけることができます。 「 作業およびその他のフィールドの登録」も参照してください。
• Work アイテム フォーム コントロール ライブラリ拡張機能など、Marketplace 拡張機能を使用してフィールドにカスタム ルールを適用するためのその他の解決策。

ルールの構成

継承プロセス

継承されたプロセスの場合、各ルールは条件とアクションの 2 つの部分で構成されます。 条件は、ルールを適用するために満たす必要がある状況を定義します。 アクションは、実行する操作を定義します。 ほとんどのルールでは、ルールごとに最大 2 つの条件と 10 個のアクションを指定できます。 すべてのカスタム ルールを実行するには、すべての条件が満たされている必要があります。

たとえば、状態に割り当てられた値と別のフィールドに基づいてフィールドを必須にすることができます。 次に例を示します。

   (Condition) When a work item State isActive
   (Condition) And when the value ofValue Area = 事
   (Action) Then make requiredストーリー ポイント

Note

現在、状態遷移ルールでは 1 つの条件のみがサポートされています。 State に基づいてルールを適用する場合は、「ワークフローの状態にルールを適用するを参照してください。

次の表に、選択した条件で使用できるアクションの概要を示します。

Condition

サポートされているアクション

フィールド値を設定するか、必須または読み取り専用にする

状態に基づいて遷移を制限する

ユーザーまたはグループメンバーシップに基づいて、フィールド属性を設定するか、状態遷移を制限します

オンプレミスの XML プロセス

オンプレミスの XML プロセスでは、XML 要素を使用してルールを定義します。 これらのルール要素はすべて、作業項目タイプ定義の FIELD 定義内で定義できます。 また、 HELPTEXT 要素を除き、ワークフロー遷移中に、または FIELD (グローバル ワークフロー) 要素内の子要素として影響を受ける規則を指定できます。

Note

VALIDUSER要素は、TFS 2018 以降のバージョンではサポートされていません。

フィールド ルールを適用する場所

作業項目の有効期間を通してフィールドにルールを適用する場合は、 FIELD セクション内で指定します。 たとえば、新しくアクティブなバグに必要なフィールドは、バグが閉じられるまで必須のままです。 それ以外の場合は、状態、理由、または遷移の変更に基づいて適用する場合は、 WORKFLOW セクション内で指定します。

State (System.State) フィールドと Reason (System.Reason) フィールドは、 WORKFLOW セクション内で定義されます。 ほとんどのフィールド ルールは、状態の変更、理由の選択、または特定の切り替え時にフィールドに適用するように指定できます。 詳細については、「 作業項目の種類のワークフローを変更するを参照してください。

それ以外の場合は、状態の変更中にのみ評価されるルールを指定します。 これらの規則は、STATE、REASON、またはTRANSITION要素の下の WORKFLOW セクション内で定義されます。 HELPTEXTを除くすべてのルールは、FIELD (Workflow) 要素内で適用できます。

フィールド ルールは加法です。 つまり、ルール エンジンによってすべて評価される同じフィールドに対して 4 つのルール セットを指定できます。

• 作業項目の種類固有 ルールは、その状態モデル内の作業項目の場所に関係なく適用されます。 たとえば、 <REQUIRED \> ルールでは、次のチェックが実行されます。

  "MyField Value" != NULL

• 状態固有 ルールは、特定の状態にある場合、作業項目インスタンスにスコープが設定されます。 次の条件に該当する場合、状態固有のルールが適用されます。

  State field value == "MyState" && "MyField Value" != NULL

• 特定の遷移に対して指定する遷移固有 ルールは、特定の遷移が行われる作業項目にスコープが設定されます。 これらの規則は、次の条件に該当する場合に適用されます。

  State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL

• 特定の理由に対して指定する理由固有 ルールは、特定の遷移の特定の理由にスコープが設定されます。 これらは、次の条件に該当する場合に処理されます。

  Reason field == "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

次の例では、作業項目がアクティブな状態にある場合に、顧客の重大度フィールドの変更を制限します。

<STATE name="Active">
      <FIELDS>
      <FIELD refname="MyCorp.Severity" >
         <READONLY />
      </FIELD>
      </FIELDS>
</STATE>

定義されているルールが多すぎるとどうなりますか

プロジェクトごとに 1 つの SQL 式が定義され、作業項目が作成または更新されるたびに検証されます。 この式は、プロジェクトに定義されているすべての作業項目の種類に対して指定するルールの数に合わせて増加します。 フィールドに対して指定された動作修飾子ごとに、サブ式の数が増加します。 入れ子になったルール (遷移にのみ適用されるルール、または他のフィールドの値に基づいて条件付けされるルール) により、 IF ステートメントに条件が追加されます。 式が特定のサイズまたは複雑さに達すると、SQL ではそれ以上評価できないため、エラーが発生します。 一部の WIT を削除するか、一部のルールを削除すると、エラーが解決される可能性があります。

選択リスト (ドロップダウン メニュー) の値の指定、既定値の設定、エントリの消去、または変更の制限が可能です。 条件付きルールでは、異なるフィールド値の間の依存関係に基づいてルールを適用できます。 また、フィールドを変更できるユーザーを制限したり、あるグループにのみ規則を適用するようスコープを指定したりすることができます。

作業項目ルールは、1 つのコレクションとして存在しません。 ルールは実際には動的に生成され、異なるデータ ソースからマージされます。 マージ ロジックは単純なロジックであり、同じルールを統合しますが、競合するルールはトリミングしません。

バイパス ルール

一般に、ユーザーが作業項目を変更すると、すべての作業項目がルール エンジンによって検証されます。 ただし、特定のシナリオをサポートするために、作業項目の更新に対して Bypass ルールを割り当てたユーザーは プロジェクト レベルのアクセス許可によって、ルールが評価されずに作業項目を保存できます。

ルールは、2 つの方法のいずれかでバイパスできます。 1 つ目は、 Work Items - update REST API bypassRules パラメーターを true に設定することです。 2 つ目は、バイパス モード (WorkItemStoreFlags.BypassRules を使用してWorkItemStoreを初期化) で初期化することで、クライアント オブジェクト モデルを使用することです。

システム フィールドとユーザー設定ルール

システム フィールドには System. があります名前 参照名 (例: System.Title および System.State。

Area ID、Changed Date、Created Date、Created By、State、Reason の各システム フィールドが必要です。

ルール エンジンは、次を除き、設定条件またはアクションをシステム フィールドに制限します。

• State フィールドと Reason フィールドは読み取り専用にすることができます。
• ほとんどのルールは、 Title、 Assigned To、 Description、および Changed By フィールドに適用できます。

継承プロセスのルール ユーザー インターフェイスのドロップダウン メニューにフィールドが表示されない場合は、これが理由です。 たとえば、条件に基づいて Area Path (System.AreaPath) を読み取り専用にしようとすると、[エリア パス] フィールドは選択できません。 システム フィールドを指定できる場合でも、ルール エンジンによってルールの保存が制限される場合があります。

既定の規則とコピー規則

既定のルールとコピー ルールは、作業項目フィールドの値を変更します。 既定値の指定、フィールドのクリア、フィールドの定義の要求など、実行時の動作と制約を定義します。

ユーザーまたはグループ メンバーシップ規則の制限で説明されているように、現在のユーザーのグループ メンバーシップに基づいて、これらの規則の適用を制限できます。

継承プロセス

これらのルール アクションのほとんどは、任意の条件を選択して適用できます。

継承されたプロセス アクション

説明

Copy the value from...

現在のフィールドにコピーする値を含む別のフィールドを指定します。

Clear the value of...

含まれる任意の値のフィールドをクリアします。

Use the current time to set the value of ...

現在のユーザーの時刻設定に基づいて、フィールドの時刻を設定します。

オンプレミスの XML プロセス

これらのルールでは、既定値の設定、1 つのフィールドから別のフィールドへの値のコピー、または指定されたパターンに一致するようにフィールド値の適用がサポートされます。 構文の構造と例については、「 既定値を定義するか、フィールドに値をコピーするを参照してください。

XML 要素

使用方法

COPY

ユーザーが作業項目を作成または変更するときに、指定した値をフィールドにコピーします。

<FIELD refname="MyCorp.Status" name="Status" type="String">  
   <COPY from="value" value=" " />  
</FIELD> 

DEFAULT

ユーザーが作業項目を作成または変更するときに空のフィールドの値を指定します。 フィールドに既に値がある場合、 DEFAULT ルールは無視されます。 既定のルールは、フィールドの Is 値が現在空の場合にのみ実行されます。 サポートされる値には、現在の時刻 (from = "clock")、現在のユーザー (from = "currentuser")、リテラル値 (from = "value" value = "literal")、または別のフィールド (from = field field = "referenceNameField") の値が含まれます。

<FIELD refname="MyCorp.Priority" name="Priority" type="String" 
<HELPTEXT>Specify the severity of the problem</HELPTEXT 
   <ALLOWEDVALUES 
      <LISTITEM value="P1"/ 
      <LISTITEM value="P2"/ 
      <LISTITEM value="P3"/ 
   </ALLOWEDVALUES 
<DEFAULT from="value" value="P3"/ 
</FIELD 

SERVERDEFAULT

フィールド値を定義するサーバー クロックまたは現在のユーザーを指定します。

<TRANSITION from="New" to="Active">  
   <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.StartWork" />  
   </ACTIONS>  
   <REASONS>  
      <DEFAULTREASON value="Work started" />  
   </REASONS>  
   <FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
            <COPY from="currentuser" />  
            <VALIDUSER />  
            <REQUIRED />  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
         <SERVERDEFAULT from="clock" />  
      </FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser" />  
      </FIELD>  
   </FIELDS>  
</TRANSITION>  

制約規則

制約ルールでは、フィールドの値の変更が制限されます。 作業項目の有効な状態を定義します。 各制約は 1 つのフィールドで動作します。 制約は、作業項目の保存時にサーバーで評価され、制約に違反した場合、保存操作は拒否されます。

ユーザーまたはグループ メンバーシップ規則の制限で説明されているように、現在のユーザーのグループ メンバーシップに基づいて、これらの規則の適用を制限できます。

継承プロセス

これらのルール アクションのほとんどは、任意の条件を選択して適用できます。

継承されたプロセス アクション

説明

Hide the field...
グループ メンバーシップ条件が選択されている場合にのみ使用できます。

作業項目フォームにフィールドを表示しないように指定し、基本的に現在のユーザーがフィールドの値を変更する機能を削除します。

Make read-only

フィールドが変更されないようにします。 特定の条件下でこのルールを適用できます。 たとえば、作業項目を閉じた後、レポートのためにデータを保持するためにフィールドを読み取り専用にする必要があります。
フィールドの既定値を読み取り専用に指定するには、[フィールドの編集] ダイアログで [オプション タブ指定します。

Make required

ユーザーがフィールドの値を指定する必要があります。 ユーザーは、すべての必須フィールドに値を割り当てるまで、作業項目を保存できません。
フィールドの既定値を指定するには、[フィールドの編集] ダイアログで [オプション タブ指定します。

オンプレミスの XML プロセス

XML 要素

使用方法

ALLOWEDVALUES

フィールドに使用できる値の一覧を定義します。 使用できる値は、作業項目フォームおよびクエリ ビルダーのフィールド リストで選択できる値です。 これらの値の 1 つから選択する必要があります。

CANNOTLOSEVALUE

値が指定されると、ユーザーが値のフィールドをクリアできないようにします。 この要素は現在のフィールド値を保持し、クリアしたり空にしたりすることはできません。

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <CANNOTLOSEVALUE /> 
</FIELD> 

FROZEN

フィールドに値が含まれると、ユーザーがフィールドの値を変更できないようにします。 ユーザーがそのフィールドの値を持つ作業項目を保存するとすぐに、値を変更できなくなります。 変更がコミットされた後は、固定フィールドを空以外の値に変更することはできません。 ただし、フィールドを手動でクリアし、作業項目を保存してから、別の値を指定することができます。

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <FROZEN not="[Project]\Management Team" /> 
</FIELD> 

EMPTY

含まれる任意の値のフィールドをクリアし、ユーザーが作業項目を保存するときにフィールドを読み取り専用にします。 READONLYでEMPTYを使用しないでください。
EMPTY は、主に状態遷移 保証するために使用されます 項目の遷移先の状態に適用されるフィールドをクリアします。

<FIELD refname="MyCorp.SubStatus" />  
   <WHEN field="MyCorp.Status" value="Approve" >  
     <EMPTY />
   </WHEN>  
</FIELD>  

MATCH

文字列フィールドに対して作成されたエントリが、文字または数字の 指定されたパターンに準拠するように強制します。 複数の MATCH 要素を定義した場合、指定したパターンのいずれかに一致する値は有効と見なされます。 少なくとも 1 つの要素が成功した場合、フィールドには有効な値があります。

<FIELD refname="MyCorp.GitHubURL" name="GitHub URL" type="String">  
   <MATCH pattern="https:\/\/github\.com\/\S+[\.md|\.yml]$"/>  
</FIELD>

NOTSAMEAS

フィールドに別のフィールドに割り当てられた値と同じ値が割り当てられないようにします。

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <NOTSAMEAS field="MyCorp.SubStatus" /> 
</FIELD> 

PROHIBITEDVALUES

フィールドの禁止値の一覧を定義します。 複数の ALLOWEDVALUES ルールや PROHIBITEDVALUES ルールが特定のフィールドに適用される場合、有効な値の完全なリストは、すべての許可値リストの積集合になります。または、許可された値リストがない場合は、すべて (つまり、差を設定する) すべての禁止値リストの和集合になります。

READONLY

フィールドが変更されないようにします。 特定の条件下でこのルールを適用できます。 たとえば、作業項目を閉じた後、レポートのためにデータを保持するためにフィールドを読み取り専用にする必要があります。
EMPTYはフィールドを読み取り専用にするため、EMPTY要素でREADONLYを使用しないでください。 これらの要素を組み合わせると、一貫性のない結果が得られる場合があります。
また、 Control 要素 ReadOnly 属性を使用して、作業項目フォームからフィールドを読み取り専用として表示することもできます。 このフィールドは他のクライアントが書き込むことができますが、作業項目フォームを介して書き込む必要はありません。

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <READONLY />  
</FIELD> 

REQUIRED

ユーザーがフィールドの値を指定する必要があります。 ユーザーは、すべての必須フィールドに値を割り当てるまで、作業項目を保存できません。

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <REQUIRED />  
</FIELD> 

候補リスト

選択リストは、ユーザーが文字列または整数フィールドに対して選択できる値または選択できない値を定義します。 選択リストで定義された値は、作業項目フォームとクエリ エディターに表示されます。

継承プロセス

継承プロセスの場合、選択リストは [フィールドの編集] ダイアログで定義されます。

[フィールドの編集] ダイアログ

説明

選択リスト フィールドの [定義 ] タブ

フィールドに使用できる値の一覧を定義します。 使用できる値は、作業項目フォームおよびクエリ ビルダーのフィールド リストで選択できる値です。 これらの値の 1 つから選択する必要があります。

ユーザーが自分の値を入力するにはOptionsタブ内のチェックボックスをオンにして、ユーザーが自分のエントリを指定できるようにします。

フィールドの推奨値の一覧を定義します。 推奨値は、作業項目フォームおよびクエリ ビルダーのフィールド リストで選択できる値です。 その他の値は、一覧の値に追加で入力できます。

オンプレミスの XML プロセス

次の表に示す XML 要素を使用して、選択リストを定義します。 構文の構造と例については、「 Define pick listsを参照してください。

リストを組み合わせて、リストを展開またはコントラクトすることができます。 また、「 User またはグループ メンバーシップ ルールの制限で説明されているように、現在のユーザーのグループ メンバーシップに基づいて、これらのルールの適用を制限できます。

XML 要素

説明

ALLOWEDVALUES

フィールドに使用できる値の一覧を定義します。 使用できる値は、作業項目フォームおよびクエリ ビルダーのフィールド リストで選択できる値です。 これらの値の 1 つから選択する必要があります。

ALLOWEXISTINGVALUE

既存の値を許可するフィールドを定義します。 この要素を使用すると、既に存在するフィールド値が無効な場合でも使用できます。 すべての新しいフィールド値が有効である必要があります。

PROHIBITEDVALUES

フィールドの禁止値の一覧を定義します。

SUGGESTEDVALUES

フィールドの推奨値の一覧を定義します。 推奨値は、作業項目フォームおよびクエリ ビルダーのフィールド リストで選択できる値です。 その他の値は、一覧の値に追加で入力できます。

ID フィールドと検証エラー

メンバーがチームを離れ、プロジェクトの共同作成者として登録されなくなったときに発生する検証エラーを回避するには、Assigned To フィールドの ALLOWEXISTINGVALUE 要素を含めます。

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
      <HELPTEXT>The user who is working on this work item</HELPTEXT>
      <ALLOWEXISTINGVALUE />
      <VALIDUSER />
      <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
      <LISTITEM value="Active" />
      <LISTITEM value="[project]\Contributors" />
      </ALLOWEDVALUES>
      <DEFAULT from="field" field="System.CreatedBy" />
</FIELD>

条件フィールドの値または変更

条件付きルールでは、特定の値と等しいか等しくないフィールドの値に基づいてアクションを指定するか、特定のフィールドの値に変更が加えられたか、または行われなかったかに基づいてアクションを指定します。 一般に、条件付きルールは無条件ルールよりも最初に適用されます。 複数の条件付きルールが true と評価された場合、実行の順序は When、WhenNot、WhenChanged、WhenNotChanged です。

継承プロセス

フィールドごとに複数の条件付きルールを指定できます。 ただし、条件付きルールごとに指定できる運転フィールドは 1 つだけです。

継承された条件

説明

The value of ... (equals) [When]

別のフィールドに特定の値がある場合に、現在のフィールドに適用する 1 つ以上のルールを指定します。

A change was made to the value of ... [WhenChanged]

特定のフィールドの値が変更されたときに、現在のフィールドに 1 つ以上のルールを適用します。

The value of ... (not equals) [WhenNot]

別のフィールドに特定の値がない場合に、現在のフィールドに 1 つ以上のルールを適用します。

No change was made to the value of ... [WhenNotChanged]

特定のフィールドの値が変更されていない場合に、現在のフィールドに 1 つ以上のルールを適用します。

継承されたアクション

説明

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

特定のフィールドに対して実行するアクションを指定します。

オンプレミスの XML プロセス

次の XML 要素は、他のルールが評価される条件を設定するために使用されます。 フィールドごとに複数の条件付きルールを指定できます。 ただし、条件付きルールごとに指定できる運転フィールドは 1 つだけです。 条件付きルールを入れ子にすることはできません。 各プロセス モデルでサポートされているアクションには、次の表に示すアクションが含まれます。

構文の構造と例については、「 Assign conditional-based values and rulesを参照してください。 ユーザーまたはグループ メンバーシップ規則の制限で説明されているように、現在のユーザーのグループ メンバーシップに基づいて、これらの規則の適用を制限できます。

XML 要素

使用方法

WHEN

別のフィールドに特定の値がある場合に、現在のフィールドに適用する 1 つ以上のルールを指定します。 親要素は、現在のフィールドを定義します。
指定したフィールドに指定した値がある場合、この要素のルールが現在のフィールドに適用されます。

WHENCHANGED

現在のフィールドに 1 つ以上のルールを適用する条件を指定します。 このルールは、作業項目のリビジョンで別のフィールドの値が変更されたときに、現在のフィールドに適用されます。 親要素は、現在のフィールドを定義します。

WHENNOT

現在のフィールドに 1 つ以上のルールを適用する条件を指定します。 ルールは、別のフィールドの値が変更されたときに現在のフィールドに適用されます。 親要素は、現在のフィールドを定義します。
指定したフィールドに指定した値が含まれていない場合、この要素のルールが現在のフィールドに適用されます。

WHENNOTCHANGED

現在のフィールドに 1 つ以上のルールを適用する条件を指定します。 このルールは、作業項目のリビジョンで別のフィールドの値が変更されない場合に、現在のフィールドに適用されます。 親要素は、現在のフィールドを定義します。

ユーザーまたはグループメンバーシップルールの制限

現在のユーザーのメンバーシップに基づいてルールの適用を制限できます。 1 人のユーザーではなく、Azure DevOps セキュリティ グループにルールのスコープを設定することをお勧めしますが、後者は指定できます。 ルールのスコープを複数のグループにするには、使用するグループのセットを含む親 Azure DevOps グループを作成する必要があります。

プロセスの実装

ヒント

ルールの評価の問題が発生する可能性を回避するには、Microsoft Entra ID または Active Directory セキュリティ グループではなく、Azure DevOps セキュリティ グループを指定します。 詳細については、「 Default ルールとルール エンジンを参照してください。

継承プロセス

次の表に示すように、現在のユーザーのメンバーシップに基づいてルールを制限するには、継承されたプロセスに対して 2 つの条件のいずれかを指定します。 これらの規則は、Azure DevOps 2020 以降のバージョンでアクティブです。

適用対象

Rule

状態

Current user is a member of group ...
Current user is not member of group ...

アクション

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

オンプレミスの XML プロセス

現在のユーザーのメンバーシップに基づいてルールを制限するには、rule 要素に for 属性または not 属性を指定します。 ルールのスコープを指定します。 ルールのスコープを複数のグループにするには、使用するグループのセットを含む親 Azure DevOps グループを作成する必要があります。

シナリオ

使用方法

指定したグループに対してのみフィールドを必須にする

forを使用して、グループにルールを適用します。 この例では、ジュニア アナリスト グループのすべてのユーザーが [2 番目の承認者] フィールドに入力する必要があります。

<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>

フィールドの変更をユーザーのグループに制限する

notを使用して、ルールからグループを除外します。 次の使用例は、トリアージ委員会グループのユーザーを除くすべてのユーザーの [トリアージの説明] フィールドを読み取り専用として定義します。

<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>

一部のユーザーに必要なフィールドを作成し、他のユーザーには必須にしない

forとnotの組み合わせを使用して、他のルールではなく一部にルールを同時に適用します。 次の使用例は、[プロジェクト メンバー] グループのユーザーの必須フィールドとして重大度を定義しますが、Project Admins グループのユーザーには定義しません。 ユーザーが両方のグループに含まれている場合は、 for ステートメントが適用され、フィールドが必要になります。

<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>

トークンを使用してユーザーまたはグループを参照する

ID フィールドまたはユーザー 選択フィールドは、ユーザーとグループの両方を参照する値を受け取ることができます。 ルールをグループに制限する場合は、グループのドメインまたはスコープを指定します。 値によっては、トークンを使用できます。

継承プロセス

トークンの例を次に示します。

• [ProjectName]、[Fabrikam]、[FabrikamFiber]、[MyProject] など
• [OrganizationName]、[fabrikam]、[myorganization] など
• [CollectionName]、[fabrikam]、[myorganization] など

プロジェクトまたは組織で使用できるスコープについては、 Project Settings>Permissions>Groups または Organization Settings>Permissions>Groups ページに移動し、必要に応じて一覧をフィルター処理できます。 たとえば、次の図は、 Azure DevOps に基づいてフィルター処理されたリストへの最初の 4 つのエントリを示しています。 詳細については、「 Change プロジェクト レベルのアクセス許可 または Change プロジェクト コレクション レベルのアクセス許可を参照してください。

オンプレミスの XML プロセス

トークンの例を次に示します。

• [Project]\Contributors、[Project]\Fabrikam Team、[Project]\Project Approvers などの [Project]。[Project] トークンは、プロジェクトに対して定義されたグループを指定します。 これは、チーム、既定またはカスタムのセキュリティ グループ、またはプロジェクトに追加された Active Directory グループに対応できます。
• [GLOBAL]、コレクション スコープ のグループを参照する場合は、[GLOBAL]\Project Collection Administrators [GLOBAL] を使用して、コレクションに追加されたプロジェクト コレクション管理者グループや Windows グループなどのコレクション スコープのセキュリティ グループを参照します。 例:

  <FIELD name="Title">
      <READONLY for="[GLOBAL]\Project Collection Valid Users"/>
  </FIELD>
  

• [Team Foundation] サーバー スコープ のグループを参照する場合は、[Team Foundation]\Team Foundation 管理者[Team Foundation] を使用して、組み込みグループやサーバー レベル グループに追加する Windows グループなどのサーバー スコープ グループを参照します。 例:

  <FIELD name="Title">
      <READONLY for="[Team Foundation]\Team Foundation Valid Users"/>
  </FIELD>
  

• [DomainName] サーバー スコープのグループを参照します。たとえば、[Team Foundation]\Team Foundation Administrators ドメイン修飾アカウント名 (次の例に示すような名前) を使用して、ドメイン ユーザーまたはグループを参照できます。 一部のルールでは、グループのみがサポートされ、ドメイン ユーザーの参照はサポートされません。

  <LISTITEM value="FABRIKAM\Christie Church's Direct Reports"/>
  

Note

[Project]、[GLOBAL]、および [Team Foundation] をそのまま使用します。 プロジェクト、コレクション、またはサーバー名の名前に置き換えることはありません。

プロジェクトまたはコレクションで使用できるスコープの詳細については、 Project Settings>Permissions>Groups または Collection Settings>Permissions>Groups ページに移動します。 必要に応じて一覧をフィルター処理します。 たとえば、次の図は、 Azure DevOps に基づいてフィルター処理されたリストへの最初の 4 つのエントリを示しています。 詳細については、「 Change プロジェクト レベルのアクセス許可 または Change プロジェクト コレクション レベルのアクセス許可を参照してください。

すべてのユーザーとグループは、これらのトークンのいずれかで修飾する必要があります。 たとえば、次の XML は、指定されたグループを有効なトークンで修飾しないため、無効です。

<FIELD name="Title">
    <READONLY for="Dev Team"/>
</FIELD>

既定のセキュリティ グループの詳細については、「 Permissions とグループ」を参照してください。

規則の評価

作業項目を変更するユーザーまたはユーザーのグループ メンバーシップに基づいて条件を指定するルールは、2 つの方法のいずれかで評価されます。 ルールが評価されるときに、アプリケーションは、そのユーザーが指定されたグループのメンバーであるかどうかを確認して、ルールが現在のユーザーに適用されるかどうかを判断する必要があります。

• Web ポータル、REST API、または azure boards コマンドから作業項目を変更すると、Microsoft Entra ID または Active Directory への要求が行われます。 この操作に問題はありません。
• WIT クライアント オブジェクト モデルを使用して Visual Studio、Excel、またはその他のカスタム ツールから作業項目を変更する場合、メンバーシップを評価する要求はクライアント キャッシュに基づきます。 クライアント キャッシュは Active Directory グループを認識していません。

Note

GIT を使用するプロジェクト用の Visual Studio 2019 チーム エクスプローラーが、REST API を使用するように書き直されました。

ユーザーがさまざまなクライアントから作業項目を更新する際の問題を回避するには、Active Directory グループではなく Azure DevOps セキュリティ グループを指定します。 Active Directory グループに対応する Azure DevOps セキュリティ グループを簡単に作成できます。 方法については、「 ユーザーまたはグループの追加または削除、セキュリティ グループの管理を参照してください。

Note

WIT クライアント OM は非推奨です。 2020 年 1 月 1 日の時点で、Azure DevOps Services と Azure DevOps Server 2020 に対して作業する場合はサポートされなくなりました。

ルールが評価される順序

ルールは通常、一覧表示される順序で処理されます。 ただし、すべてのルールを評価するための完全なシーケンスは完全に決定論的ではありません。

このセクションでは、条件付き、コピー、および既定のルールを適用するときの予期される動作と相互作用について説明します。

継承プロセス

次の手順は、Azure DevOps が実行する対話と作業項目フォームのユーザーによる正しい順序を示しています。 手順 1、8、および 13 のみがユーザーによって実行されます。

1. Web ポータルや Visual Studio チーム エクスプローラーなどの Azure DevOps クライアントから、ユーザーは新しい作業項目を作成するか、既存の作業項目を編集します。

2. フィールドの既定値を入力します。 すべてのフィールドに対して、条件句の一部ではないフィールドに割り当てられた既定値を適用します。

3. フィールド値をコピーまたは設定します。 すべてのフィールドに対して、値をコピーするルールを適用するか、条件句の一部ではないフィールドの値を設定します。

4. When 条件ルールが一致するすべてのフィールドに対して、ルールを適用してフィールド値を設定またはコピーします。

5. 条件に一致しない条件ルールを持つすべてのフィールドに対して、ルールを適用してフィールド値を設定またはコピーします。

   システムは常にルールを処理してからしないルールを処理します。

6. 手順 1 以降に値が変更され、 変更された場合 ルールを含むすべてのフィールドに対して、ルールを適用してフィールド値を設定またはコピーします。

7. ユーザーが編集を開始できるようにします。

8. ユーザーはフィールド値を変更し、フィールドからフォーカスを移動します。

9. 新しい値に一致するフィールドのルールを処理します。

10. 新しい値と一致するフィールドのルールを処理します。

11. 新しい値と一致するフィールドの 変更 ルールを処理します。

12. ユーザーに編集機能を返します。

13. ユーザーは変更をデータ ストアに保存します。

14. すべてのフィールドに対して、条件付きルールの下で直接または間接的にフィールドに定義されている Use the current time to set the value of ... アクションを適用します。

オンプレミスの XML プロセス

ルールは通常、一覧表示される順序で処理されます。 ただし、 WHEN、 DEFAULT、および COPY 要素を使用する場合は、追加の動作が適用される場合があります。 次の手順は、Azure DevOps が実行する対話と作業項目フォームのユーザーによる正しい順序を示しています。 手順 1、8、および 13 のみがユーザーによって実行されます。

1. Web ポータルや Visual Studio チーム エクスプローラーなどの Azure DevOps クライアントから、ユーザーは新しい作業項目を作成するか、既存の作業項目を編集します。

2. フィールドの既定値を入力します。 すべてのフィールドに対して、 DEFAULT 規則を外部または WHEN 規則に適用します。

3. フィールド値をコピーします。 すべてのフィールドに対して、WHEN 句の外部にある COPY 規則を使用します。

4. 一致するWHENルールを持つすべてのフィールドに対して、最初にDEFAULTを実行してから、内部でCOPYルールをします。

5. 一致する WHENNOT ルールを持つすべてのフィールドに対して、最初に DEFAULT を実行してから、内部でCOPY ルールをします。

   システムは常に、WHENNOT ルールの前に WHEN ルールを処理します。

6. 手順 1 以降に値が変更され、WHENCHANGED ルールを含むすべてのフィールドについて、最初に DEFAULT を実行し、次にCOPY ルールを内部で実行します。

7. ユーザーが編集を開始できるようにします。

8. ユーザーはフィールド値を変更し、フィールドからフォーカスを移動します。

9. 新しい値に一致するフィールドに対して、 WHEN ルールを発生させます。

10. 新しい値に一致するフィールドに対して WHENNOT 規則を発生させます。

11. 新しい値に一致するフィールドに対して、 WHENCHANGED ルールを発生させます。

12. ユーザーに編集機能を返します。

13. ユーザーは変更をデータベースに保存します。

14. すべてのフィールドに対して、WHEN または WHENNOT ルールの下でフィールドに対して直接または間接的に定義された SERVERDEFAULT 操作を実行します。

キーストローク エントリとルールの評価

ユーザーが作業項目フォームを使用してフィールド内でキーストロークを入力するたびに、フィールドに新しい値が設定されます。 これは、ルールの前提条件条件が満たされるたびに、条件付きルールが予期せず発生する可能性があることを意味します。

次の XML 例では、"Approved Again" を Status フィールドに入力すると MyCorp.SubStatus が空になります。 WHEN ルールは、意図した最終的な値が "Approve" でない場合でも、ユーザーが Approved に文字 "e" を入力するとすぐに発生します。 このため、条件付きルールを使用する場合は慎重に検討してください。

<FIELD refname="MyCorp.SubStatus" />
   <WHEN field="MyCorp.Status" value="Approve" >
      <EMPTY />
   </WHEN>
</FIELD>

関連記事

• サンプル ルールのシナリオ
• 作業項目フィールドのインデックス
• 作業項目のフィールドと属性
• プロジェクト レベルのアクセス許可を変更する
• プロジェクトコレクションレベルの権限を変更する
• アクセス許可とグループ
• 継承されたプロセス
  • 作業項目の種類にカスタム ルールを追加する
  • ワークフローの状態にルールを適用する
• オンプレミスの XML プロセス
  • 既定値を定義するか、フィールドに値をコピーする
  • 選択リストを定義する
  • 条件付きベースの値とルールを割り当てる