カスタムルールのシナリオのサンプル

[アーティクル]
07/25/2024

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

この記事では、カスタムルール定義の例を示します。すべてのカスタムルールは、作業項目の種類に対して定義されます。継承されたものおよびオンプレミスの両方の XML プロセスモデルの例が示されています。

カスタムルールを追加する前に、ルールとルールの評価を読み取り作業項目の種類 (継承プロセス) にルールを追加します。

依存する必須フィールドを定義する

フィールドが必要なのは、別のフィールドに特定の値が含まれている場合のみです。次の例では、顧客が問題を報告すると、カスタム Customer Reported フィールドが True に設定され、 Severity フィールドが必要になります。問題が顧客によって報告されない場合は、 Severity フィールドの値は必要ありません。

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

Customer REported field=true の場合に重大度を必須にするカスタムルールのスクリーンショット。

作業項目タイプ定義のFIELDSセクション内で、フィールド定義のWHEN規則ステートメントを指定します。

<FIELDS>
   ...
   <FIELD refname="MyCorp.Severity" name="Customer Severity" type="String">  
       <ALLOWEDVALUES>  
           <LISTITEM value="Blocking" />  
           <LISTITEM value="Major" />  
           <LISTITEM value="Minor" />  
       </ALLOWEDVALUES>  
       <WHEN field="MyCorp.CustomerReported" value="true">  
           <REQUIRED />  
       </WHEN>  
   </FIELD> 
   ...
</FIELDS>

依存フィールドの値をクリアする

次の例は、開始日に変更が加えられたときにStory Pointsの値をクリアするカスタムルールを定義する方法を示しています。

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

開始日が変更されたときにストーリーポイントの値をクリアするカスタムルールのスクリーンショット。

作業項目タイプ定義のFIELDSセクション内で、フィールド定義のWHENCHANGED規則ステートメントを指定します。

<FIELDS>
 ...
   <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum">
       <HELPTEXT>The size of work estimated for implementing this user story</HELPTEXT>
       <WHENCHANGED field="Microsoft.VSTS.Scheduling.StartDate">  
           <EMPTY />  
       </WHENCHANGED>
   </FIELD>
   ...
</FIELDS>

依存フィールドの値を設定する

次の例では、 Size フィールドの値を、ユーザー設定フィールド Tee-Shirt Size フィールドに選択した値に応じてマップする方法を示します。

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

Tee-Shirt Size pick-list は、Small、Medium、Large、および X-Large の 4 つの値で構成されます。 Tee-Shirt Size フィールドが特定の値に変更されたときに、Size フィールドを割り当てるために 4 つのカスタムルールが定義されています。使用を簡略化するために、 Tee-Shirt Size の既定値は Small です。

[Tee-Shirt Size] フィールドの [フィールドの編集] ダイアログ

[Tee-Shirt Size] フィールドの [フィールドの編集] ダイアログのスクリーンショット。

カスタム規則

$[Tee-Shirt Size]$Tシャツのサイズ$ が [Small]$小$ に設定されている場合にサイズの値を設定するカスタムルールのスクリーンショット。$

4 つのカスタムルール

Tee-Shirt Size が設定されている場合にサイズの値を設定する 4 つのカスタムルールのスクリーンショット。

作業項目タイプ定義のFIELDSセクションで、Size フィールドの値を指定します。一連のWHENルールステートメントを使用してマッピングを行い、COPY value="value"ルールを使用して Size フィールドの値を設定します。

<FIELDS>
   ...
   <FIELD name="Tee-Shirt Size" refname="Fabrikam.TShirt.Size" type="String">
        <HELPTEXT>Estimate of overall size for work to be done; Small (2), Medium (6), Large (18), X-Large (30).</HELPTEXT>
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="Large" />
          <LISTITEM value="Medium" />
          <LISTITEM value="Small" />
          <LISTITEM value="X-Large" />
        </ALLOWEDVALUES>
   </FIELD> 
   <FIELD name="Size" refname="Fabrikam.Size" type="Integer">
        <HELPTEXT>Integer estimate of overall size for work to be done; Automatically fill in based on Tee-Shirt Size. Allow any value.</HELPTEXT>
        <WHEN field="Fabrikam.TShirt.Size" value="Small">
          <COPY value="2" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Medium">
          <COPY value="6" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Large">
          <COPY value="18" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="X-Large">
          <COPY value="30" />
        </WHEN>
   </FIELD>
   ...
 </FIELDS>

状態の変更時にフィールド値を要求する

次の例は、タスクワークフローStateが Active に変更されたときに、Remaining Work フィールドの指定を要求する方法を示しています。

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

状態が [アクティブ] に変更されたときに残存作業時間を必須にするカスタムルールのスクリーンショット。

作業項目の State フィールドの値が Active に設定され、作業項目が保存されると、 Activated By フィールドと Assigned To フィールドの値が現在のユーザーの名前に自動的に設定されます。そのユーザーは、Team Foundation Server の有効なユーザーグループのメンバーである必要があります。 アクティブ化された日付フィールドの値も自動的に設定されます。次の例は、この規則を適用する要素を示しています。

<WORKFLOW>
. . .  
    <STATE value="Active">
        <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <REQUIRED />
            </FIELD>
        </FIELDS>
    </STATE>
. . .  
</WORKFLOW>

閉じた状態でフィールドの値をクリアする

タスクを閉じる際に Remaining Work フィールドのクリアを自動化するには、示されているようにカスタムルールを定義します。

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

状態が [終了] に変更されたときに必要な残存作業時間をゼロにするカスタムルールのスクリーンショット。

<WORKFLOW>
. . .  
      <STATE value="Closed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <EMPTY />
            </FIELD>
          </FIELDS>
      </STATE>
. . .  
</WORKFLOW>

グループによる作業項目の作成を制限する

作業項目の種類の Proposed 状態カテゴリへの切り替えを制限するカスタムルールでは、その種類の作業項目の作成が事実上禁止されます。ルールを特定のグループに適用することで、そのグループがその種類の作業項目を作成することを事実上禁止します。

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

次のカスタムルールでは、 Proposed 状態カテゴリが New ワークフロー状態にマップされるため、プロジェクトチームが作業項目を作成できないように制限します。

グループによる作業項目の作成を制限するカスタムルールのスクリーンショット。

次のカスタム規則では、Fabrikam レビューチーム (for 属性) が、 New ワークフロー状態への移行を禁止することで作業項目を作成できないように制限します。

<WORKFLOW>
... 
<TRANSITION from=" " to="New"  
   for="[Project]\Developers" 
   not="[Project]\Fabrikam Review Team"  
   . . .  
</TRANSITION> 
...  
</WORKFLOW>

グループによる作業項目の変更を制限する

継承プロセスでは、エリアパスのグループに対する拒否アクセス許可を設定することで、ユーザーが作業項目を変更できないようにすることができます。オンプレミスの XML プロセスでは、作業項目を任意の状態に保存できないようにするグループの各ワークフロー状態に制限を設定できます。

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

特定の種類の作業項目の変更を制限するカスタムルールを定義することはできません。制限は状態によってのみ指定できます。ユーザーが状態を変更しない場合は、すべてのフィールドがグループに対して読み取り専用にされていない限り、他のフィールドを変更できます。

代わりに、ユーザーのグループが任意の種類の作業項目の選択を変更できないように制限する場合は、それらの作業項目をエリアパスに割り当てることができます。次の図に示すように、セキュリティグループを定義し、そのグループのそのエリアパスの作業項目を編集するための制限を設定します。詳細については、「作業追跡のアクセス許可とアクセスの設定」、子ノードの作成、および領域パスの下の作業項目の変更に関するページを参照してください。

作業項目の変更を制限するエリアパスの [アクセス許可] ダイアログのスクリーンショット。

次のカスタムルールでは、Fabrikam レビューチーム (for 属性) が、ユーザーストーリーの作業項目の種類に対して定義されているすべてのワークフロー状態を禁止することで、ユーザーストーリーを変更できないように制限します。特定のチームに対して有効なワークフローの状態がないため、そのチームのメンバーは作業項目を変更と共に保存できません。

<WORKFLOW>
... 
 <STATE value="New">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Active">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Resolved">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Closed">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
...  
</WORKFLOW>

状態遷移を制限する

継承されたプロセスの場合、任意から任意の状態への遷移が自動的に定義されます。これにより、ユーザーはワークフローの状態を新規から完了まで進めることができますが、必要に応じて後方に移動することもできます。切り替えを制限するカスタムルールを定義する場合、ユーザーがワークフローの更新に間違いを犯した場合、修正できない可能性があることに注意してください。たとえば、作業項目カードをボード上の後のステージに移動して状態を更新できますが、元に戻す必要はありません。

ヒント

一部のユーザーではなく、一部のユーザーに対して状態遷移を制限することを検討してください。これにより、ユーザーが間違いを犯した場合、別のチームメンバーに State 値をリセットして制限をバイパスするように依頼できます。

状態遷移ルールを定義する前に、ルールとルールの評価、自動生成されたルールおよびワークフローの状態と状態のカテゴリがバックログとボードで使用される方法を確認します。

閉じた作業項目の変更を制限する

ビジネスプロセスによっては、閉じたり完了したりした作業項目の変更や更新をユーザーが続行できないようにすることができます。作業項目の種類にルールを追加して、ユーザーが閉じた作業項目を再度開かないようにすることができます。

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

継承されたプロセスでは、状態遷移を制限するルールを追加できます。たとえば、次のルールでは、クローズから他の 2 つの状態 (新規とアクティブ) への移行が制限されます。

Note

A work item state moved from ...条件は、Azure DevOps Server 2020 以降のバージョンで使用できます。

Note

指定したルールアクションに応じて、作業項目フォームの [ 保存 ] ボタンが無効になるか、制限されたユーザーが作業項目を変更しようとするとエラーメッセージが表示されます。

オンプレミスのデプロイでは、作業項目の種類にルールを追加して、作業項目が閉じられた後に再び開かないようにすることができます。たとえば、次のワークフロー移行ルールを使用すると、テスターは作業項目を再度開くことができるようになりますが、開発者グループのメンバーは開けません。

<WORKFLOW>
. . .  
<TRANSITION from="Closed" to="New"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
. . .  
</WORKFLOW>

ユーザーまたはグループに基づいてフィールドの変更を非表示にする、または制限する

Current user is a member of group...またはCurrent user is not a member of group...を選択すると、フィールドを非表示にしたり、フィールドを読み取り専用にしたり、フィールドを必須にすることができます。

たとえば、次の条件は、Fabrikam Fiber\Voice グループに属していないメンバーの理由フィールドが非表示になっていることを示しています。

カスタムルール、現在のユーザーがグループのメンバーではない、[理由を非表示] フィールド

Note

作業項目は、それらに適用されるルールの対象となります。ユーザーまたはグループのメンバーシップに基づく条件付きルールは、Web ブラウザー用にキャッシュされます。作業項目の更新が制限されている場合は、これらのルールのいずれかが適用されている可能性があります。自分には当てはまらない問題が発生したと思われる場合は、作業項目フォームでの IndexDB のキャッシュの問題に関する記事をご覧ください。

ユーザーまたはグループに基づいて指定フィールドの変更を制限する

作業項目の種類をカスタマイズして、作業項目の種類の特定のフィールドを変更できるユーザーを制限できます。

Note

Azure DevOps Server 2019 以前のバージョンでは、オンプレミスの XML プロセスモデルを使用するユーザーまたはグループに基づいて作業項目の変更のみを制限できます。

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

次の 2 つの条件のいずれかを使用して、セキュリティグループのユーザーまたはセキュリティグループのメンバーではないユーザーに必要な選択フィールドを作成できます。

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

ヒント

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

たとえば、選択したユーザーまたはグループの Title または State フィールド 読み取り専用 にすることができます。

たとえば、ユーザーストーリー作業項目の種類の Priority フィールドは、Fabrikam Fiber\Voice グループのメンバーの読み取り専用になります。このグループのユーザーがユーザーストーリーを開くと、[優先度] フィールドの値を変更できません。

カスタムルール、現在のユーザーがグループのメンバーではない、優先度フィールドを読み取り専用にする

次の方法で共有

カスタムルールのシナリオのサンプル

依存する必須フィールドを定義する

依存フィールドの値をクリアする

依存フィールドの値を設定する

状態の変更時にフィールド値を要求する

閉じた状態でフィールドの値をクリアする

グループによる作業項目の作成を制限する

グループによる作業項目の変更を制限する

状態遷移を制限する

閉じた作業項目の変更を制限する

ユーザーまたはグループに基づいてフィールドの変更を非表示にする、または制限する

ユーザーまたはグループに基づいて指定フィールドの変更を制限する

フィードバック

その他のリソース

次の方法で共有

カスタム ルールのシナリオのサンプル

依存する必須フィールドを定義する

依存フィールドの値をクリアする

依存フィールドの値を設定する

状態の変更時にフィールド値を要求する

閉じた状態でフィールドの値をクリアする

グループによる作業項目の作成を制限する

グループによる作業項目の変更を制限する

状態遷移を制限する

閉じた作業項目の変更を制限する

ユーザーまたはグループに基づいてフィールドの変更を非表示にする、または制限する

ユーザーまたはグループに基づいて指定フィールドの変更を制限する

関連記事

フィードバック

その他のリソース

カスタムルールのシナリオのサンプル