次の方法で共有


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

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

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

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

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

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

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

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

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

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

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

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

Tee-Shirt Size pick-list は、SmallMediumLarge、および 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 つのカスタム ルールのスクリーンショット。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状態遷移を制限する

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

ヒント

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

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

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

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

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

Note

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

カスタム ルール、現在のユーザーがグループのメンバーではない、新しい状態またはアクティブな状態への切り替えを禁止する

Note

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

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

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 プロセス モデルを使用するユーザーまたはグループに基づいて作業項目の変更のみを制限できます。

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

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