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

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

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

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

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

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

継承プロセス

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

作業項目タイプ定義の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 フィールドに選択した値に応じてマップする方法を示します。

継承プロセス

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

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

カスタム規則

4 つのカスタム ルール

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

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

継承プロセス

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

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

次のカスタム 規則では、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 値をリセットして制限をバイパスするように依頼できます。

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

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

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

継承プロセス

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

Note

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

Note

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

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

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

<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 のキャッシュの問題に関する記事をご覧ください。

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

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

継承プロセス

次の 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 グループのメンバーの読み取り専用になります。 このグループのユーザーがユーザー ストーリーを開くと、[優先度] フィールドの値を変更できません。

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

オンプレミス XML プロセス モデルでは次の制限要求をサポートするように作業項目の種類をカスタマイズできます。

• 作業項目を作成または変更できるユーザーを制限する
• エピックやフィーチャーなど、特定の作業項目の種類を作成できるユーザーを制限する

たとえば、作業項目の種類 (通常は WORKFLOW セクション内) にルールを追加することで、作業項目の変更を制限できます。

次の 2 つの方法のいずれかで、作業追跡オブジェクトへのアクセスを制限します。

• 条件フィールド ルール、 条件ベースのフィールド ルール グループに適用される 2 つの組み合わせを設定します。 条件を満たすルールを指定し、特定のグループに適用することで、フィールドへの変更を制限できます。 条件付きルールには、 CANNOTLOSEVALUE、 EMPTY、 FROZEN、 NOTSAMEAS、 READONLY、および REQUIRED 要素を含めることができます。
• [非表示のカテゴリ] グループに WIT を追加、プロジェクト共同作成者の大半が作成できないようにすることができます。 テンプレートへのハイパーリンクを作成作業項目フォームを開き、そのリンクを作成するチーム メンバーと共有することができます。

関連記事

• ワークフローの状態にルールを適用する (継承プロセス)
• ルールおよびルールの評価