作業項目フィールドへの規則の適用
フィールドのデータ型に応じて、そのフィールドに入力できるデータに関するさまざまな制約を設定できます。 選択リスト (ドロップダウン メニュー) の値の指定、既定値の設定、エントリの消去、または変更の制限が可能です。 条件付き規則では、異なるフィールド値の間の依存関係に基づいて規則を適用できます。 また、フィールドを変更できるユーザーを制限したり、あるグループにのみ規則を適用するようスコープを指定したりすることができます。
システム フィールドの制約に従って、作業項目の種類 (WIT) 定義の FIELD 定義内にこれらの規則要素をすべて定義することができます。 加えて、HELPTEXT を除いて、これらの規則がワークフローの遷移中に有効になるように、または FIELD (グローバル ワークフロー) 要素内の子要素として指定できます。
.png "作業項目の追跡の XML 要素のフィールド規則")
このトピックで説明する制約に従って、フィールドにあらゆる組み合わせの規則を定義することができます。
ヘルプ テキスト: フィールドの作業項目フォームにツールチップ テキストを表示するよう指定します。 選択リスト: 許可される値、提案される値、または禁止される値のドロップダウン メニューまたは選択リストを指定します。 |
値の規則の割り当て: 実行時の動作と制約を定義します。
|
条件付き規則: いつ一連の規則が親フィールドに適用されるかを指定します。 ユーザー ロールに基づいて条件を設定: 作業項目の作成者または変更者に基づいて規則を適用します。 グループを指定するためにトークンを使用: 正しいトークンを使用して、グループのドメインまたはスコープを指定します。 |
[システム] フィールドに適用できる規則は何ですか。 [人名] フィールドでの検証エラーを回避するにはどのようにすればよいですか。 複数選択の選択リストを定義する方法はありますか。 |
フィールド規則はどこに適用する必要がありますか。 規則はどのように評価されますか。 どの順序が適用されますか。 フォームにあるキーストロークのエントリは、規則の評価にどのように影響しますか。 |
[状態] および [理由] フィールドを変更するにはどのようにすればよいですか。 フィールドに他の 2 つのフィールドの合計となる値を格納するにはどのようにすればよいですか。 グローバル ワークフローを使用してフィールド ルールを定義するのはいつですか。 |
フィールド規則は、作業項目の追跡をカスタマイズするために所有するコンポーネントです。 詳細については、「チームのプロセスをサポートするための作業トラッキング オブジェクトのカスタマイズ」を参照してください。
フィールドの変更またはフィールド規則の WIT 定義ファイルへの追加について、詳細は「作業項目フィールドの定義」を参照してください。
ヘルプ テキスト
ユーザーが作業項目フォームに表示されるフィールドをマウスでポイントしたときに表示されるヘルプ テキストやツールヒント テキストをカスタマイズすることができます。 さまざまな WIT とさまざまなチーム プロジェクトに表示される同じフィールドのヘルプ テキストをカスタマイズおよびローカライズすることができます。 ヘルプ テキストは Unicode で最大 255 文字に制限されています。
次の例は、ヘルプ テキストをカスタムの [業務の妥当性] フィールドに割り当てたものを示しています。
<FIELD name=”Business Justification” refname="Fabrikam.BusinessJustification" type="String">
<HELPTEXT>Only required when you set the Urgencyfield to Need Immediately. </HELPTEXT>
</FIELD>
255 文字の制限を超えたガイダンスをユーザーに表示するには、「作業項目フォームでのヘルプ テキスト、ハイパーリンク、または Web コンテンツの提供」を参照してください。
注意
HELPTEXT の存在が格納されているデータのサイズに加算され、拡張性に影響を与えることがあります。1 つの TFS インスタンス内で数百のチーム プロジェクトをサポートしている場合は、HELPTEXT 規則の使用を控えてください。
選択リストの規則
選択リストの規則では、ユーザーが [文字列] フィールドに対して選択できる値または選択できない値を定義します。 選択リストで定義した値は、作業項目フォームとクエリ エディターに表示されます。 リストの結合、リストの展開や折りたたみが可能です。 また、for 属性と not 属性を使用し、作業項目の変更者に基づいて、これらの規則を適用したり無視したりします。
規則 |
使用方法 |
|---|---|
ALLOWEDVALUES |
指定された値に基づいて、ユーザーが選択できる値を制限します。 |
ALLOWEXISTINGVALUE |
フィールドが選択リストになくても、フィールドの既存の値が保持できるようにします。 選択リストで、または人名を含む選択リストに対してフィールド値を変更する際は、この規則を含めることをお勧めします。 |
GLOBALLIST |
チーム プロジェクトまたはプロジェクトのコレクションで維持される値が入れられるグローバル リストの名前を指定します。 |
PROHIBITEDVALUES |
指定された値が割り当てられないようにします。 フィールドに禁止される値が含まれている場合、作業項目を保存することはできません。 |
SUGGESTEDVALUES |
ユーザーが選択できる値のリストを定義しますが、選択の制約はありません。 ユーザーは、このリストにある値以外の値を指定することができます。 |
選択リストの使用例については、「選択リストの定義」を参照してください。
値の規則の割り当て
値の割り当て規則では、既定値の指定、フィールドのクリア、定義が必要なフィールドなど、ランタイムの動作と制約を定義します。 for 属性および not 属性を使用して、作業項目を変更する人に基づいて、これらのルールを適用または無視することができます。
クリア、既定値の設定、値のコピー、または値を強制的にパターンと一致させる
これらの規則は、既定値の設定、あるフィールドから他のフィールドへの値のコピー、またはフィールド値を強制的に指定されたパターンと一致させることをサポートしています。
規則 |
使用方法 |
|---|---|
COPY |
ユーザーが作業項目を作成したり変更したりする際に、指定された値をフィールドにコピーします。 |
DEFAULT |
ユーザーが作業項目を作成または変更する際に、空のフィールドの値を指定します。 フィールドに既に値がある場合、DEFAULT 規則は無視されます。 |
EMPTY |
値が含まれるフィールドをクリアしてから、ユーザーが作業項目を保存するときに、フィールドを読み取り専用にします。 EMPTY と READONLY を一緒に使用しないでください。 EMPTY は、状態遷移時に、項目が遷移している状態に該当するフィールドをクリアするために主に使用されます。 |
MATCH |
[文字列] フィールドに対して作成されたエントリを、強制的に指定された文字や数値のパターンに適合させます。 |
SERVERDEFAULT |
ユーザーが作業項目を保存する際、現在のユーザー名またはフィールドに対するサーバーのクロック値のいずれかをコピーします。 これらのフィールドは、通常、フォームでは読み取り専用として表示されます。 |
構文の構造と例については、「既定値の定義またはフィールドへの値のコピー」を参照してください。
フィールドに割り当てられた require、read-only、restrict の値
これらの規則では、フィールドの値を指定または変更する制約を指定します。
規則 |
使用方法 |
|---|---|
CANNOTLOSEVALUE |
値が指定されると、ユーザーは値のフィールドをクリアできなくなります。 |
FROZEN |
フィールドに値が含まれていると、ユーザーはフィールドの値を変更できなくなります。 ユーザーがこのフィールドの値を使用して作業項目を保存した後、その値を変更することはできません。 |
NOTSAMEAS |
別のフィールドに割り当てた値と同じ値がフィールドに割り当てられなくなります。 |
READONLY |
フィールドを変更することがまったくできなくなります。 この規則は、特定の条件下で適用できます。 たとえば、作業項目が閉じられた後、レポート目的でデータを保持するため、フィールドを読み取り専用にするなどです。 EMPTY もフィールドを読み取り専用にするため、READONLY と EMPTY 要素を一緒に使用しないでください。 これらの要素を組み合わせると、矛盾した結果になります。 加えて、Control 要素の ReadOnly 属性を使用して、作業項目フォームから、フィールドを読み取り専用で表示することができます。 フィールドは、他のクライアントが書き込むことができますが、作業項目フォーム経由で書き込むことはできません。 |
REQUIRED |
ユーザーはフィールドの値を指定する必要があります。 ユーザーは、すべての必須フィールドに値を割り当てるまで作業項目を保存できません。 |
構文の構造については、「すべての FIELD XML 要素のリファレンス」を参照してください。
作業項目を作成または変更できるユーザーを制限します。
VALIDUSER 要素を人名フィールドに適用することにより、作業項目を作成または変更できるユーザーを制御できます。 この要素を指定するときは、フィールドの値として割り当て可能なユーザーまたはユーザー グループを指定します。 この要素を設定することで、フィールドに割り当てられているユーザーが指定されたグループの直接または間接のメンバーであることを必要とする省略可能な group 属性をサポートできます。 既定では、Team Foundation 有効ユーザー グループのすべてのメンバーをフィールドで指定できます。
VALIDUSER 要素は、文字列型のフィールドの種類に対してのみ有効です。 for 属性または not 属性にユーザーまたはグループをそれぞれ指定することで、作業項目を変更するユーザーにこの規則を適用するかどうかを許可または制限できます。
<VALIDUSER group="groupName" for="userName" not="userName" />
人名フィールドを参照するときは、VALIDUSER 規則のみ使用できます。 次のシステム フィールドは、人名フィールドの例です。
アクティブ化した人 (System.ActivatedBy)
担当者 (System.AssignedTo)
承認方法 (System.AuthorizedAs)
変更者 (System.ChangedBy)
終了者 (System.ClosedBy)
作成者 (System.CreatedBy)
システム フィールドのほかに、カスタム文字列フィールドを作成し、人名フィールドとして使用することもできます。 また、カスタム人名フィールドを Active Directory と同期させることができます (syncnamechanges="true" を指定)。
作業項目フィールドでは、ユーザーの ID はドメインの違いによって区別されません。 したがって、"Fabrikam\ctsoapo" と "Contoso\ctsoapo" は、VALIDUSER 規則が適用されるフィールドに入力した場合、同じユーザーとして扱われます。
条件付き規則
条件付き規則では、いつ一連の規則が親フィールドに適用されるかを指定できます。 別のフィールドに指定された値が割り当てられているか (または割り当てられていないか)、あるいはいつ別のフィールドを変更するか (または変更しないか) に基づいて条件を設定します。 選択リストを含め、条件付き規則要素内に値の規則を割り当てることができます。
規則 |
使用方法 |
|---|---|
WHEN |
指定した値が別のフィールドに割り当てられている場合に、親フィールドに適用する規則を指定します。 |
WHENNOT |
指定した値が別のフィールドに割り当てられていない場合に、親フィールドに適用する規則を指定します。 |
WHENCHANGED |
指定したフィールドの値が変化する場合、親フィールドに適用する規則を指定します。 |
WHENNOTCHANGED |
指定したフィールドの値が変化しない場合、親フィールドに適用する規則を指定します。 |
フィールドごとに複数の条件付き規則を指定できます。 ただし、条件付き規則ごとに指定できる重要なフィールドは 1 つのみです。 条件付き規則を入れ子構造にすることはできません。 構文の構造と例については、「条件付き値および条件付き規則の割り当て」を参照してください。
作業項目を作成または変更するユーザーに基づいて、規則を適用または無視します。
for 属性または not 属性を使用することによって、選択リストを作成したり、ユーザーのグループに適用する値の規則または適用しない値の規則を割り当てたりすることができます。 グループに対して規則のスコープを調整します。 規則のスコープを複数のグループに設定するには、使用するグループのセットを含む親の TFS グループを作成する必要があります。
フィールドを指定したグループに対してのみ必須とします。
グループに規則を適用するには、for を使用します。 この例では、Junior Analysts グループのいずれかのユーザーが [第 2 承認者] フィールドに入力する必要があります。
<FIELD name="Second Approver"> <REQUIRED for="Example1\Junior Analysts"/> </FIELD>フィールドの変更をユーザーのグループに対して制限する:
規則からグループを除外するには not を使用します。 この例では、[トリアージの説明] フィールドを、Triage Committee グループのユーザーを除く全員に対して読み取り専用にするよう定義しています。
<FIELD name="Triage Description"> <READONLY not="[Project]\Triage Committee" /> </FIELD>一部のユーザーに対してフィールドを必須とし、他のユーザーには必須としない:
for と not の組み合わせを使用して、同時に一部のユーザーに対して規則を適用し、他のユーザーには適用しないようにします。 この例では、[重要度] フィールドを、Project Members グループのユーザーに対しては必須フィールドとして定義し、Project Admins グループのユーザーに対しては必須フィールドとして定義しないようにします。
<FIELD name="Severity"> <REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/> </FIELD>これは、Deny が Allow より優先されるためです。ユーザーが両方のグループに属している場合、"not" ステートメントは強制されますが、フィールドは必須になりません。
参照グループに対するトークンを使用する
グループに対する規則を制限する場合、グループのドメインまたはスコープを示す必要があります。 値によってはトークンを使うことができます。
[人名] フィールドでは、ユーザーとグループの両方を参照する値を許容することが可能です。 フィールド属性 for および not はグループに対して適用されます。 これらの項目に値を指定する場合、次のトークンを使用できます。
チーム プロジェクトのスコープ — [Project] :
チーム プロジェクトに定義されるグループを指定するには、[Project] トークンを使用します。 これは、チーム、[Project]\Contributors グループなどの組み込みの TFS グループ、プロジェクト レベルで作成したカスタム TFS グループ、または TFS グループに追加した Windows グループになります。 次に例を示します。
チーム: [Project]\Fabrikam Team
チームを作成する場合、チームに割り当てられたメンバーを含む TFS グループが作成されます。
チーム プロジェクト グループ: [Project]\Contributors
チーム プロジェクトに追加される Windows グループ: [Project]\ Triage Committee
ヒント: Team Web Access (TWA) 管理コンテンツで [セキュリティ] ページを開いて、有効なグループのリストを表示することができます。
プロジェクトのコレクションのスコープ — [CollectionName]:
プロジェクトのコレクションの管理者グループ、またはコレクションに追加する Windows グループなど、コレクションがスコープ設定された TFS グループを参照するには、[CollectionName] を使用します。 次に例を示します。
<FIELD name="Title"> <READONLY for="[DefaultCollection]\Project Collection Valid Users"/> </FIELD>サーバー インスタンスのスコープ — [GLOBAL]:
組み込みグループやサーバー レベル グループに追加した Windows グループなど、サーバーでスコープ設定された TFS グループを参照するには、[GLOBAL] トークンを使用します。 次に例を示します。
<FIELD name="Title"> <READONLY for="[Global]\Team Foundation Valid Users"/> </FIELD>ドメイン修飾されたアカウントまたはグループを指定する:
次の例に示すようなドメイン修飾されたアカウント名は、ドメインのユーザーまたはグループの参照に使用されます。 規則によってはグループのみをサポートし、ドメインのユーザーの参照をサポートしないことに注意してください。
<LISTITEM value="FABRIKAM\Christie Church’s Direct Reports"/>
すべてのユーザーおよびグループは、次のトークンのいずれかで修飾される必要があります。 たとえば、次の XML は有効なトークンで指定されたグループを修飾していないため無効となります。
<FIELD name="Title">
<READONLY for="Dev Team"/>
</FIELD>
Q & A
Q: [システム] フィールドに適用できる規則は何ですか。
A: [システム] フィールドには Sytem.Name の参照名 (System.Title および System.State など) があります。 TFS はこれらのフィールドのカスタマイズを制限します。ただし次のインスタンスを除きます。
HELPTEXT 規則は全フィールドに割り当てることができます。
READONLY 規則は [状態] および [理由] フィールドに割り当てることができます。
ほとんどの規則は、[タイトル]、[割り当て先]、[説明]、または [システムによる変更] フィールドに割り当てることができます。
Q: [人名] フィールドでの検証エラーを回避するにはどのようにすればよいですか。
A: チームのメンバーがチームを去り、プロジェクトの貢献者として登録された者でなくなった場合に発生する検証エラーを回避するには、[割り当て先] フィールドに要素 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>
Q: 複数選択の選択リストを定義する方法はありますか。
A: この機能はネイティブでサポートされていません。ただし、この CodePlex プロジェクトで提供されるソース コード (Custom Controls for TFS Work Item Tracking (TFS 作業項目を追跡するカスタム制御)) を採用できることがあります。
Q: [状態] および [理由] フィールドを変更するにはどのようにすればよいですか。
A: [状態] フィールドおよび [理由] フィールドは、WIT 定義の「ワークフロー」セクション内で定義されます。 状態の変更時、理由の選択時、または特定の遷移において、フィールドに適用するほとんどのフィールド ルールを指定することができます。 詳細については、「作業項目の種類に関するワークフローの変更」を参照してください。
Q: フィールド規則はどこに適用する必要がありますか。
A: 作業項目の耐用期間全体にわたってフィールドに規則を適用する場合は、FIELD 定義内で指定します。 たとえば、新規かつアクティブなバグのために必要となるフィールドは、そのバグがクローズされるまでずっと必要です。
そうでない場合、状態が変化している間にのみ規則が評価されるよう指定します。 これらの規則は、STATE 要素、REASON 要素、または TRANSITION 要素の WORKFLOW セクション内で定義されます。 HELPTEXT を除くすべての規則は、FIELD (ワークフロー) 要素内で適用できます。
フィールド規則は追加的です。 つまり、同じフィールドに対して 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>
Q: 規則はどのように評価されるのですか。どの順序が適用されますか。
A: 一般的に、規則は、一覧表示する順序で処理されます。 ただし、WHEN* 要素、DEFAULT 要素、COPY 要素を使用する場合、追加の動作が適用されることがあります。
フィールドに複数の規則を適用する場合、規則がどのように評価されるかについてのアイデアが得られます。 規則の評価方法は、完全に確定的なものであはありません。 このセクションでは、WHEN* 規則、DEFAULT 規則、COPY 規則を使用する場合に予想される動作と相互作用について説明します。
次の手順は、TFS が実行する相互作用を、作業項目フォームのユーザーごとに正しい順序で示します。 手順 1、8、13 のみがユーザーによって実行されます。
Visual Studio、Team Explorer、Team Web Access、または Team Explorer Everywhere などの Team Foundation クライアントから、ユーザーは新しい作業項目を作成するか、既存の作業項目を編集します。
フィールドの既定値を記入します。 全フィールドで、WHEN* 規則の外にあるどの DEFAULT 規則でも使用できます。
フィールド値をコピーします。 全フィールドで、WHEN* 句の外にあるどの COPY 規則でも使用できます。
一致する WHEN 規則を持つ全フィールドで、先に DEFAULT を実行してから、内部の COPY 規則を実行します。
一致する WHENNOT 規則を持つ全フィールドで、先に DEFAULT を実行してから、内部の COPY 規則を実行します。
TFS は、常に WHENNOT 規則の前に WHEN 規則を処理します。
手順 1 から変更された値があり、WHENCHANGED 規則を含む全フィールドでは、先に DEFAULT 規則を実行してから内部にある COPY 規則を実行します。
ユーザーが編集を開始するのを許可します。
ユーザーは、フィールド値を変更した後、フィールドからフォーカスを移動します。
新しい値と一致するフィールドに対して任意の WHEN 規則を指定します。
新しい値と一致するフィールドに対して任意の WHENNOT 規則を指定します。
新しい値と一致するフィールドに対して任意の WHENCHANGED 規則を指定します。
ユーザーに対して編集能力を返します。
ユーザーは変更をデータベースに保存します。
全フィールドで、WHEN 規則または WHENNOT 規則に基づいて直接的または間接的にフィールドに対して定義された SERVERDEFAULT 操作を実行します。
Q: フォームにあるキーストロークのエントリは、規則の評価にどのように影響しますか。
A: システムは、ユーザーが UI の作業項目フォームを介してフィールド内のキーストロークを入力するたびに、フィールドに新しい値を設定します。 つまり、規則の前提条件に適合する場合は常に、条件付き規則が予期せず発生することがあります。
次の XML の例では、[状態] フィールドに "Approved Again (再度承認済み)" と入力したときに SubStatus が空白になります。これは、目的の最終値が "Approve (承認)" でない場合であっても、ユーザーが "Approved (承認済み)" に "e" を入力するとすぐ、WHEN* 規則が発生するためです。 このため、条件付き規則を使用する際はよくお考えください。
<FIELD refname="MyCorp.SubStatus" />
<WHEN field="MyCorp.Status" value="Approve" >
<EMPTY />
</WHEN>
</FIELD>
Q: フィールドに他の 2 つのフィールドの合計となる値を格納するにはどのようにすればよいですか。
A: この機能は、現時点ではネイティブにサポートしていません。
Q: グローバル ワークフローを使用してフィールド ルールを定義するのはいつですか。
A: グローバル ワークフローを使用するのは、複数のチーム プロジェクト全体で定義と規則が同じである多数のフィールドを維持するよう課された場合のみです。 グローバル リストと類似して、グローバル ワークフローの使用により、フィールド定義を更新する必要がある場合に必要な作業を最小限にすることができます。 詳細については、「グローバル ワークフローのカスタマイズ」を参照してください。