JP5238138B2 - ワークアイテムトラッキングシステム用のワークアイテムルール - Google Patents

Description

本発明は、ワークアイテムトラッキングシステム用のワークアイテムルールに関する。

ワークアイテムトラッキングシステム（ｗｏｒｋ ｉｔｅｍ ｔｒａｃｋｉｎｇ ｓｙｓｔｅｍ）はしばしば、現在のビジネスの世界、特にソフトウェア開発環境で使用される。ワークアイテムトラッキングシステムは通常、ユーザが、作業の単位を表す１つまたは複数のワークアイテムを定義し、作業の単位を表すワークアイテムを更新することによって、作業の単位の進行を追跡することを可能にする。作業の単位は、１人または複数の人によって実行される仕事、ソフトウェアアプリケーションのバグフィックス（すなわち、ソフトウェア欠陥の訂正）または改善／追加などのソフトウェア関連ワークアイテム、プロジェクト、別のタイプのワークアイテム、あるいは前述のものの任意の組合せを含むがこれに制限されない様々なタイプのいずれかとすることができる。本明細書で使用する「ワークアイテム」は、作業の単位を表し、定義するソフトウェア抽象化（例えば、オブジェクト、クラス、レコード、アレイ、他のタイプの抽象化、または前述のものの適当な組合せ）である。「ワークアイテムトラッキングシステム」または「ＷＩＴＳ」は、（ユーザによる）手動のおよび（システムにおける他のイベントに応答するシステムによる）おそらくは自動の、ワークアイテムの作成および変更を可能にすることによって作業単位の追跡を可能にするシステムである。

一部のワークアイテムトラッキングシステムは、異なるユーザに異なるアクセス特権を与えるように、および／または異なるユーザがワークアイテムに対して異なるアクションを実行できるように、ハードコードされている。例えば、（例えば、第１の開発チームからの）第１のソフトウェア開発者が第１のワークアイテムにアクセスし、これを変更することを許可し、（例えば、第２の開発チームからの）第２のソフトウェア開発者が第１のワークアイテムにアクセスすることは許可するが、変更することは許可せず（例えば、読み取り専用）、（例えば、第３の開発チームからの）第３のソフトウェア開発者が第１のワークアイテムにアクセスすることを完全に拒否する、とすることができる。これらのアクセスおよび変更の「ルール」は、別々に識別可能な別個のソフトウェアエンティティではなく、その定義および機能性は、ワークアイテムへのアクセスおよび操作を制御するコードの中に埋め込まれている（すなわち、ハードコードされている）。したがって、これらは、容易に使用可能（すなわち、再利用可能）ではなく、他のエンティティ（すなわち、プログラムおよびアプリケーション）による代替の解釈の対象ではない。

さらに、これらのルールは、ユーザに対して閉ざされており（公開されていない）、ユーザによる作成または変更の対象ではない。コードは、プログラマが変更しなければならない。時とともに、会社の従業員、企業構造、ビジネスゴール、プロダクト、および会社の他の態様が変化する。そのような変化に応答して、ワークアイテムのアクセスルールおよび変更ルールを変更する（例えば、１つまたは複数のルールを追加し、削除し、および／または変更する）ことが望ましい場合がある。しかし、上で説明したように、この変更はプログラマによって行われなければならない。したがって、管理者（または変更を望む他の人）は自分自身でその変更を行うことができず、必要な変更をプログラマに説明しなければならない。さらに、管理者はコードに対してプログラマによって行われた実際の変更を（コードの形を除いて）容易に見ることができず、そのような変更の結果を経験することしかできない。変更が所望の結果をもたらさない場合、管理者はプログラマのところに行き、問題を説明しなければならず、その後、このプロセスが繰り返される。このプロセスは、アクセスルールおよび／または変更ルールに対する変更を実装するために管理者とプログラマの間の対話を必要とし、ビジネスリソースの非効率的な使用である。いくつかの文献に、上述のような従来技術に関連した技術内容が開示されている（例えば、非特許文献１および２参照）。また、米国特許出願第１１／０８９，６１３号明細書に、本発明に関連する内容が含まれている可能性がある。

[online]、2005年3月25日、インターネット <URL : http://lab.msdn.microsoft.com/teamsystem/> [online]、2005年3月25日、インターネット <URL : http://blogs.msdn.com/team_foundation/>

従来のワークアイテムトラッキングシステムには、上述したような種々の問題があり、さらなる改善が望まれている。本発明は、上記従来技術の問題点を解決することを課題とする。

本明細書で説明されるのは、ワークアイテムトラッキングシステムで使用されるワークアイテムルールである。本明細書で使用される「ワークアイテムルール」または「ＷＩＲ」は、ワークアイテムに影響するアクションを少なくともある度合まで統制するルールを定義する、識別可能な別個のソフトウェア抽象化（例えば、オブジェクト、クラス、レコード、アレイ、他のタイプの抽象化、または前述のものの適当な組合せ）である。ワークアイテムルールは、複数のソフトウェアエンティティによってアクセス可能、使用可能、および解釈の対象とすることができる。さらに、ワークアイテムルールを、例えばユーザインタフェース（例えば、ＸＭＬエディタまたはＧＵＩ）を介するユーザへの公開によって、ユーザ（すなわち、プログラマだけではなく）による作成および変更の対象になるように構成することができる。したがって、ユーザは、ワークアイテムへのアクセスおよび／またはその変更を制御するビジネスルール抽象化を作成し、変更することを可能にされうる。

ワークアイテムルールは、抽象化を識別できる識別子、および／または名前を指定することができ、条件およびその条件が満足された場合に行われるアクションを指定するかこれらを示すことができる。そのような条件は、ユーザまたはユーザのグループ、ワークアイテムの内容（例えば、フィールド、ワークフロー、遷移、状態など）、ワークアイテムの１つまたは複数のプロパティ（例えば、タイプまたは他のメタデータ）、ビジネスプロダクトまたはその態様、ワークアイテムに関連する他の情報、または前述のものの適当な組合せのいずれかに対応するものとすることができる。

いくつかの実施形態で、認可されたユーザ（例えば管理者）がワークアイテムルールを作成し、および／または変更することを可能にするユーザインタフェース（例えば、ＸＭＬエディタまたはＧＵＩ）が提供される。

本発明のいくつかの実施形態で、ワークアイテムトラッキングシステムは、論理階層、例えばツリー様配置でワークアイテムルールを編成することができる。ワークアイテムの論理階層の編成は、例えばビジネスプロダクトまたは会社構造など、別のエンティティの編成構造に対応するものとすることができる。階層内のワークアイテムの間で関係を定義することができる。例えば、階層の第２のレベルのワークアイテムが、階層の第１のレベルの１つまたは複数のワークアイテムとの親関係を有することができる。したがって、第１のレベルのワークアイテムの１つについて定義されたワークアイテムルールを、第２のレベルのワークアイテムについて定義されたワークアイテムルールによってオーバーライド（ｏｖｅｒｒｉｄｅ）することができる。いくつかの実施形態で、否定の判定をもたらすワークアイテムルールは、論理階層内の位置に関わりなく、肯定の判定をもたらす別のワークアイテムルールをオーバーライドする。

本発明のいくつかの実施形態で、第１のワークアイテムルールに影響する第１のユーザアクションに応答して、第１のユーザおよび／または第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定することができる。次に、その１つまたは複数のワークアイテムルールを解釈することができ、その解釈に基づいてユーザアクションに応答することができる。

本発明のいくつかの実施形態で、ワークアイテムルールを、マルチティア（ｍｕｌｔｉ−ｔｉｅｒ）の形で実施することができる。例えば、ワークアイテムトラッキングシステムを、少なくともクライアントワークアイテムルールエンジンおよびサーバワークアイテムルールエンジンを含む複数のティアに渡って分散させることができる。クライアントワークアイテムルールエンジンは、ユーザがワークアイテムにアクセスし、および／またはこれを変更することを可能にするユーザインタフェースを提供することができる。ユーザがワークアイテムにアクセスするかこれを変更することに応答して、クライアントワークアイテムルールエンジンは、１つまたは複数の対応するワークアイテムルールを解釈することができ、その後に、サーバワークアイテムルールエンジンが、同一のまたは類似する１つまたは複数のワークアイテムルールを（例えば、サーバワークアイテムルールエンジンが自由に使える、より新しいデータを有する可能性があるという事実に起因して）おそらくは異なる形で解釈することができる。

次の説明から明瞭になるように、ワークアイテムルールは、プログラマの助けなしで、ビジネスエンティティの変化するビジネスニーズに適合するように比較的簡単に変更できるので、既知のワークアイテムトラッキングシステムの柔軟性を拡張する。さらに、以下に説明するワークアイテムルールを実施するシステムおよび方法は、ワークアイテムのセキュリティとワークアイテムの内容の保全性維持との緻密な統合を可能にする。

本発明の実施形態で、ワークアイテムトラッキングシステムの１つまたは複数のワークアイテムに影響するユーザアクションが統制される。ワークアイテムトラッキングシステムの第１のワークアイテムに影響する第１のユーザアクションに応答して、第１のユーザおよび／または第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定する。その１つまたは複数の判定されたワークアイテムルールを解釈し、そのワークアイテムルールの解釈に基づいて第１のユーザアクションに応答する。

この実施形態の一態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、前記第１のユーザまたは前記第１のユーザが属するユーザのグループに対応し、解釈することは、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含む。

この実施形態のもう１つの態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの内容に対応し、解釈することは、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含む。

この実施形態のもう１つの態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの１つまたは複数のプロパティに対応し、解釈することは、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含む。

この実施形態のもう１つの態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、プロダクトの少なくとも１つの態様に対応し、解釈することは、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含む。

この実施形態のさらにもう１つの態様で、ユーザが１つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェースが提供される。

この実施形態のもう１つの態様で、前記ワークアイテムトラッキングシステムは、論理階層に編成された複数のワークアイテムルールを備え、前記複数のワークアイテムは、前記１つまたは複数のワークアイテムを備える。第１のワークアイテムは、前記階層の第１のレベルに対応し、第２のワークアイテムは、前記第１のレベルに優先する前記階層の第２のレベルに対応する。判定することは、前記第１のワークアイテムに対応する第１のワークアイテムルールを判定することと、前記第２のワークアイテムに対応する第２のワークアイテムルールを判定することとをさらに含み、解釈することは、前記第１および第２のワークアイテムルールを解釈することと、前記第１のレベルに優先する前記階層の前記第２のレベルに少なくとも部分的に基づいて、前記第１のワークアイテムルールの前記解釈を前記第２のワークアイテムルールの前記解釈によってオーバーライドすることとを含む。

この実施形態のもう１つの態様で、前記ワークアイテムトラッキングシステムは、少なくとも第１のネットワーク要素および１つまたは複数の通信媒体によって前記第１のネットワーク要素に接続された第２のネットワーク要素に渡って分散される。前記第１のネットワーク要素は第１のモジュールを備え、前記第２のネットワーク要素は第２のモジュールを備える。前記第１のモジュールは、前記第１のワークアイテムに影響するユーザアクションを指定するユーザからの入力を受け取る。前記判定すること、解釈すること、および応答することは、前記第１のモジュールによって実行される。前記第２のモジュールは、前記１つまたは複数の判定されたワークアイテムルールを解釈する。

本発明のもう１つの実施形態で、コンピュータプログラム製品が提供される。前記製品は、コンピュータ読み取り可能な記録媒体と、前記コンピュータ読み取り可能な記録媒体に保管され、コンピュータによって実行された結果として、上述した本発明の実施形態の方法および／または上述したその１つまたは複数の態様を実行するように前記コンピュータに指示する命令を定義するコンピュータ可読信号とを備える。前記コンピュータ可読信号は、マークアップ言語に従って前記命令のうちの１つまたは複数を定義することができる。

本発明のもう１つの実施形態で、ワークアイテムトラッキングシステムの１つまたは複数のワークアイテムに影響するユーザアクションを統制するシステムが提供される。前記システムは、前記ワークアイテムトラッキングシステムの第１のワークアイテムに影響する第１のユーザアクションに応答して、前記第１のユーザおよび／または前記第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定し、前記１つまたは複数の判定されたワークアイテムルールを解釈し、前記解釈に基づいて前記ユーザアクションに応答する、第１のワークアイテムルールエンジンを備える。

この実施形態の一態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、前記第１のユーザまたは前記第１のユーザが属するユーザのグループに対応する。前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作する。

この実施形態のもう１つの態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの内容に対応し、前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作する。

この実施形態のもう１つの態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの１つまたは複数のプロパティに対応し、前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作する。

この実施形態のさらにもう１つの態様で、前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、プロダクトの少なくとも１つの態様に対応し、前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作する。

この実施形態のもう１つの態様で、ユーザが１つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェースが提供される。

この実施形態のもう１つの態様で、前記ワークアイテムトラッキングシステムは、論理階層に編成された複数のワークアイテムルールを備え、前記複数のワークアイテムは、前記１つまたは複数のワークアイテムを備える。第１のワークアイテムは、前記階層の第１のレベルに対応し、第２のワークアイテムは、前記第１のレベルに優先する前記階層の第２のレベルに対応する。前記第１のワークアイテムルールエンジンは、前記第１のワークアイテムに対応する第１のワークアイテムルールを判定し、前記第２のワークアイテムに対応する第２のワークアイテムルールを判定するように動作する。前記第１のワークアイテムルールエンジンは、前記第１および第２のワークアイテムルールを解釈し、前記第１のレベルに優先する前記階層の前記第２のレベルに少なくとも部分的に基づいて、前記第２のワークアイテムルールの前記解釈による前記第１のワークアイテムルールの前記解釈のオーバーライドを制御するように動作する。

この実施形態のもう１つの態様で、前記第１のワークアイテムルールエンジンは、第１のネットワーク要素に常駐し、前記第１のワークアイテムルールエンジンは、前記第１のユーザアクションを指定するユーザからの入力を受け取るように動作する。前記システムは、１つまたは複数の通信媒体によって前記第１のネットワーク要素に接続された第２のネットワーク要素に常駐する第２のワークアイテムルールエンジンをさらに備え、前記第２のワークアイテムルールエンジンは、前記１つまたは複数の判定されたワークアイテムルールが前記第１のモジュールによって適用されるのとは異なって、前記１つまたは複数の判定されたワークアイテムルールを解釈するように動作する。

本発明の他の利益、新規の特徴、および目的ならびに本発明の態様および実施形態は、添付図面とともに検討されるときに、本発明の態様および実施形態を含む以下の本発明の詳細な説明から明白になるだろう。添付図面は、概略的であり、実寸通りに描かれていることを意図されたものではない。図面では、様々な図面に示された同一のまたはほぼ同一の構成要素のそれぞれが、単一の符号によって表される。図を明瞭にするために、当業者が本発明を理解できるようにするために図示が必要でない場合には、すべての構成要素がすべての図面で符号を付けられているわけではなく、本発明の各実施形態または各態様のすべての構成要素が図示されているわけでもない。

本発明によれば、柔軟なワークアイテムトラッキングシステムを実現することができる効果を奏する。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。

本発明のいくつかの実施形態を、本件特許出願人から入手できるＭｉｃｒｏｓｏｆｔ Ｔｅａｍ Ｓｙｓｔｅｍテクノロジ（非特許文献１）および／またはＭｉｃｒｏｓｏｆｔ Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎテクノロジ（非特許文献２）に従って実装することができる。さらに、本発明のいくつかの実施形態を、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）２００５（ＭＶＳ ２００５）を含む本件特許出願人から入手可能なＭｉｃｒｏｓｏｆｔ（登録商標）Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）（ＭＶＳ）の諸バージョンによって提供されるワークアイテムトラッキングシステムおよびワークアイテムルールテクノロジ（その一部を付録Ｉ〜ＩＩＩで詳細に説明する）に従って実装することができる。設計文書；ビジネスルールの説明および使用と題する付録Ｉでは、ビジネスルールの実施形態と、それをどのように使用できるかを説明する。ワークアイテムタイプ定義言語（Ｗｏｒｋ Ｉｔｅｍ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）と題する付録ＩＩでは、ワークアイテムタイプ定義言語の実施形態を説明する。ワークアイテムタイプルール ― カスタマシナリオと題する付録ＩＩＩでは、ワークアイテムタイプルールを使用できるシナリオの例を説明する。付録Ｉ〜ＩＩＩの内容全体が、参照によって組み込まれている。Ｍｉｃｒｏｓｏｆｔ Ｔｅａｍ Ｓｙｓｔｅｍテクノロジ、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎテクノロジ、ＭＶＳテクノロジ、および付録Ｉ〜ＩＩＩに記載のテクノロジは、本発明の実施形態を実装するのに使用できるテクノロジの例にすぎず、本発明の範囲を制限することを意図されていないことを理解されたい。他のテクノロジ、例えば上記テクノロジの変形を使用することができ、これらが本発明の範囲に含まれることが意図されている。

本発明の上記および他の実施形態の機能および利益は、以下で説明する例からより十分に理解されるだろう。次に述べる例では、より良い理解を容易にし、本発明の利益を例示することが意図されているが、本発明の範囲全体を例証するものではない。

この説明であれ請求項であれ、ここで使用される単語「備える」、「含む」、「有する」などは、制限なし、すなわち、含むがそれに制限されないことを意味すると理解されなければならない。

実施例
図１は、ワークアイテムトラッキングシステム（ＷＩＴＳ）のワークアイテムルール（ＷＩＲ）を実施するためのシステム１００の例を示すブロック図である。システム１００は、ワークアイテムトラッキングシステムのワークアイテムルールを実施するシステムの例示的な実施形態にすぎず、本発明の範囲を制限することを意図されたものではない。そのようなシステムの多数の他の実施形態、例えばシステム１００の変形形態が可能であり、本発明の範囲に含まれることが意図されている。例えば、主にＷＩＲに関する図１００に示されたいくつかの要素は、多少はＷＩＴＳ要素内に統合されたものとして図示されている。しかし、ＷＩＲ要素は、実際にはＷＩＴＳ要素と別々の別個の要素とすることができる。

システム１００は、次のものを含むことができる：１つまたは複数のＷＩＴＳクライアント（例えば、ＷＩＴＳクライアント１０２、１０４、および１０６）；１つまたは複数のＷＩＴＳサーバ（例えば、ＷＩＴＳサーバ１２０）；それぞれを、例えばデータベース（例えば、オブジェクト指向データベース、リレーショナルデータベース、ファイルシステム、別のタイプのデータベース、または前述の任意の組合せ）などの、様々なタイプのデータソースのいずれかとすることができる１つまたは複数のデータソース（例えば、データソース１２６）；ネットワーク１１８、他のネットワーク要素、または前述のものの任意の組合せ。

本明細書で使用される「ネットワーク」は、要素間で通信を交換できる伝送媒体の１つまたは複数のセグメントによって相互接続された２つまたはそれ以上のネットワーク要素のグループである。各セグメントは、金属および／または光ファイバから作られた１つまたは複数の電気的または光学的なワイヤまたはケーブル、（例えば、搬送波を介する無線伝送を使用する）空気、またはこれらの伝送媒体の任意の組合せを含む、複数のタイプの伝送媒体のいずれかとすることができる。本明細書で使用される「複数」は、２つまたはそれ以上を意味する。ネットワークを、単一のワイヤ、無線接続、または他のタイプのセグメントによって接続された２つのネットワーク要素のように単純なものとすることができることを理解されたい。さらに、ネットワークが本明細書の図面で図内の要素に接続されて図示されている場合、接続された要素自体がネットワークの一部と考えられることを理解されたい。

ＷＩＴＳクライアント１０２、１０４、および１０６のそれぞれは、例えば諸ユーザデバイスなどの複数のタイプのデバイスのいずれかとすることができる。ユーザデバイスに、ワークステーション；パーソナルコンピュータ（例えば、ＰＣ）；ラップトップコンピュータ、ノートブックコンピュータ；電話機（例えば、陸上回線（ｌａｎｄｌｉｎｅ）電話機または携帯電話機）；ポケットベル；Ｂｌａｃｋｂｅｒｒｙ（商標）ブランドのデバイス、ＰＣＳデバイス、携帯情報端末（ＰＤＡ）、双方向ラジオ（例えば、「ウォーキートーキー」）、他のタイプのユーザデバイス、および前述のものの任意の適当な組合せが含まれるが、これらに制限はされない。

ＷＩＴＳクライアント（例えば、ＷＩＴＳクライアント１０６）は、ワークアイテムタイプインタフェース（ＷＩＴ ＩＦ）１０８、ワークアイテムインタフェース１１０、セキュリティインタフェース１１２、クライアントワークアイテムルール（ＷＩＲ）エンジン１１４およびＷＩＲキャッシュ１１６のいずれも含むことができる。

ＷＩＴインタフェース１０８は、例えば付録ＩＩに記載のように、ユーザがワークアイテムタイプ定義を作成し、および／または変更することを可能にするユーザインタフェースとすることができる。本明細書で使用される「ユーザインタフェース」は、ユーザがアプリケーションの実行中にアプリケーションとインタフェースすることを可能にするアプリケーションまたはアプリケーションの一部（すなわち、コンピュータ可読命令のセット）である。ユーザインタフェースに、例えばコンピュータスクリーンまたは他の手段を介して視覚的に、スピーカまたは他の手段を介して聴覚的に、およびゲームコントローラまたは他の手段を介して手動でなど、アプリケーションがアプリケーションの実行中にユーザにどのように情報を出力するかを定義するコードを含めることができる。そのようなユーザインタフェースに、ユーザがアプリケーションの実行中にどのように情報を入力できるかを定義するコードも含めることができ、例えば、マイクロホンを使用して聴覚的に、またはキーボード、マウス、ゲームコントローラ、タッチスクリーン、もしくは他の手段を使用して手動で、または他の手段で行うことができる。

ユーザインタフェースは、情報をどのようにしてユーザに視覚的に提示する（すなわち表示する）かを定義し、ユーザがどのようにして情報のビジュアルプレゼンテーション（すなわちディスプレイ）をナビゲートしてビジュアルプレゼンテーションの文脈で情報を入力できるかを定義することができる。ユーザインタフェースは、アプリケーションの実行中に情報のビジュアルプレゼンテーションを制御することができ、ユーザがビジュアルプレゼンテーションをナビゲートしてビジュアルプレゼンテーションの文脈で情報を入力することを可能にする。ユーザインタフェースのタイプは、ユーザがコマンドをタイプするコマンド駆動（ｃｏｍｍａｎｄ−ｄｒｉｖｅｎ）インタフェース、ユーザがメニューから情報を選択するメニュー駆動インタフェース、およびその組合せから、通常はコンピュータのグラフィックス能力を利用し、ナビゲートするのがより柔軟、直観的、簡単であり、コマンド駆動およびメニュー駆動のビジュアルユーザインタフェースより魅力的な「ルックアンドフィール（ｌｏｏｋ−ａｎｄ−ｆｅｅｌ）」を有するＧＵＩまでの範囲に渡る。本明細書で使用されるときに、ユーザインタフェースまたはＧＵＩによって提示される情報のビジュアルプレゼンテーションを、それぞれ「ユーザインタフェースディスプレイ」または「ＧＵＩディスプレイ」と称する。

ＷＩＴインタフェース１０８は、ユーザがＸＭＬファイルを手動で作成することを可能にするか、ユーザがワークアイテムタイプを定義できるようにする、より洗練されたユーザインタフェース（例えば、ＧＵＩ）を提供することができる。

しばらく図１からそれるが、図２に、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）フォーマットでのワークアイテムタイプ定義２００の例を示す。定義２００は、単にワークアイテムタイプ定義の例示的な実施形態であり、本発明の範囲を制限することを意図されたものではない。例えば定義２００の変形形態など、そのような定義の多数の他の実施形態のいずれであっても可能であり、本発明の範囲に含まれることが意図されている。例えば、定義２００はＸＭＬ形式で記述されているが、様々な他の適当なフォーマットのいずれであっても使用することができる。

定義２００は、例えばバグ（ｂｕｇ）、特徴（ｆｅａｔｕｒｅ）、要件（ｒｅｑｕｉｒｅｍｅｎｔ）、またはタスク（ｔａｓｋ）など、様々なタイプのワークアイテムのいずれでも定義することができ、名前フィールド（ｎａｍｅ ｆｉｅｌｄ）２０２；記述セクション（ｄｅｓｃｒｉｐｔｉｏｎ ｓｅｃｔｉｏｎ）２０６；フィールドセクション（ｆｉｅｌｄｓ ｓｅｃｔｉｏｎ）２１０；ワークフローセクション（ｗｏｒｋｆｌｏｗ ｓｅｃｔｉｏｎ）２１２；フォームセクション（ｆｏｒｍ ｓｅｃｔｉｏｎ）２１４；他のセクションおよびフィールド；またはこれらの任意の適当な組合せのいずれでも含むことができる。

名前フィールド２０２は、指定される値がチームプロジェクト（以下でより詳細に説明する）内で一意になるように構成されうる。名前の例に、バグ、特徴、要件、タスク、および他の名前を含めることができる。

記述セクション２０６は、ランタイムにワークアイテムタイプの概要が必要な時に使用することができるヘルプテキストを指定することができる。例えば図２では、記述セクション２０６で、「bug work item types are used to track defects within a code（ｂｕｇワークアイテムタイプはコード内の欠陥を追跡するのに使用される）」が指定されている。

フォームセクション２１４は、関連するフィールドがどのように表示され、エンドユーザによってどのように操作されるかを指定することができる。

フィールドセクション２１０は、ワークアイテムタイプに関連するセットのフィールドを指定する。いくつかの実施形態で、どのワークアイテムタイプも、ワークアイテムトラッキングシステムが正しく動作するようにするのに必要なコアフィールドのセットを備えることができる。他のフィールドは、特定のワークアイテムタイプ用にカスタマイズすることができる。いくつかの実施形態で、ワークアイテムタイプ定義の他所（例えば、フォームセクション２１４またはワークフローセクション２１２）で参照されるすべてのフィールドは、コア必須フィールドを除いて、まずフィールドセクション２１０で宣言されなければならない。フィールドは、次の情報を有することができる：名前（ｎａｍｅ）、参照名（ｒｅｆｅｒｅｎｃｅ ｎａｍｅ）、タイプ（ｔｙｐｅ）、ヘルプテキスト（ｈｅｌｐ ｔｅｘｔ）、および挙動（ｂｅｈａｖｉｏｒ）または制約（ｃｏｎｓｔｒａｉｎｔ）のセット。明示的にリストされる非コアフィールドは、暗黙のうちに、このワークアイテムタイプのすべてのインスタンス（例えば、ワークアイテム）について、空（ｅｍｐｔｙ）であり、読み取り専用とすることができる。

いくつかの実施形態で、フィールドルールのスコープ（ｓｃｏｐｅ）を、特定のユーザまたはユーザのグループに制限することができる。属性「ｆｏｒ」および「ｎｏｔ」を追加して、このスコープ指定をサポートすることができる。これらの属性は、それらを特定のグループに固有または特定のグループ以外の全員に固有にするためにタグで使用することができる。そのような「拒絶（ｄｅｎｙ）」を指定するフィールドルールは、「認可（ｇｒａｎｔ）」を指定するルールに優先するものとすることができる（以下で詳細に説明し、付録ＩＩで示すように、あるワークアイテムタイプ定義内の複数のルールが、１人または複数のユーザ、ユーザのグループ、ユーザのドメイン、全ユーザなどを指定することができる）。

図３に、ユーザのグループにスコープ指定されたフィールドルールを定義するワークアイテムタイプ定義のフィールドセクション３００の例を示す。図３のフィールドセクション３００は、「ｔｉｔｌｅ」という名前のフィールド（３０２）が、読み取り専用フィールドであり、［Ｐｒｏｊｅｃｔ］＼Ｔｅｓｔｅｒｓのメンバを除く全員にアクセスを提供することを指定している。フィールド３０４の「ｎｏｔ」が「ｆｏｒ」に置換された場合には、このルールは、Ｔｉｔｌｅフィールドが、同一のメンバについてアクセス可能な読み取り専用であるが、ほかの誰からもアクセス不能であることを指定する。

図４は、ワークアイテムタイプ定義のワークフローセクション４００の例を示す図である。ワークフローセクションは、有効な状態（ｓｔａｔｅ）、正しい遷移（ｔｒａｎｓｉｔｉｏｎ）、および遷移の正しい理由（ｒｅａｓｏｎ）を記述することができる。理由は、なぜユーザがある状態から別の状態に変更しようとしているかを識別することができる。いくつかの実施形態で、ただ１つの遷移がナッシング（ｎｏｔｈｉｎｇ）（すなわち、「」）から名前付き状態への遷移を定義でき、それによって、新しいワークアイテムの初期状態が識別される。さらに、どの遷移も、デフォルト理由フィールド４２０内でデフォルト理由を１つだけ定義することができる。ワークアイテムの最小のワークフローに、１つの状態、１つの遷移、および１つのデフォルト理由のみを含めることができる。

ワークフローセクション４００は、１つまたは複数の許容可能な状態４０４および４０６を定義する状態セクション４０２と、そのワークアイテムタイプの１つまたは複数の許容可能な遷移を定義する遷移セクション４０８を備えることができる。遷移セクション４０８内で、１つまたは複数の遷移、例えば遷移４１０および４１６を定義することができる。遷移４１０は、ナッシングから「ａｃｔｉｖｅ（アクティブ）」への初期遷移を定義し、ここで、理由セクション４１２は、デフォルト理由は値（ｖａｌｕｅ）が新しい（ｎｅｗ）ときであることを示す、デフォルト理由４１４だけを備える。遷移４１６は、「Ａｃｔｉｖｅ」から「Ｃｏｍｐｌｅｔｅ（完了）」への遷移を指定している。遷移４１６には、理由セクション４１８に理由４２０および４２２が含まれている。理由４２０は、「ｄｅｆｅｒｒｅｄ（延期）」というデフォルト理由であり、理由４２２は、「ｎｏ ｐｌａｎｓ ｔｏ ｆｉｘ（修正の予定なし）」という理由を指定している。

いくつかの実施形態で、２つの状態の間のすべての正しい遷移を指定しなければならず、遷移が１つも指定されていない場合には、デフォルトは、この遷移を実行することを許可しない。さらに、２つの属性「ｆｏｒ」および「ｎｏｔ」を、ワークフローの遷移セクションでオプションとして使用して、誰が遷移の実行を許可されるかを洗練することができる。「拒絶」は、「許可（ａｌｌｏｗ）」に優先するものとすることができる。これらの属性のいずれも指定されていない場合、誰もがこの遷移を行うことを許可されうる（具体的には、そのワークアイテムを変更できる人全員）。

図５は、遷移ルール５００の例である。この遷移ルールは、「ｒｅｓｏｌｖｅｄ（解決済み）」から「ｃｏｍｐｌｅｔｅ（完了）」への遷移を、新しいテスタ（例えば、チームに参加したばかりのテスタ）を除くプロジェクトテスタ全員に制限する。遷移ルールは、個々のユーザアイデンティティを指定することもできる。

フィールドセクション、フィールドルール、ワークフローセクション、遷移、および遷移ルールを含むワークアイテムタイプ定義の他の例は、付録ＩＩでより詳細に説明される。

ワークアイテムトラッキングシステムの諸態様を、論理階層、例えばツリー様配置で編成することができる。論理階層の編成は、例えばビジネスプロダクトまたは会社構造など、別のエンティティの編成構造に対応するものとすることができる。論理階層は複数のレベルを備えることができ、最上位レベルは階層のルート（例えば、木の幹）である。階層のルートは、次に高いレベルに１つまたは複数の子ノードを有することができ、次に高いレベルのこれらのノードのそれぞれが、次に高いレベルに１つまたは複数の子ノードを有することができ、以下同様である。

図１に戻ると、ＷＩＴインタフェース１０８は、図２〜５に示されたようなワークフローアイテムタイプ定義をユーザが入力することを可能にすることができるが、ユーザが論理階層の特定のノード（例えば、ルートノード、またはより下のレベルのノードのいずれか）のワークアイテムタイプを定義することを可能にするように構成されうる。その結果、特定のワークアイテムタイプから作成される（すなわち、インスタンス化される）ワークアイテムは、この階層に関してそのワークアイテムタイプ自体と同一のスコープを有することができ、そのスコープは、このタイプが定義されたノードに対応する。すなわち、ワークアイテムタイプ定義およびそれに含まれるルールのスコープを、ワークアイテムトラッキングシステムの論理階層の特定のノードに制限することができる。以下でより詳細に説明する図６に、そのような論理階層、具体的にはプロダクトツリー６０２の例を示す。

セキュリティインタフェース１１２は、ユーザが１つまたは複数のセキュリティベースのワークアイテムルールを指定することを可能にするユーザインタフェースを提供することができ、ユーザがそのようなルールのスコープを論理階層（例えば、プロダクトツリー）内のノードに制限することを可能にすることができる。これらのルールは、特定のワークアイテムタイプと独立に定義することができる。ＷＩＴインタフェース１０８も、セキュリティに関してルールを定義することを可能にするが、ワークアイテムタイプのスコープ内でそれを行うことを理解されたい。

図６は、ユーザがプロダクトツリーのノードを選択することを可能にするために、ユーザに提供できるユーザインタフェースディスプレイ６００の例を示すスクリーンショットである。いくつかのワークアイテムトラッキングシステムで、プロダクトツリーは、最初の（すなわち、最高の）レベルのルートノードを有することができ、これは、プロダクト全体および／またはＭＶＳ「ソリューション」に対応するものとすることができる。このプロダクトツリーの第２のレベルの各ノードは、プロダクトおよび／またはソリューション内の１プロジェクトに対応するものとすることができ、プロジェクトノードの各子ノードは、その親プロジェクトのサブコンポーネント（例えば、プロダクトの特徴、またはプロダクトの他の態様）に対応するものとすることができる。

ツリー部分６０２は、「Ｐｒｏｊｅｃｔ Ｍｏｄｅｌ Ｈｉｅｒａｒｃｈｙ」という名前のプロジェクトノード６０４を先頭とするプロダクトツリーの、第２のレベルのプロジェクトを表すことができ、プロジェクトノード６０４は、２つの子ノード６０６（「ｎｏｄｅ １」）および６０８（「ｎｏｄｅ ２」）を有する。ノード６０６は、２つの子ノード６１０（「Ｎｏｄｅ １＿Ｃｈｉｌｄ １」）およびノード６１２（「Ｎｏｄｅ １＿Ｃｈｉｌｄ ２」）を備える。ディスプレイ６００は、ユーザがツリー部分６０２（およびおそらくはこのツリーの残り）をナビゲートし、ノードのうちの１つ、例えばノード６０６を選択することを可能にするように構成されうる。セキュリティベースのワークアイテムルールを定義するために、ｐｅｒｍｉｓｓｉｏｎｓ（アクセス権）ボタン６１４を、階層６０２のノード（例えば、ノード６０６）を選択した後に１つまたは複数のセキュリティベースのルールを定義するというユーザの意図をユーザが示すことを可能にするように構成することができる。ユーザがｐｅｒｍｉｓｓｉｏｎｓボタン６１４を選択することに応答して、図７のディスプレイ７００を表示することができる。

図７は、ユーザが１つまたは複数のセキュリティベースのワークアイテムルールを指定することを可能にするユーザインタフェースディスプレイ７００の例を示すスクリーンショットである。ディスプレイ７００は、ユーザおよびグループ選択ウィンドウ７０２、ユーザおよびグループ追加パネル７０４、アクセス権ウィンドウ７０６、他のコンポーネント、およびそれらの任意の適当な組合せのいずれでも含むことができる。

選択ウィンドウ７０２は、ユーザが、セキュリティベースのワークアイテムルールを定義する対象であるユーザおよび／またはユーザのグループを選択することを可能にすることができる。例えば、ディスプレイ７００では、ユーザ「ＲＥＤＭＯＮＤ＼ａｍｉｔｇｈ」が選択されている。

追加パネル７０４を、ユーザが、選択ウィンドウ７０２に追加されるユーザおよびユーザのグループを検索し、選択することを可能にするように構成し、したがってそれらのものをセキュリティベースのルールについて選択できるようにすることができる。いくつかの実施形態で、パネル７０４は、例えばＷｉｎｄｏｗｓ（登録商標）のユーザもしくはグループおよび／またはＴｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒのユーザもしくはグループなどの、ユーザおよびグループの１つまたは複数のソースを検索することを可能にされうる。

アクセス権ウィンドウ７０６は、ユーザが、ウィンドウ７０２で選択されたユーザおよびグループに対して、１つまたは複数のセキュリティベースのワークアイテムルールを指定することを可能にする。例えば、ユーザは、ユーザまたはグループによる特定のアクションが許可されるか拒絶されるかを指定することを可能にされうる。例えば、ウィンドウ７０６に示されているように、ユーザは、ユーザまたはグループが、（とりわけ）現在選択されているノードのワークアイテムを編集し、および／または現在選択されているノードのワークアイテムを表示することを許可または拒絶されることを指定することを可能にされうる。アクセス権ウィンドウ７０６は、例えばユーザが選択されたノード自体を編集すること（７０８）を許可することなど、ユーザが、ワークアイテムルールに必ずしも関連しないアクセス権を定義することを可能にするように構成されることもできる。

図８は、ユーザが１つまたは複数のセキュリティベースのワークアイテムルールを指定することを可能にするユーザインタフェースディスプレイ７００’の例を示すスクリーンショットである。ディスプレイ７００’に、ユーザおよびグループ選択ウィンドウ７０２、ユーザおよびグループ追加パネル７０４、アクセス権ウィンドウ８０６、他のコンポーネント、およびそれらの任意の適当な組合せのどれでも含めることができる。ディスプレイ７００’は、根本的にはディスプレイ７００と同一であるが、ユーザが、ディスプレイ７００’のウィンドウ８０６でより多くのアクセス権を指定していることが異なる。具体的に言うと、ユーザは、ウィンドウ７０２で選択されたユーザ（「ＲＥＤＭＯＮＤ＼ａｍｉｔｇｈ」）が、このノードのワークアイテムの編集を許可されない（すなわち、拒絶される)（８０９）が、このノードのワークアイテムを表示することを許可される（８１１）ことを指定している。

ディスプレイ６００を、ワークアイテムタイプと独立のセキュリティベースのワークアイテムルールの定義に関して説明したが、これまたは類似するディスプレイが、それについて１つまたは複数のワークアイテムタイプが定義されるノードをユーザが選択できるエントリポイントとして働くことができる。すなわち、ディスプレイ６００または類似するディスプレイは、プロダクトツリーのノードを指定するナビゲーションツールとして働くことができ、それについて１つまたは複数のワークアイテムタイプルールのスコープが指定される。

したがって、上で説明したように、ＷＩＴインタフェース１０８は、特定のワークアイテムタイプにスコープを制限された１つまたは複数のワークアイテムルールをユーザが定義することを可能にするように構成されることができ、その特定のワークアイテムタイプは、おそらくプロダクトツリーなどの論理階層の特定のノードにスコープを制限されうる。また、セキュリティインタフェース１１２は、セキュリティベースである（すなわち、ユーザまたはユーザのグループに固有の）１つまたは複数のワークアイテムルールをユーザが定義することを可能にするように構成されることができ、そのワークアイテムルールは、おそらくプロダクトツリーなどの論理階層の特定のノードにスコープを制限されうる特定のワークアイテムタイプと独立である。これらのタイプのルールの両方を、ワークアイテムに影響する（例えば、ワークアイテムにアクセスし、および／またはこれを変更する）ユーザアクションに応答して実施することができる。ユーザは、これから説明するワークアイテムインタフェース１１０によって、ワークアイテムに影響するユーザアクションを行うことを可能にされうる。

図９は、ワークアイテムを作成し、および／または変更するためのユーザインタフェースディスプレイ９００の例を示すスクリーンショットである。ディスプレイ９００は、ワークアイテムルールにアクセスし、および／またはこれを変更するユーザインタフェースディスプレイの単なる例であり、本発明の範囲を制限することを意図されたものではない。例えばディスプレイ９００の変形形態など、様々な他のディスプレイのいずれでも使用することができ、本発明の範囲に含まれることが意図されている。

ディスプレイ９００は、作成される「ｂｕｇ」というワークアイテムタイプの例を示すことができる。このワークアイテムは、フォルダタブ９０２によって示されているように、名前「ｎｅｗ ｂｕｇ」を有することができる。さらに、このワークアイテムは、割り当て（ａｓｓｉｇｎｍｅｎｔ）フィールド９０４、優先順位（ｐｒｉｏｒｉｔｙ）フィールド９０６、状態（ｓｔａｔｅ）フィールド９０８、および理由（ｒｅａｓｏｎ）フィールド９１０によってそれぞれ示されるように、ユーザ「ａｍｉｔｇｈ」に割り当てられ、「２」の優先順位を有し、「ｎｅｗ」なので「ａｃｔｉｖｅ」状態であるものとすることができる。ユーザは、記述ウィンドウ９１４に「ｔｅｓｔ ｅｄｉｔ（テスト編集）」という説明を入力し、ワークアイテムを保存するように指示し終えたものとすることができる。しかし、このユーザは、タイトルフィールド９１２にタイトルを入力しなかったので、エラーメッセージ（例えば、「Save failed. The value for field 'title' must NOT be emptied.」（保存失敗。フィールド「ｔｉｔｌｅ」の値を空にすることはできません。））を、エラーメッセージウィンドウ９１６でユーザに表示することができる。ユーザがフィールド９１２に値を入力せずにワークアイテム「ｎｅｗ ｂｕｇ」の保存を試みることに応答してそのようなエラーメッセージを表示することは、例えばＷＩＲエンジン１１４（以下でより詳細に説明する）による、１つまたは複数のワークアイテムルールの実施の結果とすることができる。例えば、ワークアイテムタイプルールが、例えば上で図２〜５に関して説明したように、ユーザ「ａｍｉｔｇｈ」、このユーザが属するグループ、または全ユーザについて、タイトルフィールド９１２に値が必要であることを指定しているものとすることができる。

図１に戻ると、クライアントＷＩＲエンジン１１４は、ワークアイテムに影響するユーザアクションに応答してワークアイテムルール（ワークアイテムタイプルールおよび／またはセキュリティベースのルールを含む）を実施するように構成されうる。例えば、エンジン１１４は、影響されるワークアイテムに対応する１つまたは複数のワークアイテムルールを判定し、判定された１つまたは複数のワークアイテムルールを解釈し、その解釈に基づいてユーザアクションに応答するように構成されうる。

影響されるワークアイテムに対応する１つまたは複数のワークアイテムルールの判定は、そのワークアイテムにアクセスし、および／またはこれを変更しているユーザ、そのワークアイテムが対応する論理階層（例えば、プロダクトツリー）のノード、およびそのワークアイテムのワークアイテムタイプに対応するすべてのワークアイテムルールを識別することを含むことができる。これらのルールを、ＷＩＲキャッシュ１１６に保管することができ、ＷＩＲキャッシュ１１６は、システム１００に関連するワークアイテムルールのすべてをキャッシングすることができる。ＷＩＲキャッシュ１１６のソースは、データソース１２６のＷＩＲ情報１３０とすることができる。システム１００の任意のＷＩＴＳクライアント上でワークアイテムインタフェース（例えば、インタフェース１０８）、セキュリティインタフェース（例えば、１１２）、または他の手段（例えば、必要なルールまたはコアルールに関するプログラマのシステム管理者によって）を介して定義されたワークアイテムルールは、データソース１２６などの１つまたは複数の集中位置に（例えば、ＷＩＲ情報１３０として）保管されうる。これらのＷＩＲルールを、そのようなＷＩＴＳクライアントの１つまたは複数でキャッシングすることができる。

判定された１つまたは複数のワークアイテムルールの解釈は、判定されたルールをある形で組み合わせることを含むことができる。例えば、ディスプレイ６００のツリー部分６０２を参照すると、セキュリティベースのルールおよびワークアイテムタイプルールを定義し、したがって、ノード６０４、６０６、６０８、６１０、および／または６１２を含むツリー部分６０２の様々なレベルでスコープを指定することができる。クライアントＷＩＲエンジン１１４は、ユーザ、ノード、およびワークアイテムタイプの識別を入力として使用して、これらの入力（およびおそらくは他の情報）に基づいて判定されたルールのすべてを評価し、この評価に基づいて、ユーザアクションが許可されるかまたはユーザアクションの少なくとも一部が拒絶されるかを判定することができる。

このルールの評価または解釈は、様々な形のいずれかで実行することができる。例えば、いくつかの実施形態で、論理階層の所与のノード（例えば、ツリーノード）について定義されたルールは、その論理階層の下位ノードについて定義された競合するルールに優先する。いくつかの実施形態で、特定のユーザアクションに適用可能な複数のルールについて、肯定（例えば、アクションを許可する）と解釈される複数のルールの個数に関わりなく、または肯定と解釈されたルールが否定と解釈されたルールより論理階層内で上位であるという事実に関わりなく、ユーザアクションを拒絶するためには１つのルールが否定（例えば、アクションを拒絶する）と解釈されればよい。

例えば、プロダクトツリー部分６０２を参照して、次のシナリオを検討されたい。
１．ユーザ１が、グループＡのメンバである。
２．第１のセキュリティベースのルールは、グループＡのユーザがプロジェクトノード６０４のワークアイテムを編集することを許可されることを指定する。
３．第２のセキュリティルールは、ユーザ１がノード６０６のワークアイテムを編集することを許可されない（すなわち、拒絶される）ことを指定する。
４．プロジェクトノード６０４のノード６０６の下で、ユーザ１が、タイプ「ｂｕｇ」の第１のワークアイテムの優先順位フィールドの値に対する変更を保存することを試みる。

このシナリオについて、第１および第２のセキュリティベースのルールが、クライアントＷＩＲエンジン１１４によって判定されると仮定する。第１のセキュリティルールが、ノードツリー内の位置に起因して第２のセキュリティベースのルールより高い優先権を与えられる場合、第１と第２のセキュリティベースのルールの間のこの競合は、第１のセキュリティルールが第２のセキュリティルールをオーバーライドすることによって解決される。したがって、ユーザ１は、第１のセキュリティルールによって、優先順位フィールドの値を変更することを許可される。その代わりに、エンジン１１４が、ノードツリー内の位置に関わりなく、任意の拒絶が認可をオーバーライドするように構成されている場合には、第２のセキュリティベースのルールが適用される。したがって、ユーザ１は、第２のセキュリティベースのルールによって、ノード６０６のワークアイテムの編集を許可されないので、優先順位フィールドを変更することを許可されない。

第２のセキュリティベースのルールは存在しないが、ワークアイテムタイプルールが、ノード６０６のタイプ「ｂｕｇ」のワークアイテムについてグループＡのユーザは優先順位フィールドを編集することを許可されないことを指定する、第２のシナリオを検討されたい。第１のセキュリティルールが、プロダクトツリー内のその位置に起因して、優先権を与えられる場合に、第１のシナリオと同一の結果が達成され、ユーザ１は、優先順位フィールドの編集を許可される。逆に、任意の拒絶がアクセスのすべての認可をオーバーライドする場合には、ワークアイテムタイプルールは、ユーザ１がグループＡのメンバなので、ユーザ１が優先順位フィールドを編集することを許可されないことを命ずる。

ユーザアクションの拒絶としての１つまたは複数のルールの解釈のいずれかに応答して、そのユーザアクションを拒絶することができ、例えばディスプレイ９００に関して上で説明したメッセージウィンドウ９１６のメッセージに似たメッセージなどのメッセージを、ユーザに表示することができる。さらに、クライアントＷＩＲエンジン１１４は、例えば、ユーザに役立つメッセージを表示すること、フィールドに対して許可される値のリストを提供することなどによって、許可されるユーザアクションをユーザが実行するのを助けるように構成されうる。

エンジン１１４による１つまたは複数の判定されたルールの解釈がユーザアクションが許可されることである場合、エンジン１１４は、このトランザクションをＷＩＲクライアント／サーバインタフェース１２２に通信することができる。インタフェース１２２は、サーバＷＩＲエンジン１２４と、異なるＷＩＴＳクライアント（例えば、ＷＩＴＳクライアント１０２、１０４、および１０６）の１つまたは複数のクライアントＷＩＲエンジンとの間のインタフェースとしての役割を果たす（例えば、通信を調整する）ことができる。インタフェース１２２は、クライアントＷＩＲエンジン１１４から受け取ったトランザクションをサーバＷＩＲエンジン１２４に適当な形に変換し、変換されたトランザクションをエンジン１２４に送ることができる。

ＷＩＲエンジン１２４は、データソース１２６に保管されたＷＩＲ情報１３０に対するすべての内容書き込みを検証するように構成されることができ、また影響されるワークアイテムに対応するワークアイテムルールの第２の判定および解釈を実行することができる。トランザクションの受け取りに応答して、エンジン１２４は、ＷＩＲ情報１３０を使用して、ワークアイテムに対応する１つまたは複数のワークアイテムルール（例えば、セキュリティベースのルールおよび／またはワークアイテムタイプルール）を判定することができ、これらのワークアイテムルールは、１つまたは複数の表の各行が特定のルールを表す表形式で保管されうる。ルールは、他の形でも（例えば、オブジェクト指向データベース内のオブジェクトとして）保管されうる。

エンジン１２４は、判定されたルールからビュー（例えば、ＳＱＬビュー）を構成し、構成されたビューに基づいてルールを解釈するように構成されうる。例えば、サーバＷＩＲ１２４は、判定されたルールから生成された複数のＳＱＬステートメントを連結し、この連結されたＳＱＬステートメントを実行することによって、１つまたは複数の判定されたルールを解釈するように構成されうる。

サーバＷＩＲエンジン１２４がユーザアクションは許可されないと判定した場合、サーバＷＩＲエンジン１２４は、トランザクションをロールバック（ｒｏｌｌ ｂａｃｋ）し、そのトランザクションを開始したクライアントＷＩＲエンジンに拒絶およびロールバックを通信することができる。

クライアントＷＩＲエンジン１１４およびサーバＷＩＲエンジン１２４の両方でのワークアイテムルールの判定および解釈は、制限されたユーザのアクションが許可されないことを保証するためのある種の冗長性を提供することができる。これは、特にワークアイテムトラッキングシステムのコア要件に違反するユーザアクションを防ぐことによって、システム保全性を維持するのを助ける可能性がある。さらに、ＷＩＲ情報１３０は、クライアントＷＩＲエンジンによって使用されるＷＩＲキャッシュ（例えば、ワークキャッシュ１１６）内の情報より新しい可能性がある。というのは、ユーザアクションが行われたＷＩＴＳクライアントにまだ伝搬されていないワークアイテムルール更新が、ＷＩＴＳサーバによって他のＷＩＴＳクライアントから受け取られている場合があるからである。したがって、サーバＷＩＲエンジン１２４によって実行される判定および解釈は、クライアントＷＩＲエンジンによって行われる判定よりも新しいシステム１００の状態を反映している場合がある。

システム１００およびそのコンポーネントは、ソフトウェア（例えば、Ｃ、Ｃ＃、Ｃ＋＋、Ｊａｖａ（登録商標）、またはこれらの組合せ）、ハードウェア（例えば、１つまたは複数の特定用途向け集積回路）、ファームウェア（例えば、電子的にプログラムされたメモリ）、またはこれらの任意の組合せを含む様々なテクノロジのいずれかを使用して実装することができる。システム１００のコンポーネントのうちの１つまたは複数は、単一のデバイス（例えば、１台のコンピュータ）に常駐することができ、または、１つまたは複数のコンポーネントは、別々の別個のデバイスに常駐することができる。さらに、各コンポーネントを複数のデバイスに渡って分散させることができ、１つまたは複数のデバイスを相互接続することができる。

さらに、システム１００の１つまたは複数のコンポーネントを備える１つまたは複数のデバイスのそれぞれで、コンポーネントのそれぞれが、そのシステムの１つまたは複数の位置に常駐することができる。例えば、これらのシステムのコンポーネントの異なる部分が、デバイス上のメモリの異なる領域（例えば、ＲＡＭ、ＲＯＭ、ディスクなど）に常駐することができる。そのような１つまたは複数のデバイスのそれぞれは、他のコンポーネントの中でも、１つまたは複数のプロセッサ、メモリシステム、ディスクストレージシステム、１つまたは複数のネットワークインタフェース、および様々なコンポーネントを相互接続する１つまたは複数のバスまたは他の内部通信リンクとすることができる。システム１００およびそのコンポーネントを、以下で図１１および１２に関して説明するようなコンピュータシステムを使用して実装することができる。

図１０は、ワークアイテムトラッキングシステムでワークアイテムルールを実施する方法１０００の例を示す流れ図である。方法１０００は、単に、ワークアイテムトラッキングシステムのワークアイテムルールを実施する方法の例示的な実施形態であり、本発明の範囲を制限することを意図されたものではない。例えば方法１０００の変形形態など、そのような方法の多数の他の実施形態のいずれであっても可能であり、本発明の範囲に含まれることが意図されている。方法１０００およびその動作（ａｃｔ）は、上で図１に関して説明したシステム１００およびその部分を使用して実施することができる。

動作１００２で、１つまたは複数のセキュリティベースのルールおよび／または１つまたは複数のワークアイテムタイプルールを含む、１つまたは複数のワークアイテムルールを作成することができる。動作１００２は、図１のシステム１００に関して上で説明したＷＩＴインタフェースおよび／またはセキュリティインタフェースによって実行することができる。

動作１００４で、第１のワークアイテムに影響する第１のユーザアクションの表示を受け取ることができる。例えば、図１に関して上で説明したように、クライアントＷＩＲエンジン（例えば、エンジン１１４）が、ワークアイテムインタフェース（例えば、インタフェース１１０）から第１のユーザアクションの表示を受け取ることができる。

動作１００６で、第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定することができ、動作１００８で、これらの１つまたは複数のワークアイテムルールを解釈することができる。動作１００６および１００８は、システム１００に関して上で説明したように実行されることができる。システム１００に関して説明したように、動作１００６および１００８は、クライアントＷＩＲエンジン（例えば、エンジン１１４）およびサーバＷＩＲエンジン（例えば、エンジン１２４）の両方によって実行されることができる。いくつかの実施形態で、これらの動作が、これらのクライアントエンジンおよびサーバエンジンによって、わずかに異なる形で実行される場合がある。上で説明したように、サーバは、ワークアイテムルールの判定および解釈で、クライアントエンジンより新しいデータソースからのデータを使用することができ、クライアントエンジンと異なるテクノロジ（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬテクノロジ）を使用することができる。さらに、クライアントＷＩＲエンジンは、アクションを単純に拒絶するのではなく、例えば許容される値および／またはユーザが実行できるアクションをリストすることによって、許可されるユーザアクションをユーザが実行するのを助けることができる。対照的に、解釈に対するサーバＷＩＲエンジンの応答は、単に、アクションを拒絶することおよび／またはユーザアクションをカプセル化したトランザクションをロールバックすることとすることができる。

動作１０１０で、解釈に基づいて第１のユーザアクションに応答することができる。例えば、図１に関して上で説明したように、ユーザアクションを、クライアントＷＩＲエンジンによって拒絶と解釈されたので拒絶するか、クライアントＷＩＲエンジンによって許可と解釈されたがサーバＷＩＲエンジンによって拒絶と解釈されたので拒絶するか、クライアントおよびサーバのＷＩＲエンジンによって許可と解釈されたので許可することができる。

方法１０００は、追加アクションを含むことができる。さらに、方法１０００の一部として実行される動作の順序は、図１０に示された順序に制限されない。というのは、動作を他の順序で実行することができ、および／または１つもしくは複数の動作を少なくとも部分的に直列にまたは並列に実行できるからである。

方法１０００およびその動作、ならびにこの方法およびこれらの動作の様々な実施形態および変形形態は、個別にまたは組み合わせて、例えば不揮発性記録媒体、集積回路メモリ要素、またはその組合せなどの、１つまたは複数のコンピュータ読み取り可能な記録媒体に有形に具体化されるコンピュータ可読信号によって定義することができる。コンピュータ読み取り可能な記録媒体は、コンピュータによってアクセスできる任意の使用可能な媒体とすることができる。制限ではなく例として、コンピュータ読み取り可能な記録媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を保管するための任意の方法またはテクノロジで実装された、揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体を含む。コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、および他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、他のタイプの揮発性および不揮発性のメモリ、所望の情報を保管するのに使用でき、コンピュータによってアクセスできる他のすべての媒体、および前述の任意の適当な組合せが含まれるが、これに制限はされない。

通信媒体は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号内に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを具体化し、通信媒体には、すべての情報配布媒体が含まれる。用語「変調されたデータ信号」は、信号内に情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体、他のタイプの通信媒体、および前述のものの任意の適当な組合せが含まれる。

１つまたは複数のコンピュータ読み取り可能な記録媒体に具体化されたコンピュータ可読信号は、例えば、１つまたは複数のプログラムの一部として、コンピュータによる実行の結果として、そのコンピュータに、本明細書に記載の機能のうちの１つまたは複数（例えば、方法１０００またはその動作）および／または様々な実施形態、その変形形態、および組合せを実行させる命令を定義することができる。そのような命令は、例えば、Ｊａｖａ（登録商標）、Ｊ＃、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ、Ｃ＃、またはＣ＋＋、Ｆｏｒｔｒａｎ、Ｐａｓｃａｌ、Ｅｉｆｆｅｌ、Ｂａｓｉｃ、ＣＯＢＯＬなどの、複数のプログラミング言語のいずれかまたはこれらの様々な組合せのいずれかで記述することができる。そのような命令が具体化されたコンピュータ読み取り可能な記録媒体は、本明細書に記載のシステム１００および１１００のコンポーネントのうちの１つまたは複数に常駐することができ、そのようなコンポーネントのうちの１つまたは複数に渡って分散させることができ、それらの間で移行中とすることができる。

コンピュータ読み取り可能な記録媒体は、トランスポート可能とすることができ、それに保管された命令を任意のコンピュータシステムリソースにロードして、本明細書に記載の本発明の諸態様を実施することができる。さらに、上で説明したコンピュータ読み取り可能な記録媒体に保管された命令が、ホストコンピュータで動作するアプリケーションプログラムの一部として具体化された命令に制限されないことを理解されたい。そうではなく、この命令は、本発明の上で説明した諸態様を実施するようにプロセッサをプログラムするのに使用することができる任意のタイプのコンピュータコード（例えば、ソフトウェアまたはマイクロコード）として具体化することができる。

本明細書に記載の機能を実行する、例えば図１、１１、および１２に関して説明されるコンピュータシステムなどの、コンピュータシステムの単一のコンポーネントまたは複数のコンポーネントの集合のいずれも、一般に、そのような機能を制御する１つまたは複数のコントローラと考えることができることを理解されたい。１つまたは複数のコントローラは、専用のハードウェアおよび／またはファームウェアを用いて、上に記載の機能または前述のものの任意の適当な組合せを実行するようにマイクロコードまたはソフトウェアを使用してプログラムされたプロセッサを使用して、多数の形で実装することができる。

本発明による様々な実施形態は、１つまたは複数のコンピュータシステムで実施されることができる。これらのコンピュータシステムは、例えば、Ｉｎｔｅｌ ＰＥＮＴＩＵＭ（登録商標）タイププロセッサ、Ｍｏｔｏｒｏｌａ ＰｏｗｅｒＰＣ、Ｓｕｎ ＵｌｔｒａＳＰＡＲＣ、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ ＰＡ−ＲＩＳＣプロセッサ、ＡＭＤ（Ａｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ）社から入手可能な様々なプロセッサのいずれか、または任意の他のタイプのプロセッサに基づくものなどの、汎用コンピュータとすることができる。任意のタイプのコンピュータシステムのうちの１つまたは複数を使用して、本発明の様々な実施形態を実施できることを理解されたい。

本発明の一実施形態による汎用コンピュータシステムは、上で説明した機能のうちの１つまたは複数を実行するように構成されている。このシステムが他の機能を実行できることと、本発明がいずれかの特定の機能または機能のセットを有することに制限されないこととを理解されたい。

例えば、本発明の様々な態様を、図１１に示されたものなどの汎用コンピュータシステム１１００で実行される特殊化されたソフトウェアとして実装することができる。コンピュータシステム１１００は、ディスクドライブ、メモリ、またはデータを保管する他のデバイスなどの、１つまたは複数のメモリデバイス１１０４に接続されたプロセッサ１１０３を含むことができる。メモリ１１０４は、通常、コンピュータシステム１１００の動作中にプログラムおよびデータを保管するのに使用される。コンピュータシステム１１００のコンポーネントを、相互接続機構１１０５によって結合することができ、相互接続機構１１０５は、１つまたは複数のバス（例えば、同一のマシン内で一体化されたコンポーネントの間）および／またはネットワーク（例えば、別々の別個のマシンに常駐するコンポーネントの間）を含むことができる。相互接続機構１１０５は、通信（例えば、データ、命令）をシステム１１００のシステムコンポーネントの間で交換できるようにする。コンピュータシステム１１００は、例えば、キーボード、マウス、トラックボール、マイクロホン、タッチスクリーンなどの１つまたは複数の入力デバイス１１０２、および、例えば印刷デバイス、ディスプレイスクリーン、スピーカなどの、１つまたは複数の出力デバイス１１０１も含む。さらに、コンピュータシステム１１００は、コンピュータシステム１１００を通信ネットワークに接続する（相互接続機構１１０５に加えてまたはこれの代わりに）１つまたは複数のインタフェース（図示せず）を含むことができる。

図１２に詳細に示されるストレージシステム１１０６は、通常、コンピュータによって読み取り可能かつ書き込み可能な不揮発性記録媒体１２０１を含み、この不揮発性記録媒体１２０１に、プロセッサによって実行されるプログラムを定義する信号が保管され、あるいは、そのプログラムによって処理される情報が保管される。この媒体は、例えば、ディスクまたはフラッシュメモリとすることができる。通常、動作時に、プロセッサはデータを不揮発性記録媒体１２０１から別のメモリ１２０２に読み取らせ、これによって、プロセッサによる情報への媒体１２０１より高速のアクセスを可能にする。このメモリ１２０２は、通常は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）またはスタティックメモリ（ＳＲＡＭ）などの揮発性ランダムアクセスメモリである。これは、図示のようにストレージシステム１１０６に置くか、図示されていないメモリシステム１２０４に置くことができる。プロセッサ１１０３は、一般に、集積回路メモリ１１０４および１２０２内のデータを操作し、次に、処理が完了した後にそのデータを媒体１２０１にコピーする。媒体１２０１と集積回路メモリ要素１１０４および１２０２との間のデータ移動を管理する様々な機構が既知であり、本発明はそれに制限されない。本発明は、特定のメモリシステム１１０４またはストレージシステム１１０６に制限されない。

コンピュータシステムは、例えば特定用途向け集積回路（ＡＳＩＣ）などの、特別にプログラムされた特殊目的ハードウェアを含むことができる。本発明の諸態様は、ソフトウェア、ハードウェアもしくはファームウェア、またはその任意の組合せで実装することができる。さらに、そのような方法、動作、システム、システム要素、およびそのコンポーネントは、上で説明したコンピュータシステムの一部としてまたは独立のコンポーネントとして実装することができる。

コンピュータシステム１１００は、例として、本発明の様々な態様を実践できるコンピュータシステムの１タイプとして図示されているが、本発明の諸態様が、図１１に示されたコンピュータシステムで実装されることに制限されないことを理解されたい。本発明の様々な態様は、図１１に示されたものと異なるアーキテクチャまたはコンポーネントを有する１つまたは複数のコンピュータで実践することができる。

コンピュータシステム１１００は、高水準コンピュータプログラミング言語を使用してプログラム可能な汎用コンピュータシステムとすることができる。コンピュータシステム１１００は、特別にプログラムされた特殊目的ハードウェアを使用して実装することもできる。コンピュータシステム１１００内で、プロセッサ１１０３は、通常、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な周知のＰｅｎｔｉｕｍ（登録商標）クラスプロセッサなどの市販プロセッサである。多数の他のプロセッサが使用可能である。そのようなプロセッサは、通常、オペレーティングシステムを実行し、オペレーティングシステムは、例えば、本件特許出願人から入手可能なＷｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８、Ｗｉｎｄｏｗｓ（登録商標） ＮＴ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）２０００（Ｗｉｎｄｏｗｓ（登録商標）ＭＥ）、またはＷｉｎｄｏｗｓ（登録商標）ＸＰオペレーティングシステム、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ社から入手可能なＭＡＣ ＯＳ Ｓｙｓｔｅｍ Ｘ、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社から入手可能なＳｏｌａｒｉｓ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ、様々なソースから入手可能なＬｉｎｕｘ、または様々なソースから入手可能なＵＮＩＸ（登録商標）などとすることができる。様々な他のオペレーティングシステムのいずれであっても、使用することができる。

プロセッサおよびオペレーティングシステムが、一緒に、高水準プログラミング言語のアプリケーションプログラムが記述されるコンピュータプラットフォームを定義する。本発明が特定のコンピュータシステムプラットフォーム、プロセッサ、オペレーティングシステム、またはネットワークに制限されないことを理解されたい。また、本発明が特定のプログラミング言語またはコンピュータシステムに制限されないこと、および他の適当なプログラミング言語および他の適当なコンピュータシステムも使用できることは、当業者に明白であるだろう。

コンピュータシステムの１つまたは複数の部分を、通信ネットワークに結合された１つまたは複数のコンピュータシステム（図示せず）に渡って分散させることができる。これらのコンピュータシステムも、汎用コンピュータシステムとすることができる。例えば、本発明の様々な態様を、１つまたは複数のクライアントコンピュータにサービスを提供するように構成された１つまたは複数のコンピュータシステム（例えば、サーバ）、または分散システムの一部として全体的なタスクを実行するように構成された１つまたは複数のコンピュータシステムの間で分散させることができる。例えば、本発明の様々な態様を、本発明の様々な実施形態に従って様々な機能を実行する１つまたは複数のサーバシステムの間で分散されたコンポーネントを含むクライアント−サーバシステムで実行することができる。これらのコンポーネントは、通信プロトコル（例えば、ＴＣＰ／ＩＰ）を使用して通信ネットワーク（例えば、インターネット）上で通信する実行可能コード、中間（ｉｎｔｅｒｍｅｄｉａｔｅ）（例えば、ＩＬ）コード、または解釈済み（ｉｎｔｅｒｐｒｅｔｅｄ）（例えば、Ｊａｖａ（登録商標））コードとすることができる。

本発明が特定のシステムまたはシステムのグループで実行されることに制限されないこと、および本発明が特定の分散アーキテクチャ、ネットワーク、または通信プロトコルに制限されないことを理解されたい。

本発明の様々な実施形態を、ＳｍａｌｌＴａｌｋ、Ｊａｖａ（登録商標）、Ｊ＃（Ｊシャープ）、Ｃ＋＋、Ａｄａ、またはＣ＃（Ｃシャープ）などのオブジェクト指向プログラミング言語を使用してプログラムすることができる。他のオブジェクト指向プログラミング言語も使用することができる。あるいは、機能プログラミング言語、スクリプトプログラミング言語、および／または論理プログラミング言語を使用することができる。本発明の様々な態様を、非プログラム式（ｎｏｎ−ｐｒｏｇｒａｍｍｅｄ）環境（例えば、ブラウザプログラムのウィンドウで表示された時に、グラフィカルユーザインタフェース（ＧＵＩ）の諸態様をレンダリングするか他の機能を実行する、ＨＴＭＬ、ＸＭＬ、または他のフォーマットで作成された文書）で実装することができる。本発明の様々な態様を、プログラム式要素または非プログラム式要素、あるいはその任意の組合せとして実装することができる。さらに、本発明の様々な実施形態を、本件特許出願人から入手可能なＭｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴテクノロジを使用して実装することができる。

本発明のいくつかの例示的な実施形態を説明したので、前述したものは単に例示的であって制限的ではなく、例としてのみ提示されたことが、当業者には明白であるだろう。多数の修正形態および他の例示的実施形態が、当技術分野の通常の技量を有するものの範囲内であり、本発明の範囲に含まれることが企図されている。具体的には、本明細書で提示された例の多くが、方法動作またはシステム要素の特定の組合せを用いるが、これらの動作およびこれらの要素を異なる形で組み合わせて、同一の目的を達成できることを理解されたい。一実施形態に関してのみ説明された動作、要素、および特徴は、他の実施形態における類似する役割から除外されることを意図されていない。さらに、請求項に記載の１つまたは複数の特定の機能を実行する手段の範囲の制限に関して、手段は、記載された機能を実行するための、本明細書で開示された手段に制限されることを意図されているのではなく、記載された機能を実行する、現在既知のまたは後に開発される任意の同等の手段を範囲に含むことが意図されている。

「第１の」、「第２の」、「第３の」などの順序を示す単語を請求項要素を限定するために請求項において使用すること自体は、別の請求項要素に対するある請求項要素の優先、優位、または順序、あるいは方法の動作が実行される時間的順序を暗示するのではなく、単に、ある名前を有するある請求項要素を（順序を示す単語の使用を除いて）同一の名前を有する別の要素から区別し、請求項要素を区別するための符号として使用されている。

付録Ｉ
設計文書
ビジネスルールの説明および使用
目次
要約
設計目標および正当化
設計
ルールの評価
個々のルール
アイテム
フィールド
ツリーノード
定数および定数のセット
セキュリティおよび修飾（ｑｕａｌｉｆｉｃａｔｉｏｎ）の実施のバイパス
ａｄｍｉｎ ｏｎｌｙサブツリー
クライアントサイドルール評価エンジンの実装および制限
パフォーマンスアイテム
プログラム化可能性
ルールを操作し使用するストアドプロシージャ
ルールを操作するストアドプロシージャ
プロダクトツリーを操作するストアドプロシージャ
プロダクトフィールドを操作するストアドプロシージャ
プロダクトルールを作成するＳＱＬのサンプル
ルールのサンプル
ノーダッシュ（ｎｏ−ｄａｓｈ）ドメインユーザに対する全アイテムについてのリスト読み取りアクセス権の許可
リストの１つへのノードタイプの制約
エリアタイプノードはサブエリアタイプノードまたはコンポーネントタイプノードを子として有することができる
「Ｒｅｄｍｏｎｄ＼ｐｓｔｅｓｔ」のメンバは、ノード１２をルートとするプロダクトツリーの枝の「Ｆｏｌｄｅｒ」タイプでないノードを作成することができない
タイトルは、全員の必須フィールドである
誰もが、かれらがオープンしたすべてのアイテムを読むことができる
Ｗａｒはダイナミックリストである
Ｃｌｏｓｅｄ Ｄａｔｅは、状態がクローズドでない時について空でなければならない
「Ｒｅｄｍｏｎｄ＼ｍａｒｋｒａｄｐ」配布リストのすべてのドメインユーザは、どこでも何でも行うことができる

（要約）
ルールは、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒのワークアイテムトラッキングのランタイムコンフィギュレーションの主要なソースである。ルールは、フィールドによって提供される柔軟性を拡張して、プロジェクトまたはサーバの寿命の間、管理者の未知のおよび変化するビジネスニーズを記述し、実施する。単一の機構が、これらのニーズに使用され、サーバの内容のセキュリティおよび保全性をカバーする。ルールは、クライアント、中間（Ｍｉｄ）、およびデータという、このアーキテクチャのすべてのティアの間で共有できるビジネスルールの定義を提供する。これらのルールは、宣言的（規定的でなく）であり、したがって、各ティアがその特定の環境に適当であるようにこれらのルールを解釈することができる。

ＢＲＩＥは、Ｐｒｏｄｕｃｔ Ｓｔｕｄｉｏ Ａｐｐｌｉｃａｔｉｏｎの一部として始まり、進化してＴｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒのワークアイテムトラッキングの一部になった。

（設計目標および正当化）
目標は、
１）ワークアイテムトラッキングシステムで必要なビジネスルールを記述でき、
２）各プロダクトフィーチャの管理を委任できると同時に、より高いレベルの判断がより低いレベルで逆転またはバイパスされることを防ぐようにするためにプロダクトツリーを活用でき、
３）プロダクトツリーおよびドメイングループ／ユーザに基づくセキュリティセッティングを提供でき、
４）将来の要件を自然な形で追加できるのに十分にオープンエンデッドとすることができ、
５）許容不能に低速でないとすることができる
豊富なセットのプリミティブを提供することであった。

（設計）
セキュリティおよびビジネスルールの実施は、中間ティアとデータティアとの間で共有される協力的努力である。それぞれが、非常に重要な態様について他方に頼り、どちらもが、単独では完全に効果的ではない。

誰が何をするかの短い概要を次に示す。
１）中間ティアは、Ｗ２０００統合認証を使用してドメインアカウントを識別する。
２）中間ティアは、この情報を使用して、データ読み取りにどのデータティアプリミティブを使用するかを判断する。
３）データ変更（挿入／更新）について、中間ティアは、
ａ）データティアプリミティブを使用してドメインユーザの内部ＩＤを見つけ、
ｂ）この内部ＩＤを、それが変更するすべての行に保管し、
ｃ）データティアプリミティブを呼び出して、それが行ったばかりの変更をオーソライズし、
ｄ）何かが不首尾になった場合にトランザクションをロールバックする。
４）データティアは、セキュリティ環境を反映するドメインユーザごとのパーソナライズされたＳＱＬビューを作成し、組み合わせることによって、「オーソライゼーション」プリミティブを提供する責任を負う。セキュリティ環境は、
ａ）アクティブディレクトリからインポートされ、データベース内にキャッシングされたドメインアカウント情報と、
ｂ）現在のルール（「セキュリティ」、アイテム内容、および管理者データ内容をカバーする）
からなる。
５）低優先順位バックグラウンドタスクとして（クライアントクエリおよび更新などの有用なタスクのために大量のＣＰＵを保存するために）、データティアは、
ａ）アクティブディレクトリからのユーザおよびグループメンバの情報を検証し、そのキャッシュを更新し、
ｂ）セキュリティ環境の変更を組み込むために個々のドメインユーザのＳＱＬビューを更新する。

ルールの評価
擬似コードでは、あるアイテムのプロダクトルール評価が、
１．セキュリティプリンシパル（これを行う人）に適用されるすべてのルールを識別し、
２．セキュリティ対象（そのアイテムがあるプロダクトツリー内のノード）に適用されるすべてのルールを識別し、
３．そのアイテムの内容を使用してルールを評価する。

動作を拒絶するルールのいずれかが真と評価されるか、動作を許可するルールのすべてが真と評価されない場合に、その動作は拒否される。

１つの拒絶の理由が、任意の個数の許可する理由より高い地位を占める。これが、許可／拒絶システムの標準である。

アイテムに対する変更のすべてが、すべてのフィールドに関するルールの再評価を引き起こすことに留意することが重要である。あるフィールドに対する変更によって他のフィールドが影響を受けるかどうかを判定する最も簡単な形は、他のすべてのフィールドの許可される値および提案される値のリストを再生成することである。これは、「ジャストインタイム（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）」で行うことができる。

ＳＱＬ Ｓｅｒｖｅｒ内で、ルールは、セキュリティプリンシパルに関するすべてのルールを（明示的にまたはセキュリティプリンシパルの直接のまたは間接のメンバシップのゆえにのいずれかで）識別することによって評価される。各適用可能なルールが、ＳＱＬビューに一緒にバンドリングされるＳＱＬ式として解釈される。セキュリティプリンシパルが動作を実際に実行する時に、そのプリンシパルの「パーソナルビュー」が、動作が拒絶されるすなわち許可されないかどうかを検出するのに使用される。その場合には、この動作をラップしたトランザクションが、ロールバックされる。これが機能するために、中間ティアは厳密なガイドラインに従わなければならない。

中間ティアオブジェクトは、信頼されるコンピューティングベースの一部である。しかし、中間ティアがどのように動作するかに対する前提を実施しようとする複数のデバッグトリガがある。これには、次が含まれる。
Ａ）中間ティアは、同一の変更者ＩＤおよびその変更の変更日付をすべての行に記録することによって、データベース変更をグループ化する。変更日付は、最初の変更が行われる前にとられた、ＳＱＬ ＳｅｒｖｅｒのＵＴＣシステムクロック時刻である。変更者ＩＤは、その変更がそれのためであるドメインアカウントのコンスタントＩＤ（ｃｏｎｓｔａｎｔ ＩＤ）である。０の変更者ＩＤは、アプリケーションが開始した変更である。ＵＴＣは、「Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ Ｃｏ−ｏｒｄｉｎａｔｅｄ」（協定世界時）である。これは、ほとんどの形でＧＭＴタイムゾーンの同義語であるが、ＵＴＣには「夏時間」がない。
Ｂ）読み取りは、特定のドメインアカウント用にパーソナライズされたＳＱＬビューを介して行われる。中間ティアは、ドメインアカウントの名前に基づいてビューを選択する。ビューが存在しない場合には、中間ティアが実行するＳＱＬバッチが、構文エラーを生成する。この場合に、中間ティアエラーパスが、ストアドプロシージャを呼び出して、欠けているパーソナルビューを再ビルドし、ＳＱＬ ｓｅｌｅｃｔを再試行する。
Ｃ）変更は、シリアライズ可能なトランザクション内で特定の順序で行われる。中間ティアは、最初からコミットまでのすべてを行うＳＱＬバッチを生成する。このトランザクションがストアドプロシージャによってロールバックされた場合に、そのＳＱＬバッチは、さらなるデータベース変更を行わずにリターンしなければならない。ＳＱＬ Ｓｅｒｖｅｒによるエラーの送出は、ＳＱＬバッチが終了（ｔｅｒｍｉｎａｔｅ）したことを意味しない場合がある。必要な順序（テーブル上のデバッグビルドトリガによって可能な限り実施される）は、次の通りである。

１）シリアライズ可能なトランザクションを開始する
２）セキュリティプリンシパルに関連するパーソナルビューを再ビルドする
３）すべての種類のアイテム変更（すなわち、依存リンク要求、撤回、受け入れ、および拒絶と、複製作成およびクリアと、関連するセットの追加および除去を含む）を行う
４）アイテム変更をオーソライズする
５）フィールド属性変更を行う
６）フィールド使用変更を行う
７）フィールド変更（属性および使用）をオーソライズする
８）ツリー変更を行う
９）ツリー変更をオーソライズする
１０）新しいルール定数を追加する
１１）ルールセット変更を行う
１２）ルール変更を行う
１３）＜必要に応じて他のメタデータ変更を追加する＞
１４）ルール変更をオーソライズする
１５）アイテム変更を適用する
１６）フィールド変更を適用する
１７）ツリー変更を適用して、展開されたツリーテーブルを再ビルドする
１８）ルール変更を適用する
ａ．古い展開されたセットテーブルを用いる再ビルドのためにパーソナルビューをマークする
ｂ．展開されたセットテーブルを再ビルドする
ｃ．新しい展開されたセットテーブルを用いる再ビルドのためにパーソナルビューをマークする
ｄ．古いパーソナル読み取りビューを除去して、中間ティアに、使用の時点でこれらを再ビルドさせる

個々のルール
プロダクトルールは、そのオブジェクトを指定しない。同一のプロダクトルールを、多数のオブジェクト、例えば、アイテムまたは管理者データに適用することができ、同一のプロダクトルールは、次からなる。
１）条件。条件は、論理Ｉｆ−Ｔｈｅｎ（別名インプライズ（ｉｍｐｌｉｅｓ））式である。
２）スコープ
３）使用フラグのセット

条件は、真または偽と評価される論理Ｉｆ−Ｔｈｅｎ（別名インプライズ（ｉｍｐｌｉｅｓ））式のエンコーディングである。部分式のそれぞれに、１つの「プロダクトフィールド」、１つの「ルール定数」、および１つの演算子が含まれる。評価は、オブジェクトの「プロダクトフィールド」の値に対して行われるが、定数は、ストリングである。演算子は、フラグの組合せによって判定される。ルールは、Ｒｅｖｅｒｓｅフラグにオンをセットすることによって、「Ｉｆ」部分と「Ｔｈｅｎ」部分を逆転することができる。これによって、ルールのうちでより表現力のあるＴｈｅｎ部分を、Ｉｆ部分であるかのように使用することが可能になる。その場合に、ルールは、「Ｔｈｅｎ−Ｉｆ」（逆インプライズ）になる。条件の「Ｔｈｅｎ」部分は、フィールドのドロップダウンのポピュレーション（ｐｏｐｕｌａｔｉｏｎ）を駆動するのに使用される。フィールドドロップダウンに影響するために、ルールは、条件に対する「Ｔｈｅｎ」部分を有しなければならない。

演算子は、フィールドの値と
１）ストリングへの数値ＩＤのマッピングからとられた単純なストリング
２）定数セット式の結果である定数
３）ルールが評価されている環境に依存する値をとる特別な定数
との間の比較に使用することができる。

使用可能な演算子は、次の通りである。
１．フィールド値と定数の間のストリング同等性。これは、定数が特別でない限り、演算子フラグをセットしない演算子である。
２．パターンが定数の展開からのストリングである場合のストリングパターンマッチ。値が真と評価されるために、値は、パターンのうちの１つだけに一致しなければならない。パターンマッチは、「Ｉｎ」セット演算子についてのみサポートされる。
３．特別な定数に出会った時には、必ず、特別なケースの処理にエスケープする。
４．ｆＴｈｅｎＣｏｎｓｔＬａｒｇｅＴｅｘｔフラグがセットされている時には、ＴｈｅｎＣｏｎｓｔＩＤと等しいＰｒｏｐＩＤを有するＴｒｅｅ Ｐｒｏｐｅｒｔｉｅｓテーブル内の行の大きいテキスト値を使用する。

コメント：ＴｒｅｅＰｒｏｐｅｒｔｉｅｓテーブルは、特定のＴｒｅｅＩＤ（ノード）のいくつかのプロパティを表す（ＴｒｅｅＩｄ、ＰｒｏｐＩｄ、Ｎａｍｅ、Ｖａｌｕｅ）エントリのセットを有する。ＰｒｏｊｅｃｔによるＰｒｅｓｅｎｔａｔｉｏｎ Ｆｏｒｍｓのスコープ指定は、Ｐｒｏｊｅｃｔ（ＴｒｅｅＩｄによって表される）のＰｒｅｓｅｎｔａｔｉｏｎ ＦｏｒｍをＴｒｅｅＰｒｏｐｅｒｔｉｅｓテーブルにＶａｌｕｅとして保管することによって行われる。フィールド「Ｖａｌｕｅ」は、テキストフィールドである（したがって、大きいテキストを保管することができる）。上の（４）で説明した演算子は、ＴｒｅｅＰｒｏｐｅｒｔｉｅｓテーブルからのＰｒｏｐＩＤを「Ｗｏｒｋ Ｉｔｅｍ Ｆｏｒｍ ＩＤ」フィールドに関連付けるのに使用される。ＴｈｅｎＣｏｎｓｔＩＤの値が、ＴｒｅｅＰｒｏｐｅｒｔｉｅｓテーブルから選択されなければならない大きいテキスト値であることを示すために、ルールでｆＴｈｅｎＣｏｎｓｔＬａｒｇｅＴｅｘｔフラグをセットしなければならない。

定数セット展開は、次の形で動作する。２つのフラググループが、セットが展開される時にどのノードがとられるかを定義する。
・ Ｌｅａｆグループ
○ ｆＴｈｅｎＬｅａｆ − 葉定数をとることを指示する
○ ｆＴｈｅｎＩｎｔｅｒｉｏｒ − 内側定数（別名、セット名）をとることを指示する
・ Ｄｅｐｔｈグループ
○ ｆＴｈｅｎＯｎｅＬｅｖｅｌ − 展開される定数の直接の子ノードをとることを指示する
○ ｆＴｈｅｎＴｗｏＰｌｕｓ − 間接的な子ノードをとることを指示する
展開されたセットに含まれる定数について、グループのそれぞれで少なくとも１つのフラグがセットされなければならない。

現在のデータベース実装は、上で述べたフラグの次の組合せだけをサポートする。
・ 定数のセットの直接メンバ（ｆＴｈｅｎＬｅａｆ＝１、ｆＴｈｅｎＩｎｔｅｒｉｏｒ＝１、ｆＴｈｅｎＯｎｅＬｅｖｅｌ＝１、ｆＴｈｅｎＴｗｏＰｌｕｓ＝０）。これをＭｅｍｂｅｒ演算子と呼ぶ。
・ ネストされたセットの名前を除く定数のセットの直接のおよび間接のメンバ、すなわちルート以外の、セットの展開からの葉ノードまたは外側ノードの、それぞれのストリング（ｆＴｈｅｎＬｅａｆ＝１、ｆＴｈｅｎＩｎｔｅｒｉｏｒ＝０、ｆＴｈｅｎＯｎｅＬｅｖｅｌ＝１、ｆＴｈｅｎＴｗｏＰｌｕｓ＝１）。これをｉｎ演算子と呼ぶ。
・ すべてのネストされたセットの名前を含む定数のセットの直接のおよび間接のメンバ、すなわちルート以外の展開からの内側ノードおよび外側ノード（ｆＴｈｅｎＬｅａｆ＝１、ｆＴｈｅｎＩｎｔｅｒｉｏｒ＝１、ｆＴｈｅｎＯｎｅＬｅｖｅｌ＝１、ｆＴｈｅｎＴｗｏＰｌｕｓ＝１）。これを「Ｉｎ Ｗｉｔｈ Ｓｅｔ Ｎａｍｅｓ」演算子と呼ぶ。

各演算子を否定（ｎｅｇａｔｅ）することができる。整数フィールドおよび日時フィールドは、評価のためにストリングに変換される。整数は、１０進数としてフォーマットされる。日時は、ＩＳＯ ８６０１（ＸＭＬで使用されるフォーマットすなわち、空白なしのｙｙｙｙ−ｍｍ−ｄｄＴｈｈ：ｍｍ：ｓｓ：ｍｍｍ）としてフォーマットされる。ルールで使用される多数の別個の整数および日時はなく、これらをストリング定数として保管することは、自然に、整数のセット、例えば１、２、５を収容する。セット演算に関して、ルール内の定数は、定数のセットの名前である。セットに、無制限の深さまで、ネストされたメンバとして他のセットを含めることができる。ネストされたセットの名前は、そのセットの名前がセットのメンバとして明示的に追加された場合を除いて、セットメンバとしてカウントされない。セット演算およびパターンマッチ演算は、「Ｔｈｅｎ」部分式に制限される。「Ｉｆ」演算子は、特別なケースとして処理されるか、値（予測可能な形でストリングに変換された）と定数ＩＤのストリングとの間の単純なストリング同等性である。

必ず真である縮退部分式は、「Ｎｏｔ ａ Ｆｉｅｌｄ」フィールドと「Ｎｏｔ ａ Ｃｏｎｓｔａｎｔ」別名「Ｕｎｋｎｏｗｎ Ｄｏｍａｉｎ Ａｃｃｏｕｎｔ」定数との間の部分式によって定義される。定数がセットに含まれるという評価とそれが含まれないという評価の間でセットメンバシップを評価する時に、区別が行われる。定数がセットに含まれると評価された時には、そのセットに、空の値およびターゲットオブジェクト内のフィールドの既存の値が暗黙のうちに含まれる。定数が除外されていると評価された時には、セットに追加される暗黙のメンバはない。

「Ｔｈｅｎ」式の演算子フラグを考えるもう１つの形は、ツリーのルートであるルール内の定数としてである。その「メンバ」は、そのルートの子である。ツリーのすべての外側ノード、別名葉ノードは、セットに「含まれる」。ツリーのすべてのノード（外側または内側）は、「セット名を有するセットに含まれる」。ルートノードのストリングは、それ自体に子葉ノードとして明示的に含まれない限り、必ず外部にある。これによって、ルートノードのこのストリングが、すべての演算子の結果に、または何もない時に追加される。

ルールは、出所に基づいてフィールドを区別することはしない。フィールドの値が、エンドユーザまたはサーバのどちらによってセットされたかは問題でない。ルールは、参照されるすべてのフィールドがターゲットに含まれる場合に限って適用可能である。あるフィールドの値を、ルールが評価される時に判定できない（例えば、値がサーバによって後でセットされ、ルールがクライアント側で評価されている）場合に、そのフィールドは、ターゲットオブジェクトについて使用不能と考えられる。

スコープは、ルールが適用されるサーフェイス（ｓｕｒｆａｃｅ）エリアの次元を制限する。ルールを適用するために、スコープのすべてがターゲットに適用されなければならない。１つの次元は、かかわるドメインユーザである。他の次元は、ターゲットアイテムの別個の態様である。ルールのスコープは、特定のドメインユーザか、デポ（ｄｅｐｏｔ）データベースにキャッシングされたドメイングループもしくは電子メール配布リストの全メンバに制限することができる。ドメインユーザの特定のセットを使用することもできる。

また、ルールのスコープは、「Ｒｏｏｔ Ｔｒｅｅ ＩＤ」および「Ｔｒｅｅ ＩＤ」を使用して、プロジェクト内またはサブプロジェクト内のアイテムに適用されるように指定される。「Ｔｒｅｅ ＩＤ」は、ツリー内の単一のノードまたは特定のノードをルートとするサブツリーとすることができる。「ｆｌｏｗ ｄｏｗｎ」フラグは、ルールが単一のノードに制限されている時には０である。「ｆｌｏｗ ｄｏｗｎ」フラグが非０である時には、ルールは、ツリー内の子孫ノードによって継承されているかのように振る舞う。ほとんどのルールが、このフラグをオンにされている。「ｆｌｏｗ ａｒｏｕｎｄ」フラグがオンの時に、ルールは、「Ｔｒｅｅ ＩＤ」のノードまたはサブツリー以外の、「Ｒｏｏｔ Ｔｒｅｅ ＩＤ」によって示されるプロジェクトまたはサブプロジェクト内のすべての場所に適用される。

ルールは、フィールドスコープ指定用の４つのスロットを有する。各スロットは、Ｆｉｅｌｄ ＩＤと、比較されるターゲットアイテムのフィールドの前の値および現在の値のうちの一方または両方とを有する。特別なケースとして、空の値をフィールドの前の値に使用して、値を有しないことからのフィールドの遷移をターゲットにすることができる。

使用フラグは、ルールが動作を許可または拒絶しなければならない時を示す。すべての動作が、「アイテム読み取り」、「アイテム書き込み」、および「管理者変更」という広義の分類に割り当てられる。関連するアイテムのセットへのアイテムの追加またはそれからのアイテムの除去は、追加されるアイテムまたはセットに含まれる他のアイテムに対する書き込みとは考えられない。ファイルのアタッチまたはリンクあるいはアイテム内のいずれかのフィールドの値の変更が、アイテム書き込みの一部である。新しいアイテムの作成は、アイテム書き込みと考えられる。アイテムを移動するために、セキュリティプリンシパルは、古い位置と新しい位置の両方に対する書き込みアクセス権を必要とする。条件が真と評価される時に変更アクションのアクセス権を拒絶するルールは、オブジェクトの修飾を定義する宣言的な形を提供する（修飾は、その結果が「良」として適格でないオブジェクト変更を拒否することである）。

クライアントとサーバの両方で評価されるこれらの必須ルール以外に、クライアント側だけで評価される他のルールがある。「提案」フラグをセットされているルールは、ユーザがターゲットで選択するのに「好ましい」値を定義する。「デフォルト」フラグをセットされているルールは、ユーザのために事前に選択される値を定義する。値（または値のリスト）は、ルールのＴｈｅｎ Ｃｏｎｓｔ ＩＤからとられる。提案またはデフォルトの対象であるフィールドは、「Ｔｈｅｎ Ｆｉｅｌｄ ＩＤ」である。適用される（Ｔｈｅｎ式が真と仮定される場合に真と評価される）すべてのルールの提案される値またはデフォルト値が組み合わされて、クライアントで提案されるか事前に選択される値の単一のリストがもたらされる。類似する機能性をＨｅｌｐテキストルールに使用して、文脈応答型ヘルプテキストを計算する。

次の定数は、プロダクトルール条件に使用された時に「特別な」解釈を与えられる。
○ 「Ｅｍｐｔｙ Ｖａｌｕｅ」
○ 「Ｗａｓ Ｅｍｐｔｙ Ｖａｌｕｅ」
○ 「Ｓａｍｅ Ａｓ Ｏｌｄ Ｖａｌｕｅ」
○ 「Ｎａｍｅ Ｏｆ Ｓｅｃｕｒｉｔｙ Ｐｒｉｎｃｉｐａｌ」
○ 「Ｏｌｄ Ｖａｌｕｅ Ｐｌｕｓ １」
○ 「Ｖａｌｕｅ ｆｒｏｍ ａ ｄｉｆｆｅｒｅｎｔ ｆｉｅｌｄ」
○ 「Ｓｅｒｖｅｒ’ｓ ｄａｔｅ／ｔｉｍｅ ｓｔａｍｐ」
○ 「Ｃｌｉｅｎｔ’ｓ ｄａｔｅ／ｔｉｍｅ ｓｔａｍｐ」
○ 「Ｏｌｄ ｖａｌｕｅ ｆｒｏｍ ａ ｄｉｆｆｅｒｅｎｔ ｆｉｅｌｄ」
これらの名前の大半は、自己説明的であるが、いくつかは、包括的サポートを保証するのに十分に一般的でないあるカスタマの特別な状況に対処するために任意であり、例えば「Ｎａｍｅ ｏｆ Ｓｅｃｕｒｉｔｙ Ｐｒｉｎｃｉｐａｌ」は、フィールドが、アクセス権を必要とするドメインアカウント名の値を有する時にアクセス権を許可／拒絶するのに使用される。

ルール自体が、ルールのターゲットである。プロダクトルールの使用フラグを変更することは、そのルールのスコープ内のすべてのツリーノードに対する管理者アクセス権を必要とする。あるルールは、編集可能でなく、「ｉｎ−ｔｈｅ−ｂｏｘ」で供給され、ランタイムに変更することができない。

Ａｒｅテーブルに埋め込まれたフィールドは、ヌルまたは０の長さである時に、バージョンについて空と考えられる。長いテキストヘルパテーブル内のフィールドは、長さが０もしくはヌルである時、またはそのバージョンについて行が存在しない時に、空である。

Ｐｒｏｄｕｃｔ Ｓｔｕｄｉｏアプリケーションは、管理者が直接に使用するかより大きいセットに含めることができる複数のセットも維持する。これには、次が含まれる。
□ ドメインアカウント − ＡＤ（Ｅｌｅａｄコンポーネント）のプロキシを介して公開された、現在有効であることがわかっているすべての電子メールニックネーム
□ ドメインユーザ − ユーザであることがわかっているドメインアカウントのサブセット
□ ドメイングループ − グループまたは配布リストであることがわかっているドメインアカウントのサブセット

アイテム
鍵になる概念は、「アイテム」である。これは、ほとんどのルールのターゲットである。アイテムは、Ａｒｅテーブル内の１つの行であり、このＡｒｅテーブルは、すべての「単一の値を有する」フィールド、すなわちコア、共通、およびカスタムについて、１つの列を有する。この行は、アイテムの最新バージョンである。Ｗｅｒｅテーブルがあり、このＷｅｒｅテーブルは、Ａｒｅテーブルと同一のレイアウトに加えて「Ｒｅｖｉｓｅｄ Ｄａｔｅ」列を有する。あるアイテムが更新される時に、Ａｒｅテーブルの行の古い内容が、Ｉｔｅｍｓ Ａｒｅテーブル行の新しい内容のＵＴＣ変更日付と共にＷｅｒｅテーブルに挿入される。ＡｒｅテーブルおよびＷｅｒｅテーブルを一緒にすることによって、アイテムの「単一の値を有する」フィールドのすべてのバージョンの完全なヒストリができる。ほとんどのクエリは、Ｉｔｅｍｓ Ａｒｅテーブルだけを用いる。これらのテーブルのほかに、複数の「拡張」テーブルがある。「単一の値を有する」フィールドでないすべてのＩｔｅｍフィールドの値は、これらのテーブルのうちの１つに送られる。Ｗｏｒｄｓ、Ｆｉｌｅｓ、Ｒｅｌａｔｅｄ Ｉｔｅｍｓ、およびＫｅｙｗｏｒｄｓの拡張テーブルがある（１つのフィールドに、一時に複数の値をセットすることができる）。拡張テーブルの各行は、特定のタイムスパンの間「有効」である。このタイムスパンは、拡張がその瞬間に「有効」である場合に、遠い将来に達する場合がある。この形で、各拡張テーブルが、すべてのＩｔｅｍｓの最新バージョンおよび置換されたバージョンの両方を有する。ルールは、Ｉｔｅｍｓの最新バージョンおよび以前のバージョンに関する。

フィールド
アイテムは、個々のフィールドからなる。各フィールドは、「フレンドリ名」、整数ＩＤ、およびフィールドストレージタイプを有する。「ストレージタイプ」のハードコードされたパレットがある。各フィールドは、これらのタイプのうちの１つである必要があるが、多数の別個のフィールドが同一のタイプを有することができる。

ストレージタイプは、次の通りである。
Ｄａｔｅ ｔｉｍｅ。これらは、Ａｒｅテーブルに埋め込まれる。例は、「Ｏｐｅｎｅｄ Ｄａｔｅ」または「Ｃｌｏｓｅｄ Ｄａｔｅ」である。
Ｉｎｔｅｇｅｒ。これらは、Ａｒｅテーブルに埋め込まれる。例は、「Ｂｅｔａ ＩＤ」である。
Ｄｏｕｂｌｅ。これらは、Ａｒｅテーブルに埋め込まれる。例は、「Ｐｅｒｃｅｎｔａｇｅ ｃｏｍｐｌｅｔｅｄ」であり、これは、値２５．２５をとることができる。
Ｋｅｙｗｏｒｄ。これらは、Ａｒｅテーブルに埋め込まれる。例は、「Ｓｔａｔｕｓ」または「Ａｓｓｉｇｎｅｄ Ｔｏ」である。これらは、一時に１つの値だけを選択できるラジオボックス機能性に使用される。
Ｗｏｒｄｓ。これらは、長いテキストである。これらは、ヘルパテーブルに保管される。例は、「Ｄｅｓｃｒｉｐｔｉｏｎ」または「Ｒｅｐｒｏ Ｓｔｅｐｓ」である。
Ｍｕｌｔｉ−ｖａｌｕｅｄ ｋｅｙｗｏｒｄ。これらは、ヘルパテーブルに保管される。例は、「Ｐｒｏｃｅｓｓｏｒ」または「ＯＳ」である。これらは、一時に多数の値を選択できるチェックボックス機能性に使用される。これらは、現在はＣｕｒｒｉｔｕｃｋに使用されていない。
Ｆｉｌｅｓ。これらは、ヘルパテーブルに保管される、例は、「Ａｔｔａｃｈｍｅｎｔ」または「Ｌｉｎｋｅｄ Ｆｉｌｅ」である。

Ａｒｅテーブルに保管されたフィールドとヘルパテーブルに保管されたフィールドの間の区別は、後者のフィールドがアイテムのバージョンごとに複数の値を有することができることである。しかし、すべてのフィールドのすべての値が、アイテムのすべてのバージョンについて使用可能であり、したがって、単純なフィールドを、プレゼンテーションレイヤによって多数の値を有するように見せることができ、例えば、表示される説明は、一緒に連結された各アイテムバージョンからの浅い説明の値の連結である。

各ストレージタイプは、それ自体のニュアンス（変化する量の実施を伴う）を有する。すべてのキーワード（ラジオ機能性とチェックボックス機能性の両方に関する）フィールドが、２５５の最大長を有する。フィールドは、タイプを変更することができないが、タイプの中での些細な調整を行うことができ、例えば、キーワードの最大長を後で増やすことができる。ファイルは、パスとディスプレイ名の両方を有することができる。フィールドは、すべてのオブジェクトでは使用できない場合があり、デポ管理者は、新しいフィールドを導入することができる。同一のフィールドが、多数のオブジェクトに現れることができる。

ツリーノード
プロダクトツリーは、単一辺を有するグラフである。これは、プロダクトツリーがノードからなることを意味する。各ノードは、その親にもどる１つのリンクを有する。ノードは、整数ＩＤによって識別される。ノードは、ルートノードを除いてそれ自体にリンクされず、ルートノードは、それ自体の親として働く。各ノードは、タイプおよび名前を有する。ノード名は、テーブル内で一意ではないが、兄弟ノードの間では一意に保たれる。すべてのアイテムが、１つのツリーノードに「置かれる」。ツリーノードは、削除済みまたはａｄｍｉｎ ｏｎｌｙとしてマークすることができる。削除済みノードは、アイテムを有することができず、その下のすべてのノードが、アイテムを有することができない。ツリーノードがａｄｍｉｎ ｏｎｌｙであるか、ａｄｍｉｎ ｏｎｌｙであるノードの下にある場合には、そのツリー位置でアイテムを作成するか変更するために、書き込みアクセス権のほかに管理者アクセス権が必要である。

ツリーノードは、ルールのターゲットにすることができる。具体的に言うと、ルールは、ツリーノードの「タイプ」属性を制御するのに使用される。管理者は、プロダクトルールを定義して、親ノードタイプの子ノードのタイプを制御することができる。プロダクトノードの「ｉｎ−ｔｈｅ−ｂｏｘ」タイプおよびそれらの間の関係も、ノードレベルタイプの間の暗黙の順序付けによって判定される。各ノードタイプは、それ自体で別個のフィールドタイプを有するフィールドになり、他のフィールドのように使用中または使用中でないとしてマークすることができる。ノードタイプの相対的「サイズ」（すなわち、どのノードタイプがノードタイプＴの子孫として受け入れ可能であるか）は、ノードタイプフィールドに割り当てられる数にエンコードされる。

定数および定数のセット
定数は、絶対にルールの対象ではない。定数は、ルールによって内部的に使用される整数ｉｄにストリングを関連付けるだけのために存在する。しかし、定数は、プロダクトデポの将来のバージョンをマルチリンガルにするためのフックを与える。

セットは、ルールの対象にすることができる。具体的に言うと、プロダクトルールによって参照されるセットのメンバの変更は、効果的にそのルールを変更することになる。セットの変更は、そのセットを直接にまたは間接に参照するすべてのルールを変更するために管理者アクセス権を必要とする。セットは、無制限の範囲までネストすることができる。特別な定数は、定数のセットのメンバにすることができない。

複数のセットが、アクティブディレクトリからのドメイン情報をキャッシングするのに使用される。そのメンバがすべてのドメインアカウントの名前である定数である１つのセットと、ドメインユーザの名前である定数のセットであるもう１つのセットがある。他のセットは、ドメインユーザを「ノーダッシュ」（フルタイム従業員）および「ダッシュ」（それ以外の全員）に分割する。定数が、ドメイングループまたは配布リストの名前である場合に、そのメンバシップは、「ベストエフォート」でアクティブディレクトリと同期化される。最小限でも、メンバシップは、朝までに同期化される。

管理者アクセス権は、計算フィールド「Ｃｈａｎｇｅｄ Ｓｅｔ」が保護される定数であるという条件のもとで管理者アクセス権を許可または拒絶することによって、定数またはその直接もしくは間接のメンバのストリングを変更するために必要とされることができる。「Ｃｈａｎｇｅｄ Ｓｅｔ」フィールドは、プロダクトルールの外では使用不能である。この機構は、重要な「ｉｎ−ｔｈｅ−ｂｏｘ」セットのメンバを変更する能力を、管理者アクセス権を有する人によってのみ変更できる他のセットのメンバに制限するのに使用される。所定のアクセス権を有する「ｉｎ−ｔｈｅ−ｂｏｘ」セットは、次の通りである。
・ 「Ａｄｍｉｎｉｓｔｒａｔｏｒｓ」 − ルートノードおよびその下に対する管理を許可する
・ 「Ｕｓｅｒｓ」 − ルートノードおよびその下に対する読み取り／書き込みを許可する
・ 「Ｇｕｅｓｔｓ」 − ルートノードおよびその下に対する読み取りを許可する

セキュリティおよび修飾（ｑｕａｌｉｆｉｃａｔｉｏｎ）の実施のバイパス
時々、書き込み（セキュリティと修飾の両方）の通常のオーソライゼーションを「バイパス」することができる必要がある。これをＣｕｒｒｉｔｕｃｋで行う形は、まだ未知である。１つの手法は、ユーザを「Ｗｒｉｔｅ Ａｌｌ」グループに追加するか、これから除去することを可能にすることであろう。このグループのメンバは、その書込動作についてセキュリティを実施されない。これは、そのメンバが読み取りセキュリティを実施されない既存の「Ｒｅａｄ Ａｌｌ」を補足するものである。

ａｄｍｉｎ ｏｎｌｙサブツリー
プロダクトツリーの一部を、そのサブツリーのルートノードのフラグをセットすることによって、「ａｄｍｉｎ ｏｎｌｙ」モードにすることができる。ａｄｍｉｎ ｏｎｌｙモードの時に、このサブツリー内の書込動作は、書き込みアクセス権に加えて、「ａｄｍｉｎ ｏｎｌｙ」サブツリー全体に対する管理者アクセス権を必要とする。

クライアントサイドルール評価エンジンの実装および制限
目標は、多くのコンテキストで使用できる、異なるタイプのオブジェクト（アイテム、ケースなど）用のエンジンを作成することであった。ＢＲＩＥインタフェースは、コールバックベースであり、したがって、実際のデータを得るために、ＢＲＩＥは、その呼出し側をコールバックする。これによって、ＢＲＩＥ呼出し側が、データをどのように取り出すかに関する柔軟な手法を使用することが可能になり、ＢＲＩＥがそのフィールドの値を必要とするルールに出会った時にオンデマンドで行うことができ、あるいは、呼出し側が、あるフィールドの値を取り出すことができないかそうしないことを望む場合にルール処理をスキップすることを選択することができる。

ＢＲＩＥは、現在の管理者キャッシュ状態によってパラメータ化される。すべてのルールおよび付随する管理者データが、管理者キャッシュから取り出される。キャッシュが変更された後には、ＢＲＩＥを再初期化しなければならない。

主要な機能性は、単一のエントリポイント（「ＡｃｃｅｓｓＣｈｅｃｋ」）に集中化されており、このエントリポイントは、セキュリティプリンシパルアクセストークン（プリンシパルを含むグループのセット＋プリンシパルに適用されるルールのセット）、アクセスを検査されるオブジェクト、必要なアクセスマスク（読み取り、書き込み、管理者）をとる。出力は、アクセスが許可されたかどうかのフラグと、オプションとして有効なアクセスマスクである。

ＡｃｃｅｓｓＣｈｅｃｋは、次の情報も出力することができる。
・ フィールドプロパティ − どの種類のルールがフィールドについて存在するかを示すフラグのセット。ＢＲＩＥは、フィールドプロパティを次のカテゴリに副分割する。
○ Ｆｏｒｂｉｄｄｅｎ − フィールド値がこのカテゴリのルールのどれかに一致する場合に、アクセスが拒絶される
○ Ｒｅｑｕｉｒｅｄ − フィールド値がこのカテゴリのどのルールにも一致しない場合に、アクセスが拒絶される
○ Ａｌｌｏｗｅｄ − フィールド値がこのカテゴリのルールと一致する場合に、アクセスが許可される（他のルールによって拒絶される場合がある）
○ Ｓｕｇｇｅｓｔｅｄ − 提案として働くルールに関するフラグのマスク
○ Ｎｏｔ ｓｕｇｇｅｓｔｅｄ − 否定の提案として働くルールに関するフラグのマスク
・ 値リスト／フォーマット − 上で説明したフィールドプロパティカテゴリに対応する、オプションの定数／フォーマットリスト
ＡｃｃｅｓｓＣｈｅｃｋアルゴリズムは、次のように動作する。
・ オブジェクト（アイテム、ツリーノードなど）から、プリンシパルがそれへのアクセスを要求したツリー位置を見つける。
・ 対象のタイプｉｄを見つける。
・ ａｄｍｉｎ−ｏｎｌｙフラグを有する場合に、要求されたアクセスに書き込みアクセスが含まれるならば、古い／新しいツリー位置をチェックする。
・ パーソンアクセストークンについて、セキュリティプリンシパルに適用されるすべてのルールを列挙する。
・ ルールごとに、次の条件のいずれかが満足されない場合に、そのルールをスキップする。
○ ルールのアクセス権利のどれもが、要求されたアクセスマスクに含まれない場合。
○ ルールで言及されたフィールドが、チェックされるオブジェクトタイプで使用されていない場合。
○ ルールの階層位置が提要されない場合に、そのルールをスキップする。
○ ルールで使用されているフィールドをオブジェクトから読み取る。ルールで言及されたフィールドのいずれかが欠けている場合には、そのルールをスキップする。
○ ルールを評価する。ルールがアクセスを拒絶し、呼出し側が有効なアクセスマスクを望まないかフィールドプロパティの計算を望まない場合には、即座にリターンする。そうでない場合には、ルールアクセスマスクをグローバル許可アクセスマスクまたはグローバル拒絶アクセスマスクに追加する。
○ いくつかのルール特殊化について、ルールのｔｈｅｎ部分であるフィールドを、強制的に要求された値にする（「値を強制的に空にする」、「値を強制的にＦＲＯＺＥＮにする」、「値を強制的にＲＥＡＤＯＮＬＹにする」など）。
○ すべてのルールを評価した後に、要求されたアクセスマスクに対してグローバル許可／拒絶マスクをチェックする。

特定のルールの評価は、次のように行われる。
・ フィールドプロパティが要求された場合に、ルール評価アルゴリズムは、ルールに望まれる結果を渡される。所望の結果は、アクセスフラグから演繹される。所望の結果およびルール式フラグ（ｆＵｎｌｅｓｓ、ｆＴｈｅｎＮｏｔ）に基づいて、このアルゴリズムは、ルールのターゲットカテゴリ（ｆｏｒｂｉｄｄｅｎ、ｒｅｑｕｉｒｅｄ、ａｌｌｏｗｅｄ、ｓｕｇｇｅｓｔｅｄ、ｎｏｔ ｓｕｇｇｅｓｔｅｄ）を選択する。
・ ルールを評価する。Ｉｆ部分を計算する。Ｉｆ部分が真である場合には、Ｔｈｅｎ部分を計算する。「Ｉｆ部分」は、２つの式すなわち、「Ｉｆ１」および「Ｉｆ２」の組合せである。欠けているどちらかの部分式は、部分式の成功と解釈される。両方の部分式が真と評価される場合に、「Ｉｆ部分」が真と評価されるという。
結果はＩｆ＝＞Ｔｈｅｎである。次の式アルゴリズムが使用可能である。
○ パターンマッチ
○ セットメンバシップ（Ｓｅｔ ｍｅｍｂｅｒｓｈｉｐ）
○ 同等性
○ 特別な式（ＣｏｄｅＤｅｆｅｃｔ特別定数などのハックを置くための拡張可能な場所）。
・ このアルゴリズムは、出会ったルールのタイプに関するフラグをセットする。フラグの例は、次の通りである。
○ 値が空であるかどうかをチェックするルール
○ 値が前と同一であるかどうかをチェックするルール
○ リストメンバシップをチェックするルール
○ パターンマッチをチェックするルール
○ リストメンバシップをチェックし、空のおよび古い値をとるルール
○ パターンマッチをチェックし、古い値をとるルール
○ ドメインユーザをとるルール
○ ドメイングループをとるルール
○ フィールドにデフォルトをセットするルール
○ 値をフィールドにコピーするルール
・ ルールが、望まれない結果に評価される場合には、フィールド状況フラグが、計算されたばかりのルールフラグと論理和をとられる。
・ 要求された場合に、値／フォーマットリストを作成する。

すべてのルールを評価した後に、特別な「外部」カテゴリを計算する。外部カテゴリは、値／フォーマット＋ＵＩ消費に関するプロパティを含むことが意図されている。外部カテゴリは、要求されたカテゴリが空白でない場合に要求されたカテゴリと等しく、そうでない場合にはａｌｌｏｗｅｄカテゴリおよびｓｕｇｇｅｓｔｅｄカテゴリの和集合である。次に、ｆｏｒｂｉｄｄｅｎカテゴリおよびｎｏｔ ｓｕｇｇｅｓｔｅｄカテゴリが、外部フィールドプロパティカテゴリから除かれる。

ＢＲＩＥは、無条件ルールという概念も有する。これは、Ｉｆ部分を０にされ、Ｔｈｅｎ部分が特別な「セキュリティプリンシパル」定数を有するか、やはり０にされているルールである。ＢＲＩＥは、オブジェクトに関する無条件アクセスチェックを行うことができる。無条件アクセスチェックは、通常のアクセスチェックと並列に行うこともできる。無条件アクセスチェックは、オブジェクトの内容変更を考慮せずにオブジェクトに関するアクセス権を計算するのに使用される。セキュリティ例外（Ａｓｓｉｇｎｅｄ ＴｏおよびＯｐｅｎｅｄ Ｂｙ）は、この機構を使用してサポートされる。ＢＲＩＥは、特定のオブジェクトタイプおよび特定のアクセスマスクに関して無条件アクセスチェックを行うためにどのフィールドが必要であるかを知らせることができるメソッドを公開する。ＢＲＩＥ呼出し側は、ルールを評価する時にこれらのフィールドを供給する責任を負う。

ＢＲＩＥは、ルール評価プロセスを容易にする少数のヘルパメソッドを提供する。
・ アクセストークンのビルド。ＡｃｃｅｓｓＣｈｅｃｋメソッドは、ＢＲＩＥ呼出し側がアクセストークンを使用してセキュリティプリンシパルを識別することを必要とする。ＢＲＩＥは、アクセストークンをビルドし、ＢＲＩＥ呼出し側は、アクセスがチェックされる時にそれを渡す責任を負う。アクセストークンを有することの主な理由は、冗長な計算の必要をなくすことである。アクセストークンには、セキュリティプリンシパルが属する定数セットのセットと、セキュリティプリンシパルに適用されるルールのセットが含まれる。
・ クエリビルダ用の提案される値の計算（ＦｉｅｌｄＩｎｆｏＡｌｌｏｗｅｄＶａｌｕｅｓ）。非常に単純なアルゴリズムが、それを行うのに使用される。用いられる、問題とされているフィールドを有するすべてのルールが処理される。ｆＩｆＮｏｔが０の時に、Ｉｆ部分からのすべての値がとられる。ｆＴｈｅｎＮｏｔ＾ｆＵｎｌｅｓｓ＾ＤｅｎｙＷｒｉｔｅが偽の時に、ＴｈｅｎＰａｒｔ部分からのすべての値がとられる。ツリーノードタイプも計算される。特別に処理されるフィールドは、ツリーフィールド、Ｎｏｄｅ Ｎａｍｅ、Ｎｏｄｅ Ｔｙｐｅ、およびＰｅｒｓｏｎ Ｎａｍｅである。
・ デフォルト値：「アイテム」の状態を与えられれば、ｂｒｉｅは、そのアイテムのフィールドのデフォルト値を計算することができる。
・ 計算フィールドの無効化。フィールドＩｄを与えられれば、ＢＲＩＥは、計算フィールドのどれが変化のゆえに影響を受けるかを知らせることができる。
・ 計算フィールドの計算。ＢＲＩＥは、次の計算フィールドの値を計算することができる。
○ ツリータイプフィールド
○ Ｎｏｄｅ Ｎａｍｅ
○ Ｎｏｄｅ Ｔｙｐｅ
○ Ｔｒｅｅ Ｐａｔｈ
○ Ｐｅｒｓｏｎ Ｎａｍｅ
また、ＢＲＩＥは、いくつかの読み取り専用フィールド（依存性関連フィールド、Ｒｅｇｒｅｓｓｉｏｎｓ）を計算することができない。これらの計算フィールドは、アイテムが保存された後に、中間ティアによって返される。

（パフォーマンスアイテム）
最大の問題は、暗黙のセットメンバシップを識別し、どのノードがプロダクトツリー内の他のどのノードの下にあるかを識別するハウスキーピングにある。これは、ドメイングループおよび配布リストに関するメンバシップ情報を同期化するコストと、アクティブディレクトリに対するすべてのドメインアカウントの継続する存在によって倍加される。より小さい懸念が、個々のドメインユーザについてＳＱＬビューを生成するコストと、それが古くなった（それがもはやルールおよびセットメンバシップを反映しないので）時の識別である。多数のビューを担持することに対するコストはほとんどないが、これらのビューを使用して、データベース変更をロールバックしなければならない時を検出すること、または読み取りに関してパーソナルビューを介してユーザｓｅｌｅｃｔをフィルタリングすることに関するコストがある。

いくつかの現在のルールエンコーディングの説明
１．Ａｓｓｉｇｎｅｄ ｔｏ例外を実装するルール（なくなる可能性がある）
Grant Write TO Authenticated Accounts under＼(a TF Server) within sub-tree＼(a TF Server) WHEN (Assigned To is *Special Constant* -10020)

このルールのエンコーディングは、次の通りである。
((dbo.StringInString (I.[Person Name],W.[Assigned To]) = 1
and
dbo.EmailIsVerified (W.[Assigned To],W.[Changed Date]) = 1
and
W.AreaID is not null
and
W.AreaID=I.AreaID))

これは、次をエンコードしている：変更を行う人（Ｉ．［Ｐｅｒｓｏｎ Ｎａｍｅ］によって表される）が、ｂｕｇが割り当てられているグループと同一またはそのグループのメンバであり、［Ａｓｓｉｇｎｅｄ ｔｏ］フィールドの値が有効な値であり、アイテムのツリー位置が有効であり、アイテムのツリー位置が変更されていない場合に、書き込みを許可する。

管理者更新についてバックエンドで使用される楽観的なロックに関する説明
Ａｄｍｉｎテーブルのタイムスタンプ列（Ｒｕｌｅｓなど）は、楽観的ロックを行うのに使用される。ロックを保持するのではなく、我々は、動作のセットの始めにＤＢのタイムスタンプを保管する。

我々は、トランザクションの分離レベルに「読み取りコミット済み（ｒｅａｄ ｃｏｍｍｉｔｔｅｄ）」をセットするが、これは、ある行からあるデータを読み取った後に、いくつかの他のトランザクションが到着し、そのデータを編集した可能性があることを意味する（「再現不能読み取り問題」）。これに対して保護するために、我々は、下で説明する楽観的ロックを行う。

我々は、我々が更新しようとしている行が、その動作を開始した後に変更されているかどうかを判断したい時に、その行のタイムスタンプ列が、我々が保管したものより大きい値を有するかどうかを調べるためにチェックする。

そうである場合に、その行は、我々が最後にそれを読み取った後に更新されており（ある他のトランザクションによって）、我々は、変更を元に戻さなければならない。そうでない場合には、その行に対する変更を行うことができる。例えば、ＲｅｂｕｉｌｄＰｅｒｓｏｎｓＶｉｅｗｓ ｓｐｒｏｃを参照されたい。

（プログラム化可能性）
ルールを操作し使用するためのストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: AuthorizeItemChanges
//
// 特定の日付に変更されたアイテムが、アイテム内容ルールに違反していないことを
// チェックする。いずれかのアイテムがいずれかのルールを破壊している場合には、
// トランザクションをロールバックする。このプロシージャは、シリアライズ可能な
// トランザクション内で実行されると期待され、したがって、結果は、同一のＵＴＣ // クロック時刻にアイテムを追加または変更する他のトランザクションによって影響 // されなくなる。
//--------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: AuthorizeRuleChanges
//
// 特定の瞬間のセキュリティプリンシパルによるすべてのルール変更がどのルールに
// も違反していないことをチェックする。ルールによって参照される定数セットのメ
// ンバの変更は、ルールに対する変更としてカウントされる。Ｓｅｔｓテーブルのト // リガは、ＲｕｌｅＳｅｔ変更によって影響を受けるルールのＣｈａｎｇｅｒＩＤお // よびＣｈａｎｇｅｄＤａｔｅを変更することによって、これを実装する。定数ＩＤ // のストリングは、更新または削除することができず、したがって、ルールに対する // 類似する変更を引き起こさない。
/---------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: AuthorizeTreeChanges
//
// 特定の瞬間のセキュリティプリンシパルによるすべてのルール変更がどのルールに
// も違反していないことをチェックする。ルールによって参照される定数セットのメ
// ンバの変更は、ルールに対する変更としてカウントされる。Ｓｅｔｓテーブルのト // リガは、ＲｕｌｅＳｅｔ変更によって影響を受けるルールのＣｈａｎｇｅｒＩＤお // よびＣｈａｎｇｅｄＤａｔｅを変更することによって、これを実装する。定数ＩＤ // のストリングは、更新または削除することができず、したがって、ルールに対する // 類似する変更を引き起こさない。
/---------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: AuthorizeFieldChanges
//
// 特定の瞬間のセキュリティプリンシパルによるすべてのルール変更がどのルールに
// も違反していないことをチェックする。これは、プロダクトフォームに対する変更
// もチェックする。
//--------------------------------------------------------------------------*/
ルールを操作するストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: AddConstant
//
// 定数をデポに導入するのに使用されるストアドプロシージャ。定数がドメイン
// アカウントである場合には、アクティブディレクトリと同期化される、すなわちそ
// のセットメンバシップが、アクティブディレクトリからとられる。
//--------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: ChangeRuleSet
//
// 既存の定数をセット／リストに追加する。
//
// セキュリティ違反または他の保全性違反の際に、トランザクションがロールバック
// される。トランザクションがロールバックされる場合には、ＳＱＬエラー２６６が
// 送出される。
//--------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: LookupRule
//
// 条件の特定のセットを有するルールを追加する／見つける。ルールの個数は、最小
// 限に保たれ、したがって、新しいルールは、必要な条件を有する既存ルールがない
// 場合に限って追加される。
//--------------------------------------------------------------------------*/
/*---------------------------------------------------------------------------
// 名前: ChangeRule
//
// 既存ルールのフラグを変更する。冗長なデータベース更新は行わない。
// 入力引数値としてヌルを使用することによって、すべてのアクセス権フラグを未変
// 更のままにすることができる。
// ルールは、削除されず、すべてのフラグが０の場合には関連しない。
// セキュリティ違反または他の保全性保全性違反の際に、トランザクションがロール // バックされる。
// トランザクションがロールバックされる場合には、ＳＱＬエラー２６６が送出され // る。
//--------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: ApplyRuleChanges
//
// 変更がオーソライズされた後、およびツリー変更が適用された後だが、ルール変更
// が適用される前に呼び出す。これによって、セキュリティプリンシパルによって所
// 与の時に行われたＳｅｔｓに対する変更に従って、ＥｘｐｌｏｄｅｄＳｅｔｓ（遷 // 移的セットメンバシップ）に行が追加され、除去される。
//--------------------------------------------------------------------------*/
プロダクトツリーを操作するストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: ChangeTree
// 既存ノードを変更するか、新規ノードをプロダクトツリーに追加する。冗長なデー
// タベース更新または挿入は行わない。入力引数値としてヌルを使用することによっ
// て、すべての列を未変更のままにすることができる。
// 新規ノードは、ヌルのＴｒｅｅＩＤが入力として渡された場合に追加される。
// セキュリティ違反または他の保全性保全性違反の際に、トランザクションがロール // バックされる。
// トランザクションがロールバックされる場合には、ＳＱＬエラー２６６が送出され // る。
//--------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: ApplyTreeChanges
//
// プロダクトツリーに対する変更に基づいて、ツリーパステーブルに対する増分変更
// を行う。プロダクトツリーに対する変更の共通のケースは、サブツリー全体を伴う
// 些細な変更のためである。
//--------------------------------------------------------------------------*/
プロダクトフィールドを操作するストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: ChangeField
//
// 既存フィールドを変更するか新規カスタムフィールドを追加する。
// セキュリティ違反または他の保全性保全性違反の際に、トランザクションがロール // バックされる。
// トランザクションがロールバックされる場合には、ＳＱＬエラー２６６が送出され // る。
//--------------------------------------------------------------------------*/

/*---------------------------------------------------------------------------
// 名前: ApplyFieldChanges
//
// 「短く狭い」フィールドが使用されるようになる時に、ＡｒｅテーブルおよびＷｅ
// ｒｅテーブルを変更する。これらは、Ｐｒｏｄｕｃｔ Ｓｔｕｄｉｏ ＵＩの結果
// ペインに表示できるフィールドである。すべての未使用のデータベース列をフィル
// タアウトするこれらのテーブルに対するビューが、必要な場合に再ビルドされる。
// これらのビューは、保護されたアイテムの読み取りに使用されるパーソナルビュー
// の基礎である。
//--------------------------------------------------------------------------*/

プロダクトルールを作成するＳＱＬのサンプル

ルールのサンプル
次のサンプルルールでは、ビジネスシナリオと、プロダクトルールがそれにどのように対処するかを説明する。「Ｄｅｃｏｄｅｄ Ｒｕｌｅｓ」ビューに現れるルールおよびそれが依存する定数のセットのすべてのストリングが、リストされる。（形式張った）英語の解釈と共にすべてのルールを見るには、
Select ForDisplay from dbo.DecodedRules
を行う。

名前付きセット「Ｏｋａｙ Ｓｔａｔｕｓ」（ネストされたセットの名前ではなく）のストリングを見るには、
select * from dbo.ExplodeSet ('Okay Status')
を行う。

名前付きセット「Ｏｋａｙ Ｓｔａｔｕｓ」の直接のメンバ（ネストされたセットの名前を含む）のストリングを見るには、
select * from dbo.ListSet ('Okay Status')
を行う。

ドメイングループまたは配布リストの名前、例えば「ｒｅｄｍｏｎｄ＼ｍａｒｋｒａｄｐ」は、セットの名前として機能する。そのメンバも見るためには、Ｅｘｐｌｏｄｅ Ｓｅｔ ＵＤＦを使用する。

ストリングの定数ＩＤを見つけるためには、
select ConstID from dbo.Constants where String = 'redmond＼tomtal'
を行う。
注：ＩＤとして使用される数は、固定されていない。異なるデポが、まったく異なるストリング、フィールド、またはツリーノードに同一の数を使用することができる。

ノーダッシュドメインユーザに対する全アイテムについてのリスト読み取りアクセス権の許可
(Editable) Grant Read FOR No Dash Domain Users TO Everywhere WHEN Always

リストの１つへのノードタイプの制約
Deny Admin FOR Domain Accounts TO Everywhere UNLESS Node Type ID NOT is Product => Node Type ID in Child Node Types

エリアタイプノードはサブエリアタイプノードまたはコンポーネントタイプノードを子として有することができる
Deny Admin FOR Domain Accounts TO Everywhere UNLESS Parent Node Type ID is Area => Node Type ID in Area

Component
SubArea

「Ｒｅｄｍｏｎｄ＼ｐｓｔｅｓｔ」のメンバは、ノード１２をルートとするプロダクトツリーの枝の「Ｆｏｌｄｅｒ」タイプでないノードを作成することができない
Deny Admin TO REDMOND＼pstest FOR X (a Folder and under) UNLESS Node Type ID is Folder

タイトルは、全員の必須フィールドである
Deny Write FOR Domain Accounts TO Everywhere WHEN Title in Empty value

誰もが、彼がオープンしたすべてのアイテムを読むことができる
(Editable) Grant Read FOR Domain Accounts TO Everywhere WHEN Opened By in Name of domain account doing this

Ｗａｒはダイナミックリストである
(Editable) Suggestion FOR Domain Accounts TO Everywhere (Unused) WHEN WAR NOT in Okay WAR

Ｃｌｏｓｅｄ Ｄａｔｅは、状態がクローズドでない時について空でなければならない
Deny Write FOR Domain Accounts TO Everywhere UNLESS Status NOT is Closed => Closed Date in Empty value

「Ｒｅｄｍｏｎｄ＼ｍａｒｋｒａｄｐ」配布リストのすべてのドメインユーザは、どこでも何でも行うことができる
(Editable) Grant Read Grant Write Grant Admin FOR REDMOND＼markradp TO Everywhere WHEN Always

付録ＩＩ
ワークアイテムタイプ定義言語
（要約）
この文書は、ワークアイテムタイプ定義（ＷＩＴＤ）言語を定義する。

ワークアイテムタイプは、ＸＭＬファイルの手による作成によって、またはワークアイテムタイプエディタを使用してのいずれかで定義される。

（範囲）
この文書は、ワークアイテムタイプ定義言語を定義する。この文書は、この言語をどのように使用するかは定義しない。使用法については、ワークアイテムタイプルールおよびカスタマシナリオ仕様書を参照されたい。

（関連文書）
ワークアイテムタイプ
・ ワークアイテムタイプに関する詳細
ワークアイテムタイプルールおよびカスタマシナリオ
・ ワークアイテムタイプ定義言語を使用するためのカスタマ中心のシナリオ
ポートフォリオプロジェクト管理
・ ワークアイテムタイプの管理に関する詳細
Ｗｈｉｄｂｅｙ Ｂｕｇ
・ インハウス使用に関するワークアイテムタイプ定義（ドッグフーディング）

（目次）
要約
範囲
関連文書
目次
シナリオ
ワークアイテムタイプの概要
高水準ＷＩＴＤ構造
フィールド
＜ＦＩＥＬＤ＞定義
フィールド名
フィールド参照名
フィールドタイプ
フィールドレポーティング
フィールドヘルプテキスト
フィールドルール
フィールド制約
フィールドリスト
フィールドリストアイテム
グローバルリスト
フィールドリストタイプ
リストアイテム展開
例
組合せでのリストタイプの使用
正しい値の判定
ピックリスト値判定
複数リストの指定
フィールドデフォルト
フィールド条件
＜ＷＨＥＮ＊＞ルール、＜ＤＥＦＡＵＬＴ＞ルール、および＜ＣＯＰＹ＞ルールの期待される挙動
条件フィールドルール属性
ユーザおよびグループの参照
ワークフロー
概要
遷移セキュリティ
状態、遷移、または理由によるフィールドルールのスコープ指定
状態遷移アクション（状態遷移の自動化）
適切な状態遷移の識別
遷移の自動化
遷移アクションの詳細
自動遷移エラーチェックおよびＷＩＴ作成者の考慮
ルール評価順序
特別なルール制約
ナンセンスなルール
問題のあるルール
フォーム
＜Ｌａｙｏｕｔ＞、＜Ｇｒｏｕｐ＞、および＜Ｃｏｌｕｍｎ＞
コントロール
すべての要素
サンプル
ＷＩＴＤローカライゼーションおよびグローバライゼーション
Ｖ１カットリスト
フィールドタイプ
フィールドルール
フィールドインデクシング
ｉｎｄｅｘｅｄ

（シナリオ）
ＷＩＴＤ言語は、次のシナリオをサポートすることが期待される。

新しいチームプロジェクト
カスタマが、新しいチームプロジェクト（ＴＰ）を作成することを望む。カスタマは、チームプロジェクト作成ウィザードを介してこれを行う。ＴＰ作成の一部として、カスタマは、「方法論（ｍｅｔｈｏｄｏｌｏｇｙ）」（例えば、ＭＳＦ Ａｇｉｌｅ）を選択する。各「方法論」は、ワークアイテムタイプのセットを識別する。終了した時に、ＴＰに、その方法論によって定義されたデータベース内のワークアイテムタイプのセットが含まれ、ユーザは、これらのタイプの新しいワークアイテムインスタンスを作成することができる。

サードパーティワークアイテムタイプ
パートナが、カスタマがＶｉｓｕａｌ Ｓｔｕｄｉｏ Ｔｅａｍ Ｓｙｓｔｅｍツールを用いてＳＥＩ−ＣＭＭプロセスでより高いレベルを達成するのを助けることを望む。あるいは、システムインテグレータが、彼らが奨励する開発方法論をＶｉｓｕａｌ Ｓｔｕｄｉｏ Ｔｅａｍ Ｓｙｓｔｅｍツールを用いて自動化できると判断する。パートナは、ＷＩＴＤ言語でワークアイテムタイプのセットを設計する。パートナ／システムインテグレータは、これらのＷＩＴＤ ＸＭＬファイルをウェブを介して、ＣＤで、その他の方法でカスタマに配布する。

これらの方法論を購入したカスタマは、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒでチームプロジェクトの一部としてこれらのワークアイテムタイプをパッケージ化する。

Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒ間でのワークアイテムタイプの移動
ＡｄｖｅｎｔｕｒｅＷｏｒｋｓ社の部署Ａは、しばらくＶｉｓｕａｌ Ｓｔｕｄｉｏ Ｔｅａｍ Ｓｙｓｔｅｍを使用してきた。彼らは、カスタマイズされたワークアイテムタイプを使用している複数のチームプロジェクトを有する。彼らは、彼らがプロジェクトに関する問題を追跡するのに使用する新しいワークアイテムタイプも作成済みである。別の部署、部署Ｂで、新しいＴｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒがセットアップされた。部署Ｂは、良いことが部署Ａで起きていることを聞き、やはりＩｓｓｕｅワークアイテムタイプを使用すると判断した。部署Ａのチームプロジェクト管理者が、ＸＭＬファイルとしてＩｓｓｕｅをエクスポートする。部署ＢのＴＰ管理者は、自分のチームプロジェクトにＩｓｓｕｅワークアイテムタイプをインポートする。

（ワークアイテムタイプの概要）
次が、ＷＩＴＤ言語の主要な設計目標である。
・ 将来の機能性に対処するために拡張可能
・ 単純 − 基本言語は、理解と作成が単純でなければならない
・ 人間可読 − ユーザは、単純なＷＩＴＤをタイプし、特定の設計ツールに頼らずにそれらを働かせることができなければならない。

ワークアイテムタイプは、次の高水準アイテムからなる。
名前：これは、チームプロジェクト内で一意でなければならない。例に、ｂｕｇ、ｆｅａｔｕｒｅ、ｒｅｑｕｉｒｅｍｅｎｔ、ｔａｓｋが含まれる。
記述：これは、ランタイムにプロジェクト内のワークアイテムタイプの概要が必要な時に使用できるヘルプテキストである。
フィールドのリスト：これは、ワークアイテムタイプのフィールドの関連するセットを定義する。フィールド定義は、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒにグローバルである。すべてのワークアイテムタイプに、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎワークアイテムトラッキングに必要なコアフィールドのセットが含まれる。
ワークフロー：これは、有効な状態および正しい遷移のセットと、誰がこれらの遷移を実行することを許可されるかを定義する。
フィールドルールのセット：これは、ワークアイテムがその状態遷移図を通って移動する時のフィールドおよびフィールド値に対する制約を定義する。
フォーム：これは、関連するフィールドがエンドユーザによってどのように表示され、操作されるかを定義する。
オプションとして、グローバルリストのセット：複数のフィールドに再利用できる値の名前付きリスト（例えば、ｆｏｕｎｄ ｏｎ ＯＳフィールド、ｆｉｘｅｄ ｏｎ ＯＳフィールド、ｓｕｐｐｏｒｔｅｄ ｏｎ ＯＳフィールドに使用されるオペレーティングシステム）。

ワークアイテムタイプは、チームプロジェクトにスコープを指定される。グローバルワークアイテムは存在しない。

（高水準ＷＩＴＤ構造）
下は、ワークアイテムタイプ定義（ＷＩＴＤ）の高水準構造である。

＜ＷＩＴＤ ａｐｐｌｉｃａｔｉｏｎ＝’ｗｏｒｋ ｉｔｅｍ ｔｙｐｅ ｅｄｉｔｏｒ’ ｖｅｒｓｉｏｎ＝’１．０’＞
ワークアイテムタイプ定義は、タグ＜ＷＩＴＤ＞によって囲まれる。後のリリースで、ＸＭＬスキーマが変更される可能性がある。アップデートは、後方互換である。

＜ＷＯＲＫＩＴＥＭＴＹＰＥ ｎａｍｅ＝’ｂｕｇ’＞
ワークアイテムタイプ名は、所与のチームプロジェクト内で一意でなければならない。この名前は、ランタイムに使用される。例えば、ユーザが、ｂｕｇ、ｔａｓｋ、ｒｉｓｋ、またはｉｓｓｕｅを選択する。

＜ＤＥＳＣＲＩＰＴＩＯＮ＞
記述は、ランタイムにプロジェクトのワークアイテムタイプの概要が必要な時に使用できるヘルプテキストである。例えば、ａが、リスクと問題の間の相違を理解することを望む。

この文書の残りでは、＜ＧＬＯＢＡＬＬＩＳＴＳ＞セクション、＜ＦＩＥＬＤＳ＞セクション、および＜ＷＯＲＫＦＬＯＷ＞セクションを詳細に扱う。＜ＦＯＲＭ＞セクションは、現在はＷｏｒｋ Ｉｔｅｍ Ｔｙｐｅ Ｆｏｒｍ ＸＭＬで扱われている。

（フィールド）
所与のワークアイテムタイプに関連する関連フィールドは、ＸＭＬの＜ＦＩＥＬＤＳ＞セクションで定義される。定義（＜ＦＯＲＭ＞内および＜ＷＯＲＫＦＬＯＷ＞内など）セクションの他の場所で参照されるすべてのフィールドは、コアフィールドを除いて、まず＜ＦＩＥＬＤＳ＞セクションで宣言されなければならない。

フィールドは、次の情報を有する：名前、参照名、タイプ、ヘルプテキスト、および挙動または制約のセット。明示的にリストされない非コアフィールドは、このワークアイテムタイプのすべてのインスタンスについて暗黙のうちに空であり、読み取り専用である。

＜ＦＩＥＬＤ＞定義
フィールドは、名前、参照名、およびタイプによって定義される。フィールドは、様々なレポートする挙動（ｒｅｐｏｒｔｉｎｇ ｂｅｈａｖｉｏｒ）を用いてセットすることもできる。

フィールド名
フィールド名は、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒのフィールドに関する一意のユーザ可視のハンドルである。これは、所与のＴＦＳ内のすべてのチームプロジェクトおよびワークアイテムタイプにまたがる一貫性を奨励するためのものである。フィールド名は、クエリを作成するかワークアイテムタイプエディタ内で作業する時に使用される。ワークフロー内またはＷＩＴＤのフォームセクションで参照されるすべてのフィールドが、＜ＦＩＥＬＤＳ＞セクション内でそのフィールドを定義する＜ＦＩＥＬＤ＞要素を有しなければならない。

フィールドは、ＴＦＳ管理者によって、例えば「Ｔｉｔｌｅ」から「Ｈｅａｄｌｉｎｅ」に名前を変更することができる。フィールドの名前を変更することができるので、インテグレーションが名前によってフィールドを参照することは、良い考えではない。したがって、インテグレーションおよびフィールドの内部表現は、フィールド名自体に依存するのではなく、フィールド参照名を使用しなければならない。

フィールド名は、４２ユニコード文字の長さにすることができる。許容されるユニコード文字カテゴリは、次の通りである。
・ 小文字｛Ｌｌ｝
・ 大文字｛Ｌｕ｝
・ 題字｛Ｌｔ｝
・ 他の文字｛Ｌｏ｝
・ 数字｛Ｎｄ｝
・ スペース｛Ｚｓ｝

我々は、ベータ２の後で次を許可することを検討する可能性がある
句読点コネクタの単一の出現｛Ｐｃ｝
句読点ダッシュの単一の出現｛Ｐｄ｝
モディファイヤ（ｍｏｄｉｆｉｅｒ）文字｛Ｌｍ｝
ユニコードサロゲート（ｓｕｒｒｏｇａｔｅ）｛Ｃｓ｝
フィールド名は、前後のスペースをトリミングされる。

フィールド参照名
ＷＩＴＤ言語およびＷＩＱＬ（ワークアイテムクエリ言語）の重要な目的は、これらの定義をＴＦＳの間でポータブルにすることである。サードパーティインテグレーションがあるフィールドを見つけられ、参照できることも重要である。フィールド名は変更される可能性があるので、これらはこの目的には良くない。

フィールドＩＤがこの目的に最適と考えられるかもしれないが、カスタムフィールドをエンドユーザが追加することができるので、我々は、あるＴＦＳから別のＴＦＳへのフィールドＩＤ一意性を保証することができない。

したがって、我々は、フィールド参照名という概念を導入しようとしている。フィールド参照名は、．ＮＥＴフレームワークの名前空間が一意であるのと同一の形でグローバルに一意である。

したがって、フィールド参照名は、全世界で一意であり、名前を変更することができない。したがって、フィールド名「Ｔｉｔｌｅ」が「Ｈｅａｄｅｒ」に変更された場合に、参照名は同一のままになる。

．ＮＥＴ名前空間の伝統と調和して、我々は、我々自身の使用のために２つの名前空間すなわちＳｙｓｔｅｍおよびＭｉｃｒｏｓｏｆｔを定義する。Ｓｙｓｔｅｍ名前空間には、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎシステム機能に必須のすべてのコアフィールドが含まれる。Ｍｉｃｒｏｓｏｆｔ名前空間は、Ｍｉｃｒｏｓｏｆｔによって定義されるｏｕｔ−ｏｆ−ｔｈｅ−ｂｏｘワークアイテムタイプのすべての必要なフィールドを定義するのに使用される。カスタマおよびパートナは、カスタマワークアイテムタイプ用の彼ら自身のフィールド名前空間を作成することができる。

Ｓｙｓｔｅｍの例に、次が含まれる。
Ｓｙｓｔｅｍ．Ｉｄ
Ｓｙｓｔｅｍ．Ｔｉｔｌｅ
Ｓｙｓｔｅｍ．ＣｒｅａｔｅｄＢｙ
Ｓｙｓｔｅｍ．ＣｒｅａｔｉｏｎＤａｔｅ
Ｓｙｓｔｅｍ．ＣｈａｎｇｅｄＢｙ
Ｓｙｓｔｅｍ．ＣｈａｎｇｅｄＤａｔｅ
Ｓｙｓｔｅｍ．Ｓｔａｔｅ
Ｓｙｓｔｅｍ．Ｒｅａｓｏｎ

Ｍｉｃｒｏｓｏｆｔの例に、次が含まれる。
Ｍｉｃｒｏｓｏｆｔ．Ｃｏｍｍｏｎ．Ｓｔａｔｕｓ
Ｍｉｃｒｏｓｏｆｔ．Ｃｏｍｍｏｎ．Ｐｒｉｏｒｉｔｙ
Ｍｉｃｒｏｓｏｆｔ．Ｓｃｈｅｄｕｌｉｎｇ．Ｄｕｒａｔｉｏｎ
Ｍｉｃｒｏｓｏｆｔ．Ｓｃｈｅｄｕｌｉｎｇ．ＰｅｒｃｅｎｔＣｏｍｐｌｅｔｅ
Ｍｉｃｒｏｓｏｆｔ．Ｔｅｓｔｉｎｇ．ＴｅｓｔＣａｓｅＮａｍｅ

カスタマおよびパートナは、彼ら自身のワークアイテムタイプをサポートするために、彼ら自身の名前空間を定義することもできる。
Ａｃｃｅｎｔｕｒｅ．Ｃｏｍｍｏｎ．Ｓｅｖｅｒｉｔｙ
Ａｃｃｅｎｔｕｒｅ．Ｃｏｍｍｏｎ．Ｐｈａｓｅ
Ａｃｃｅｎｔｕｒｅ．ＲｉｓｋＭａｎａｇｅｍｅｎｔ．ＲｉｓｋＴｙｐｅ
Ａｃｃｅｎｔｕｒｅ．ＲｉｓｋＭａｎａｇｅｍｅｎｔ．Ｒｅｓｏｌｕｔｉｏｎ

ＥＤＳ．Ｃｏｍｍｏｎ．ＢｕｓｉｎｅｓｓＰｒｉｏｒｉｔｙ
ＥＤＳ．Ｂｕｇ．ＦｏｕｎｄＩｎＰｈａｓｅ
ＥＤＳ．Ｂｕｇ．ＦｉｘＩｎＰｈａｓｅ

ＴＦＳは、カスタマが彼ら自身のＳｙｓｔｅｍ．ＸフィールドまたはＭｉｃｒｏｓｏｆｔ．Ｘフィールドを作成することを防がない。しかし、そうしないことが強く推奨され、そうすることは、ＴＦＳ機能性を妨げる可能性がある。

フィールド参照名は、２５５文字の長さにすることができる。許容される文字は、次の通りである。
・ 英語小文字ａ〜ｚ
・ 英語大文字Ａ〜Ｚ
・ 数字０〜９
・ ピリオド「．」
・ ハイフンの単一の出現「−」
・ アンダースコアの単一の出現「＿」
フィールド参照名は、前後のピリオド「．」をトリミングされる。フィールド参照名には、少なくとも１つの「．」が含まれなければならない。

ＷＩＴＤのすべてのルール要素およびフォーム要素は、定義のポータビリティを最大にするために、参照名によってフィールドを参照しなければならない。

フィールドタイプ
フィールドのタイプは、ユーザがそのフィールドに保管することを期待するデータの種類およびサイズを定義する。フィールドは、ＴＦＳごとに１つのタイプだけを有することができる。これは、組織がプロジェクトおよびワークアイテムタイプに渡って共通のフィールドを使用することを奨励するためである。

正しいフィールドタイプは、次の通りである。
・ Ｓｔｒｉｎｇ
ワンライナ（ｏｎｅ−ｌｉｎｅｒ）および短いストリングフィールドに使用される。クエリフィルタおよび結果リストで自由に使用される。２５５ユニコード文字まで。
・ Ｉｎｔｅｇｅｒ
整数値に使用される。クエリフィルタおよび結果リストで自由に使用される。３２ビット符号付き整数。
・ Ｄｏｕｂｌｅ
浮動小数点値に使用される。クエリフィルタおよび結果リストで自由に使用される。
・ ＤａｔｅＴｉｍｅ
保管された時間の特定の瞬間をＵＴＣで表し、ローカル時間帯に合わせて調整される必要がある。
・ ＰｌａｉｎＴｅｘｔ
記述などに使用される長いテキストフィールド。
・ ＨＴＭＬ
記述などに使用される長いテキストフィールド。これは、ＨＴＭＬに強く型付けされている点がＰｌａｉｎＴｅｘｔフィールドと異なる。このフィールドは、情報のより豊かな表示を可能にする。

さらに、次のフィールドタイプは、ある種のコアフィールドだけについてサポートされる。これらのフィールドタイプをカスタマフィールドに使用することはできない。
・ ＴｒｅｅＰａｔｈ
ＣＳＳ領域またはイテレーションパスを保管するのに使用されるストリングフィールド。このフィールドタイプは、コアフィールドＳｙｓｔｅｍ．ＡｒｅａＰａｔｈまたはＳｙｓｔｅｍ．ＩｔｅｒａｔｉｏｎＰａｔｈだけについてサポートされる。
・ Ｈｉｓｔｏｒｙ
会話スレッドおよびリビジョンヒストリを表示するのに使用される長いテキストフィールド。このフィールドタイプは、コアフィールドＳｙｓｔｅｍ．Ｈｉｓｔｏｒｙだけについてサポートされる。

フィールドレポーティング
一部のフィールド値は、レポート目的に特に有用である。ＷＩＴＤは、ユーザがこれらのフィールドの特別な属性を指定することを可能にする。この属性は、オプションである。属性が指定されていない場合に、そのフィールドデータは、データウェアハウスにエクスポートされない。

レポート可能属性を有するフィールドは、データウェアハウスにエクスポートされ、レポートに含まれることができる。レポート可能属性は、次の３つの値のうちの１つをとる。

１．ｄｉｍｅｎｓｉｏｎ
ｉｎｔｅｇｅｒフィールド、ｓｔｒｉｎｇフィールド、またはｄａｔｅｔｉｍｅフィールドだけに使用される。データは、ウェアハウスおよびキューブに送られ、したがって、レポートのフィルタリングに使用することができる。ｆｏｒｍｕｌａ属性を指定する必要はないが、指定された場合に、ｆｏｒｍｕｌａ属性は値「ｎｏｎｅ」だけをとることができる。

２．ｄｅｔａｉｌ（ジャンクまたは縮退（ｄｅｇｅｎｅｒａｔｅ）ディメンション）
ｉｎｔｅｇｅｒフィールド、ｄｏｕｂｌｅフィールド、ｓｔｒｉｎｇフィールド、またはｄａｔｅｔｉｍｅフィールドだけに使用される。データは、ウェアハウスには送られるが、キューブには送られない。ｆｏｒｍｕｌａ属性を指定してはならない。

３．ｍｅａｓｕｒｅ
ｉｎｔｅｇｅｒフィールドおよびｄｏｕｂｌｅフィールドだけに使用される。集約（ａｇｇｒｅｇａｔｉｏｎ）は、ｆｏｒｍｕｌａ属性によって定義される。ｆｏｒｍｕｌａ属性が指定されていない場合のデフォルト集約は、ｓｕｍである。

ｆｏｒｍｕｌａ属性は、ユーザが、ｍｅａｓｕｒｅをどのように集約するかを選択することを可能にする。そのフィールドのｒｅｐｏｒｔａｂｌｅ属性が指定されていない場合には、ｆｏｒｍｕｌａフィールドは無視される。ｆｏｒｍｕｌａ属性は、次の７つの可能な値を有する。
ｓｕｍ
ｃｏｕｎｔ
ｄｉｓｔｉｎｃｔｃｏｕｎｔ
ａｖｇ
ｍｉｎ
ｍａｘ

ｒｅｐｏｒｔａｂｌｅセッティングは、ＴＦＳ全体に渡ってグローバルである。あるフィールドについて異なるセッティングを有するワークアイテムタイプの再プロビジョニングは、そのフィールドのｒｅｐｏｒｔａｂｌｅ値を変更しない。

ＷＩＴ作成者は、いつでも、ｒｅｐｏｒｔｉｎｇ属性を指定しないことによって、フィールドのレポートを使用不可にすることを許可される。その場合に、ユーザはこの属性を再指定することによって、フィールドのレポートを再び使用可能にすることができる（しかし、オリジナルセッティングから値を変更することはできない）。

これは、使用不可にされたときに、もはやフィールドがアダプタによってデータウェアハウスにコピーされないことを意味する。データウェアハウスは、（前に使用可能にされていた場合に）古い値を含み、レポートは、（おそらくは一貫性のないデータを有する）そのフィールドを参照することができる。

これによって、管理者が、フィールドが絶対的に必要ではないときのアダプタの不必要な使用を防ぐことが可能になる。

コアフィールドは、システムによってｒｅｐｏｒｔｉｎｇ属性をセットされ、変更することはできない。

フィールドヘルプテキスト
フィールドは、ユーザがフィールドに入力しなければならないものに関してユーザを案内するのにランタイムに使用されるヘルプテキストも有する。フィールドヘルプテキストは、オプションである。フィールド名およびタイプと異なって、フィールドヘルプテキストは、ＴＰ内の所与のワークアイテムタイプにスコープを指定される。これによって、各ＴＰが、任意の所与のワークアイテムタイプに対する任意の所与のフィールドの使用に関する、それ自体のガイドラインを定義することが可能になる。

フィールドヘルプテキストは、２５５文字の長さにすることができる。

注：グローバルヘルプテキストはなく、ＷＩＴＤがあるフィールドのヘルプテキストを提供しない場合には、使用可能なヘルプテキストはない。これには、コアフィールドが含まれる。

フィールドルール
フィールドルールは、フィールドの挙動および制約を定義し、＜ＦＩＥＬＤ＞＜／ＦＩＥＬＤ＞ブロックの中にリストされる追加要素である。

例えば、フィールドが必要な場合に、ＸＭＬは次のようになる。

注：フィールドルールのスコープは、特定のチームプロジェクトのワークアイテムタイプに制限される。グローバルルールまたはグローバルワークアイテムタイプという概念はない。

フィールドルールは、次のサブセクションにグループ化されている。
・ 制約
・ リスト
・ デフォルト
・ 条件

フィールド制約
フィールド制約は、フィールド値の要件を定義する。

注：フィールド制約のうちのいくつかは、ここで説明するグローバルコンテキストで意味をなさない。この仕様書の後の部分で、フィールドルールのスコープを、ある状態、状態遷移、および理由に制限する方法を扱う。

＜ＲＥＱＵＩＲＥＤ ／＞
このフィールドは、空でないことが要求される。すべてのフィールドタイプを、ＲＥＱＵＩＲＥＤとしてマークすることができる。

＜ＲＥＡＤＯＮＬＹ ／＞
このフィールドを変更することはできない。

＜ＥＭＰＴＹ ／＞
このフィールド値は、コミット時にクリアされ、ユーザは、値を入力することを許可されない。主に状態遷移中に使用される。

＜ＦＲＯＺＥＮ ／＞
フィールドがコミットの後に値を得たならば、もはや変更することはできない。しかし、＜ＥＭＰＴＹ／＞制約を使用してクリアし、その後にもう一度書き込むことはできる。主に状態遷移中に使用される。

＜ＣＡＮＮＯＴＬＯＳＥＶＡＬＵＥ／＞
フィールドが値を得たならば、クリアすることも空にすることもできない。

＜ＮＯＴＳＡＭＥＡＳ ｆｉｅｌｄ＝”ＭｙＣｏｒｐ．Ｆｏｏ”／＞
このフィールド値は、フィールド「Ｆｏｏ」の値と同一の値を有することができない。例えば、２つのフィールドを同時に空にすることができず、あるいは、「ｃｏｄｅ ｒｅｖｉｅｗｅｒ」フィールド値を「ａｓｓｉｇｎｅｄ ｔｏ」フィールド値と同一にすることができない。これは、類似するタイプのフィールドに使用されなければならない。これは、ＰｌａｉｎＴｅｘｔフィールドまたはＨＴＭＬフィールドについてはサポートされない。

＜ＶＡＬＩＤＵＳＥＲ ／＞
このフィールド値は、ＴＦＳ Ｅｖｅｒｙｏｎｅのメンバである有効なメンバでなければならない。

注：＜ＲＥＱＵＩＲＥＤ／＞ルールが指定されていない場合に、このフィールドは、空の値を受け入れる。Ｓｔｒｉｎｇフィールドタイプに使用される。

注：このバージョンについて、ワークアイテムフィールドは、異なるドメインのユーザアイデンティティを区別しない。したがって、「ｒｅｄｍｏｎｄ＼ｊｓｍｉｔｈ」および「ｔｏｋｙｏ＼ｊｓｍｉｔｈ」は、＜ＶＡＬＩＤＵＳＥＲ ／＞ルールを用いてフィールドに入力された時に、同一ユーザとして扱われる。しかしドメインは、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎの他の場所のユーザアイデンティティは区別する。

＜ＶＡＬＩＤＤＡＴＥ ｍｕｓｔｂｅ＝”ａｆｔｅｒ ｎｏｗ”／＞
日付フィールドを検証する。ｍｕｓｔｂｅ値は、「ａｆｔｅｒ ｎｏｗ」または「ｎｏｔ ａｆｔｅｒ ｎｏｗ」のいずれかにすることができる。「ａｆｔｅｒ ｎｏｗ」は、現在時刻の後である。「ｎｏｔ ａｆｔｅｒ ｎｏｗ」は、フィールド値が現在時刻またはそれ以前であることを要求する。ＤａｔｅＴｉｍｅフィールドタイプに使用される。

＜ＡＬＬＯＷＥＸＩＳＴＩＮＧＶＡＬＵＥ／＞
フィールドが既に値を有するが、許容される値のリスト（下を参照されたい）で表された値でない場合に、そのままであることを可能にする。代替のデフォルト挙動は、編集時にユーザがそのフィールドに対する最新の許容される値に従うことを強制することである。この要素は、「ｆｏｒ」属性または「ｎｏｔ」属性を受け入れることができない。

この要素は、同一ブロック内の要素に対する変更効果だけを有する。詳細には、この挙動は、ルールの異なるスコープ指定について次の通りである。

フィールド定義
ルールがフィールド定義にスコープを指定されている場合には、いつでもそのフィールドに適用される。したがって、既存の値がコミットされたならば、ワークアイテムがどの状態であり、どの条件ルールを適用できるかに無関係に、将来のリビジョンでその値が許容される。

条件ルール
このルールが、フィールド条件の下でスコープを指定されている場合、親フィールド条件が満たされるときに、既存の値をコミットすることだけが許容される。

状態
ルールが状態の下でスコープを指定されている場合、ワークアイテムが親状態であるときまたはワークアイテムがその状態に遷移するときに、既存の値が許容される。これは、それらの遷移にスコープを指定されているすべての理由に適用される。

遷移
ルールが遷移の下でスコープを指定されている場合、ワークアイテムが親遷移を行うときに、既存の値が許容される。これは、遷移にスコープを指定されているすべての理由に適用される。

理由
ルールが理由の下でスコープを指定されている場合、ワークアイテムが指定された理由で親遷移を行うときに、既存の値が許容される。

＜ＭＡＴＣＨ ｐａｔｔｅｒｎ＝”＜ｐａｔｔｅｒｎ＞”／＞
ストリングだけについて基本パターンマッチングを実施する。＜ｐａｔｔｅｒｎ＞は、マッチパターンに置換されなければならない。有効な値は、「Ａ」、「Ｎ」、「Ｘ」であり、他のすべての値は、リテラルと解釈される。「Ａ」は、アルファベット文字を表す。「Ｎ」は、数字文字を表す。「Ｘ」は、アルファベットまたは数字のいずれかを表す。これは、ストリングタイプフィールドだけについてサポートされる。

例：
リリース番号
ＡＮＮ．ＮＮ．ＮＮ 妥当 Ｒ０１．０３．０４またはＶ０５．０８．９９
非妥当 １．３．４またはＶ５．８．９９またはｖ１．３
ある柔軟なｉｄ
ＸＸＸ−ＸＸＸ 妥当 ００１−ａｂｃまたはａ００−ｂ０２
非妥当 １−ａｂｃまたは００１．ａｂｃ
優先順位
ＰＮ 妥当 Ｐ１またはＰ５またはＰ９
非妥当 １またはＰ１０
マッチタグは、大文字小文字の区別がないので、「ＰＮ」はＰ１およびｐ１にマッチする。マッチタグは、空白値をサポートする。

複数の＜ＭＡＴＣＨ＞要素を指定することができる。１つの要素だけが成功した場合に、そのフィールドは正しい値を有する。

フィールドリスト
フィールドリストは、フィールドのピックリストを管理するのに使用される。ピックリストには、許容される値、提案される値、および禁止される値という３タイプがある。フィールドリストは、Ｓｔｒｉｎｇフィールドタイプ、Ｉｎｔｅｇｅｒフィールドタイプ、およびＤｏｕｂｌｅフィールドタイプに使用することができる。

フィールドリストアイテム
フィールドリストは、個々のアイテムから構成される。リストには、少なくとも１つのアイテムが含まれなければならない。＜ＬＩＳＴＩＴＥＭ ｖａｌｕｅ＝””＞要素は、リスト内のアイテムを指定するのに使用される。指定される値は、単なるストリングとすることができ、あるいは、ユーザまたはグループを指定することができる。この値は、空にすることができない。

さらに、１つまたは複数の＜ＧＬＯＢＡＬＬＩＳＴ＞要素を含めることによって、リストアイテムを共有することができる。

リストアイテムは、ＴＦＳのロケールに基づくアルファベット順でソートされる。

グローバルリスト
ワークアイテムタイプを定義するときに、いくつかのフィールドが同一のセットの値を共有していることに気がつく。しばしば、この共有は、複数のワークアイテムタイプに渡り、複数のチームプロジェクトに渡る場合もある。これらのリストの一部が、頻繁に変更される場合がある（例えば、ナイトリビルドのビルド番号）。

管理者が多数の場所で頻繁にこれらのリストを更新することを要求することは、理想的ではない。グローバルリストは、この問題に対処する。

グローバルリストは、グローバルに（ＴＦＳ全体で）保管され、使用される＜ＬＩＳＴＩＴＥＭ＞の単なるセットである。これらのリストを、「Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ」、「Ｆｏｕｎｄ ｉｎ Ｂｕｉｌｄ」、「Ｆｉｘｅｄ ｉｎ Ｂｕｉｌｄ」などのフィールドに使用することができる。

グローバルリストは、名前を有する。これらの名前は、ＴＦＳ全体にまたがって一意でなければならない。グローバルリストを、ワークアイテムタイプ定義の一部として定義し、管理するか、ＯＭを介してプログラマチックに維持することができる。グローバルリスト名に「＼」文字を含めることはできない。

ユーザは、手作業およびプログラマチックの両方で次を行うことができる。
・ リストを作成する
・ リスト値を追加する
・ リスト値を除去する
・ ＴＦＳ内のグローバルリストのリストを得る
・ リストの内容を得る

グローバルリストを作成し、管理する方法に関する情報については、Ａｕｔｈｏｒｉｎｇ Ｗｏｒｋ Ｉｔｅｍ Ｔｙｐｅ Ｌａｂを参照されたい。

外部データソースおよびグローバルリスト
グローバルリストは、あるサードパーティシステムからリストを導出しなければならない場合にも使用される。例えば、ある会社が、別々のカスタマデータベースを維持していると仮定する。カスタマによって発見されたバグが入力された時に、彼らは、カスタマの名前を有する必要がある「Ｆｏｕｎｄ Ｂｙ Ｃｕｓｔｏｍｅｒ」フィールドを有する。このバージョンについて、カスタマ名リストを入手するためにランタイムにカスタマデータベースのダイナミッククエリを可能にするプログラマチックアクセスが、サポートされていない。ダイナミック機能の近似は、ＯＭに対するコードを記述して、カスタマリストがカスタマデータベース内で変更された時に必ずグローバルリストを更新することである。

プロジェクト管理者およびＴＦＳ管理者は、グローバルリストの内容を変更することができる。

グローバルリストをインポートすると、まだ存在しない場合にはグローバルリストが作成される。更新は、単に、リストが存在する場合に値のリストを更新する。ＷＩＴのフィールドのいずれかがグローバルリストを参照する場合に、そのグローバルリストは、その内容と共に、エクスポートされるＸＭＬの一部になる。

フィールドリストタイプ
＜ＡＬＬＯＷＥＤＶＡＬＵＥＳ＞
ドロップダウンとして提示される値の列挙されたリスト。ユーザは、これらの値のうちの１つを選択しなければならない。

＜ＳＵＧＧＥＳＴＥＤＶＡＬＵＥＳ＞
ドロップダウンとして提示される値の列挙されたリスト。ユーザは、これらの値のうちのどの１つでも選択することができる。ユーザは、提案の１つでない彼ら自身の値を入力することもできる。

＜ＰＲＯＨＩＢＩＴＥＤＶＡＬＵＥＳ＞
ユーザは、フィールドに禁止される値が含まれる場合に、ワークアイテムを保存することができない。禁止される値は、通常、値が前に許容されたがもはや有効でない時に使用される。

例

リストアイテム展開
リストタイプ要素＜ＡＬＬＯＷＥＤＶＡＬＵＥＳ＞、＜ＳＵＧＧＥＳＴＥＤＶＡＬＵＥＳ＞、＜ＰＲＯＨＩＢＩＴＥＤＶＡＬＵＥＳ＞は、２つのオプション属性ｅｘｐａｎｄｉｔｅｍｓおよびｆｉｌｔｅｒｉｔｅｍｓを有する。

ｅｘｐａｎｄｉｔｅｍｓ＝ｔｒｕｅ／ｆａｌｓｅ、デフォルトはｔｒｕｅ
ｅｘｐａｎｄｉｔｅｍｓにｔｒｕｅがセットされている時に、グループまたはグローバルリストを表すリストアイテムは、再帰的に展開される。すなわち、グループはそのサブグループを展開され、サブグループのサブグループが展開される。展開の後に、グループを表していたリストアイテムに、リストアイテム値としてグループとユーザの両方が含まれる。ｅｘｐａｎｄｉｔｅｍｓにｆａｌｓｅがセットされている場合には、グループまたはグローバルリストの展開は実行されない。

ｆｉｌｔｅｒｉｔｅｍｓ＝”ｅｘｃｌｕｄｅｇｒｏｕｐｓ”
この属性／値の対が現れた時に、すべてのリストアイテムが評価され、すべてのグループが除去される。これは、グループなしのユーザのリストだけが欲しい時に使用される。

注：他のフィルタが将来に提供される可能性がある。

例
［Ｐｒｏｊｅｃｔ］＼Ｂｕｓｉｎｅｓｓ Ａｎａｌｙｓｔｓは、ビジネスアナリストユーザ、ｊｓｍｉｔｈ、ｂｂｏｂ、およびｄｍｉｌｌｅｒのチームプロジェクトグループである。
Ｒｅｄｍｏｎｄ＼ＭｙＴｅａｍは、３つのサブグループ、Ｄｅｖｅｌｏｐｍｅｎｔ、Ｔｅｓｔ、およびＰＭを有するグループである。各サブグループは、それぞれ、１つのユーザ「ｄｅｖｕｓｅｒ」、「ｔｅｓｔｕｓｅｒ」、および「ｐｍｕｓｅｒ」を有する。Ｒｅｄｍｏｎｄ＼ＭｙＴｅａｍは、１つのユーザ「ｊｕｓｅｒ」も有する。
Ｒｅｄｍｏｎｄ＼ＭｙＲｅｐｏｒｔｓは、ユーザ「ｕｓｅｒｏｎｅ」、「ｕｓｅｒｔｗｏ」、および「ｕｓｅｒｔｈｒｅｅ」と、「ｕｓｅｒｆｏｕｒ」および「ｕｓｅｒｆｉｖｅ」を有する１つのサブグループＭｙＲｅｍｏｔｅｓとを有するグループである。
ＢｏｏｌＶａｌｕｅｓは、２つのエントリ「ｔｒｕｅ」および「ｆａｌｓｅ」を有するグローバルリストである。

例１
展開がオンでグループをフィルタアウトされた状態における、ストリング値、グローバルリスト、およびグループ。

このフィールドのピックリストは、次の値を示す。
ｓｔｒｉｎｇ、ｔｒｕｅ、ｆａｌｓｅ、ｊｓｍｉｔｈ、ｂｂｏｂ、ｄｍｉｌｌｅｒ

例２
グループフィルタリングは実行されない。

このフィールドのピックリストは、次の値を示す。
ｓｔｒｉｎｇ、ｔｒｕｅ、ｆａｌｓｅ、ｊｕｓｅｒ、ｊｕｓｅｒ２、ｄｅｖｕｓｅｒ、ｔｅｓｔｕｓｅｒ、ｐｍｕｓｅｒ、Ｄｅｖｅｌｏｐｍｅｎｔ、Ｔｅｓｔ、ＰＭ

例３
リストアイテム展開は実行されない。

このフィールドのピックリストは、次の値を示す。
ｓｔｒｉｎｇ、ＭｙＴｅａｍ、ＭｙＲｅｐｏｒｔｓ
注：グローバルリスト名および内容は、表示されない。

例４
グループを除外し、展開なし。

このフィールドのピックリストは、次の値を示す。
ｓｔｒｉｎｇ
注：ＭｙＴｅａｍは、除外され、展開されないグループであり、ＢｏｏｌＶａｌｕｅｓは、グローバルリストであり、したがって、展開も表示もされない。

組合せでのリストタイプの使用
単一のフィールドについて複数のタイプのリストを指定することが可能である。このセクションでは、アイテムの結果のリストを判定する方法を定義する。

下の詳細について、ＡＬＬＯＷＥＤＶＡＬＵＥＳリストのすべての値が、セットＡとして識別される。ＰＲＯＨＩＢＩＴＥＤＶＡＬＵＥＳリストのすべての値が、セットＰとして識別される。ＳＵＧＧＥＳＴＥＤＶＡＬＵＥＳのすべての値が、セットＳとして識別される。

正しい値の判定
あるフィールドについて許容される正しい値は、｛セットＡ｝から｛セットＰ｝を引くことによって得られる。｛セットＡ｝がエントリを有しない場合には、｛セットＡ｝は、すべての可能な値と考えられる（すなわち、許容される値が定義されておらず、したがって、｛セットＰ｝で具体的に識別される値以外のすべてが許容される）。｛セットＳ｝は、フィールドの正しい値の判定では役割を演じない。

ピックリスト値判定
｛セットＳ｝ＡＮＤ｛セットＡ｝がエントリを有しない場合
結果：空のリスト
｛セットＳ｝がエントリを有し、｛セットＡ｝がエントリを有しない場合
結果：｛セットＳ｝から｛セットＰ｝を引くことによって得られる値
｛セットＳ｝ＡＮＤ｛セットＡ｝がエントリを有する場合
結果：
ａ．｛セットＡ｝と｛セットＳ｝の交わりをとって｛中間セットＩ｝を得、
ｂ．｛中間セットＩ｝から｛セットＰ｝を引く
ことによって得られる値のリスト
｛セットＳ｝がエントリを有しないが、｛セットＡ｝がエントリを有する場合
結果：｛セットＡ｝から｛セットＰ｝を引くことによって得られる値のリスト
複数リストの指定
所与の時点に複数の＜ＡＬＬＯＷＥＤＶＡＬＵＥ＞（例えば、ＷＩＴ ＜ＡＬＬＯＷＥＤＶＡＬＵＥ＞セットと状態固有）を指定した場合に、これらの複数のセットの交わりが、最終的な｛セットＡ｝として採用される。

複数の＜ＰＲＯＨＩＢＩＴＥＤＶＡＬＵＥＳ＞または＜ＳＵＧＧＥＳＴＥＤＶＡＬＵＥＳ＞を指定した場合には、これらのそれぞれの和集合が、それぞれ最終的な｛セットＳ｝または｛セットＰ｝として採用される。

フィールドデフォルト
フィールドデフォルトは、フィールド値を自動的に書き込む方法を扱うルールである。３タイプの要素、＜ＤＥＦＡＵＬＴ＞、＜ＣＯＰＹ＞、および＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞がある。
＜ＤＥＦＡＵＬＴ＞
ユーザが新しいワークアイテムを作成するかワークアイテムを編集する時に、＜ＤＥＦＡＵＬＴ＞要素は、フィールドが空の場合にフィールド値を書き込む。フィールドが既に値を有する場合には、デフォルトルールは無視される。
＜ＣＯＰＹ＞
ユーザが新しいワークアイテムを作成するかワークアイテムを編集する時に、＜ＣＯＰＹ＞
＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞
編集の始めに値を書き込む＜ＤＥＦＡＵＬＴ＞および＜ＣＯＰＹ＞と異なって、＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞ルールは、ワークアイテムがデータベースにコミットされる時に値を書き込む。これは、保存時にバックグラウンドで行われ、ユーザはその値をオーバーライドすることができない。フィールドは、フォーム上で読み取り専用のように見える。このルールは、セキュア監査証跡（ａｕｄｉｔ ｔｒａｉｌ）をサポートするために、「Ｌａｓｔ Ｃｈａｎｇｅｄ Ｂｙ」および「Ｌａｓｔ Ｃｈａｎｇｅｄ Ｏｎ」などのフィールドに使用される。

これらのタグのそれぞれが、値のソースを識別するｆｒｏｍ＝”＜ｆｒｏｍｔｙｐｅ＞”の形になる。＜ｆｒｏｍｔｙｐｅ＞に応じて、他の属性を続けることができる。

有効なｆｒｏｍｔｙｐｅは、次の通りである。
・ ｖａｌｕｅ
指定されたストリング定数からの値をとる。ｖａｌｕｅ＝”ｘｘｘ”属性を必要とする。＜ＣＯＰＹ＞ルールおよび＜ＤＥＦＡＵＬＴ＞ルールだけに使用される。
・ ｆｉｅｌｄ
指定されたフィールドからの値をとる。コピーされる値は、最後に成功裡にコミットされたリビジョンからのターゲットフィールドの値である。ｆｉｅｌｄ＝”ｘｘｘ”属性を必要とする。デフォルトで、指定されたｆｒｏｍフィールドが空の場合に、何も行わない。＜ＣＯＰＹ＞ルールおよび＜ＤＥＦＡＵＬＴ＞ルールだけに使用される。
・ ｃｌｏｃｋ
値として現在の日時を使用する。追加属性は不要である。ＤａｔｅＴｉｍｅフィールドに使用される。＜ＣＯＰＹ＞ルールおよび＜ＤＥＦＡＵＬＴ＞ルールについて、この値は、ローカルマシンクロック時刻から取られる。＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞について、この値は、コミット時のサーバクロックから与えられる。
・ ｃｕｒｒｅｎｔｕｓｅｒ
値として現在のユーザの短いユーザ名を使用する。追加属性は不要である。ストリングフィールドに使用される。

デフォルト優先順位の指定の例を示す。

Ｓｔａｔｕｓフィールドをクリアする例を示す。

ワークアイテムを最後に変更した人のユーザ名を保存する例を示す。

現在日付をデフォルトとするが、ユーザがそれを変更することを許可する例を示す。

注：「Ｗｏｎ’ｔ Ｆｉｘ」などのアポストロフィを含む値について、ＸＭＬで二重引用符を使用する必要がある。例を示す。

フィールド条件
依存ピックリストに使用され、詳細なセキュリティ挙動またはカスタマ挙動を提供するのに使用される追加の句がある。
＜ＷＨＥＮ ｆｉｅｌｄ＝”ｘｘｘ”ｖａｌｕｅ＝”ｙｙｙ”＞
この要素内のすべてが、フィールドｘｘｘが値ｙｙｙを有する間に適用可能である。

注意：ｖａｌｕｅ属性は、大文字小文字の区別がないので、ｘｘｘが「ＡＢＣ」を保持し、ｖａｌｕｅ＝”ａｂｃ”である場合に、これらはマッチする。

依存ピックリストの例を示す。

バグがカスタマによって報告され、カスタマ深刻度が入力されなければならない時の必要性の変化の例を示す。そうでない場合には、カスタマ深刻度は不要である。

＜ＷＨＥＮＮＯＴ＞
この要素内のすべてが、フィールドｘｘｘが値を有するがその値がｙｙｙでない間に適用可能である。

＜ＷＨＥＮＣＨＡＮＧＥＤ ｆｉｅｌｄ＝”ｘｘｘ”＞
この要素内のすべてが、フィールドｘｘｘがユーザによって変更済みである時に適用可能である。

＜ＷＨＥＮ＊＞ルール、＜ＤＥＦＡＵＬＴ＞ルール、および＜ＣＯＰＹ＞ルールの期待される挙動
このセクションでは、＜ＤＥＦＡＵＬＴ＞ルール、＜ＣＯＰＹ＞ルール、および＜ＷＨＥＮ＊＞ルールを使用する時に期待される挙動および相互作用の概要を示す。
１）ユーザが、新しいワークアイテムを作成するか既存ワークアイテムを編集することをジェスチャで表す。
２）フィールドデフォルトを書き込む。すべてのフィールドについて、＜ＷＨＥＮ＊＞ルールの外にあるすべての＜ＤＥＦＡＵＬＴ＞ルールを使用する。
３）フィールド値をコピーする。すべてのフィールドについて、＜ＷＨＥＮ＊＞ルールの外にあるすべての＜ＣＯＰＹ＞ルールを使用する。
４）最初にマッチする＜ＷＨＥＮ＞ルールを有するすべてのフィールドについて、まず内側の＜ＤＥＦＡＵＬＴ＞ルール、次に内側の＜ＣＯＰＹ＞ルールを行う。
５）最初にマッチする＜ＷＨＥＮＮＯＴ＞ルールを有するすべてのフィールドについて、まず内側の＜ＤＥＦＡＵＬＴ＞ルール、次に内側の＜ＣＯＰＹ＞ルールを行う。
必ず、＜ＷＨＥＮＮＯＴ＞ルールの前に＜ＷＨＥＮ＞ルールを処理する。
６）＃１以降に値を変更され、＜ＷＨＥＮＣＨＡＮＧＥＤ＞ルールを有するすべてのフィールドについて、まず内側の＜ＤＥＦＡＵＬＴ＞ルール、次に内側の＜ＣＯＰＹ＞ルールを行う。
７）ユーザに編集を開始させる。
８）ユーザが、フィールド値を変更し、そのフィールドのほかの部分に移動する。
９）新しい値にマッチする、そのフィールドのすべての＜ＷＨＥＮ＞ルールを発火させる。
１０）新しい値にマッチする、そのフィールドのすべての＜ＷＨＥＮＮＯＴ＞ルールを発火させる。
１１）新しい値にマッチする、そのフィールドのすべての＜ＷＨＥＮＣＨＡＮＧＥＤ＞ルールを発火させる。
１２）編集能力をユーザに返す。
１３）ユーザが、データベースに変更を保存することをジェスチャで表す。
１４）すべてのフィールドについて、＜ＷＨＥＮ＞ルールまたは＜ＷＨＥＮＮＯＴ＞ルールの下で直接にまたは間接にのいずれかでそのフィールドについて定義された＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞動作を実行する。

条件フィールドルール属性
時々、フィールドルールのスコープを、特定のグループまたはユーザに制限したくなる。属性「ｆｏｒ」および「ｎｏｔ」を追加して、これをサポートすることができる。これらは、タグを単一のＢＩＳグループに固有または単一のＢＩＳグループに含まれない全員に固有にするために、複数のタグで使用される。拒絶は、許可に優先する。

ｆｏｒ属性およびｎｏｔ属性は、オプションであり、空の値を有してはならない。
注：このバージョンでは、フィールドルールのスコープを特定のユーザに制限することはサポートされない。

少数の例を示す。

注：複数のグループが望まれる場合には、使用したいグループのセットを含むスーパーＴＦＳグループを作成する必要がある。

ユーザおよびグループの参照
フィールドリストアイテム、条件フィールドルール属性、および遷移セキュリティなどの複数のルールが、ユーザおよびグループを参照する。ＷＩＴＤ言語は、ユーザおよびグループを参照する次のトークンをサポートする。

［Ｇｌｏｂａｌ］
このトークンは、サーバスコープ付きのＴＦＳグループを参照するのに使用される。

［Ｐｒｏｊｅｃｔ］
このトークンは、チームプロジェクトスコープ付きのＴＦＳグループを参照するのに使用される。

ドメイン
ドメイン修飾子は、ドメインユーザまたはグループを参照するのに使用される。いくつかのルールが、グループだけをサポートし、ドメインユーザの参照をサポートしないことに留意されたい。

すべてのユーザおよびグループが、上のトークンのうちの１つによって修飾されなければならない。例えば、次のＸＭＬは、指定されたグループが有効なトークンによって修飾されていないので、無効である。

（ワークフロー）
概要
ＷＩＴＤのワークフローセクションでは、有効な状態、正しい遷移、および遷移の正しい理由を記述する。理由は、なぜユーザがある状態から別の状態に変更しようとしているかを識別する。

ワークフローセクションは、次のように見える。

ナッシング（すなわち、「」）から名前付き状態への１つの遷移だけを定義しなければならない。これは、新しいワークアイテムの初期状態を識別する。すべての遷移が、＜ＤＥＦＡＵＬＴＲＥＡＳＯＮ＞要素を用いて指定される１つのデフォルト理由だけを定義しなければならない。

ワークアイテムの最小のワークフローには、１つの状態、１つの推移、および１つのデフォルト理由が含まれなければならない。下は、ユーザが定義できる最小のワークフローである。

注：状態名および理由は、大文字小文字の区別がない。

遷移セキュリティ
２つの状態の間のすべての正しい遷移を指定しなければならない。遷移が指定されていない場合に、デフォルトは、その遷移の実行を許可しないことである。

さらに、２つの属性「ｆｏｒ」および「ｎｏｔ」をオプションとしてワークフローの遷移要素内で使用して、誰が遷移の実行を許可されるかを洗練することができる。拒絶は、許可に優先する。これらの属性の両方が指定されていない場合には、誰もがこの遷移を実行することを許可される（具体的には、ワークアイテムを変更できるすべての人）。

推移の完了を、チームに参加したばかりの新しいテスタを除くすべてのプロジェクトテスタに制限するルールの例を示す。個々のユーザアイデンティティを指定することも可能である。

注：複数のグループは、親グループを作成し、その親グループを使用することによってのみサポートされる。

状態、遷移、または理由によるフィールドルールのスコープ指定
これまでに我々が定義したフィールドルールは、フィールド名、そのタイプ、ヘルプテキスト、およびワークアイテムタイプ全体の挙動を識別する。すなわち、ｂｕｇの状態に無関係なフィールドの挙動である。例えば、１つのフィールドが、何であっても必ず必要である。

フィールドルールのスコープは、ある状態、遷移、または理由にも制限することができる。所与のフィールドに適用される完全なセットのルールは、４つのサブセットすなわち、ワークアイテムタイプ固有、状態固有、遷移固有、および理由固有からの加法的なセットである。

ワークアイテムタイプ全体のルールは、ワークアイテムがその状態モデルのどこにあるかに無関係に適用される。例えば、＜ＲＥＱＵＩＲＥＤ／＞ルールは、次のチェックを行う。
"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
スコープ付きフィールドルールは、＜ＳＴＡＴＥ＞要素、＜ＴＲＡＮＳＩＴＩＯＮ＞要素、および＜ＲＥＡＳＯＮ＞要素の中で＜ＦＩＥＬＤＳ＞要素および＜ＦＩＥＬＤ＞要素を使用することによって行われる。
注：ワークフロー内のフィールドをリストするときには、フィールド参照名だけを指定しなければならない。

下の例では、次のルールを定義している：ｂｕｇがアクティブ状態であるときに、カスタマ深刻度フィールドの変更を許可してはならない。

状態遷移アクション（状態遷移の自動化）
カスタマおよびパートナは、チームシステム内のどこかで発生したイベントまたはチームシステム自体の外（例えば、コールトラッキングツール（ｃａｌｌ ｔｒａｃｋｉｎｇ ｔｏｏｌ））で発生したイベントに基づいて、ワークアイテムを状態から状態に自動的に遷移させることを望む場合がある。他のシステム（我々自身のシステムを含む）によるワークアイテムの自動遷移をサポートするために、我々は、ワークアイテムタイプモデルおよびＯＭを拡張しつつある。例によってこれらの拡張に目を向けよう。

あるツールが、ユーザが変化をチェックした後に、あるワークアイテムを「ｒｅｓｏｌｖｅｄ」に自動的に遷移させることを望む。しかし、インテグレーションプロバイダとして、ユーザは、ＷＩＴ作成者が「ｒｅｓｏｌｖｅｄ」として宣言した状態がどれであるかを知らない。この状態は、Ｒｅｓｏｌｖｅｄ、Ｃｌｏｓｅｄ、Ｃｏｍｐｌｅｔｅｄ、Ｒｅａｄｙ Ｆｏｒ Ｔｅｓｔ、Ｉｎｃｌｕｄｅ Ｉｎ Ｂｕｉｌｄなどである可能性がある。１つのオプションは、すべてのＷＩＴ作成者に、明示的に「Ｒｅｓｏｌｖｅｄ」と命名された状態を含めることを要求することである。しかし、これは、あまりに拘束的であり、状態のローカライゼーションを許容しないのでＩ１８Ｎの展望から非常に悪い。そうではなく、インテグレータは、ワークアイテムに関する自動遷移を誘導するアクション（例えば、「ｃｈｅｃｋＩｎ」、「ｃｏｍｐｌｅｔｅ」）を彼らのシステムで宣言する。次に、ＷＩＴ作成者が、適当な推移に対してこのアクションを宣言する。

適切な状態遷移の識別
例えば、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎバージョンコントロールシステムは、チェックイン時のワークアイテムの自動遷移をサポートする必要がある。「ｍｉｃｒｏｓｏｆｔ．ｖｓｔｓ．ａｃｔｉｏｎｓ．ｃｈｅｃｋＩｎ」アクションが定義されている。ＷＩＴ作成者が、開発者が変更を行っている時のための「Ｗｏｒｋｉｎｇ」という状態と、欠陥が開発者によってナイトリビルドの準備ができたと宣言された時を識別する「Ｒｅａｄｙ Ｔｏ Ｂｕｉｌｄ」というもう１つの状態とを有する「Ｄｅｆｅｃｔ」ワークアイテムを定義すると仮定する。作成者は、次を宣言することによって、チェックイン動作中にワークアイテムを状態「Ｗｏｒｋｉｎｇ」から「Ｒｅａｄｙ Ｔｏ Ｂｕｉｌｄ」に自動的に遷移させることができる。

遷移の自動化
インテグレータにとって、アクションの定義は第１のステップにすぎない。ツールは、そのアクションを実行している時に、遷移を行わなければならない。例えば、Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎバージョンコントロールシステムが、チェックイン動作を実行しており、自動遷移を実行することを望むと仮定する。バージョンコントロールシステムは、ＯＭ呼出しを介してワークアイテムトラッキングシステムに問い合わせて、関連するワークアイテムを遷移させるべき正しい「Ｔｏ」状態を見つける。
nextState =
workiteminstance.GetNextState("microsoft.vsts.actions.checkin");
ワークアイテムインスタンスの現在の状態が、指定されたアクションのアクションエントリを有する場合に、そのインスタンスは「Ｔｏ」状態を返す。そうでない場合には、戻り値はＮｕｌｌである。

遷移アクションは、自動遷移を実行することを望むパートナ／インテグレータのためのヘルパ機能である。インテグレーションが次のステージに達したならば、そこから彼らが行うことは、彼ら次第である。例えば、どの遷移アクションが特定の状態遷移を発生させたかに関する保持される記録はなく、遷移の通常のＲｅａｓｏｎだけが記録される。この種類のトラッキングが望まれる場合には、ＷＩＴ作成者が、特定の値を正しい理由として識別し、自動化が、この値を遷移中にＲｅａｓｏｎフィールドにセットすることが推奨される。

遷移アクションの詳細
アクションは、オプションである。インテグレーションは、Ｎｕｌｌ戻り値を優雅に処理しなければならない。すなわち、ａ）エラーにせず、ｂ）アクション「ｘｙｚ」を探していたが見つからなかったので自動遷移しなかったことのトレース／ログを残し、このアクションを追加させるためにＷＩＴ作成者に連絡する。

各ＷＩＴについて、アクションは、「Ｆｒｏｍ Ｓｔａｔｅ／Ａｃｔｉｏｎ」対ごとに一意でなければならない。すなわち、ＷＩＴ作成者は、同一のアクションについて複数の「Ｔｏ」状態を指定することができない。

しかし、複数の自動遷移インテグレーションを可能にするために、同一の遷移での複数のアクションがサポートされている。例を示す。

アクション名は、ローカライズ可能ではない。

アクション名は、フィールド参照名と同一の基準名前空間規約に従わなければならない。これによって、ベンダ／カスタマの間でのアクション名衝突が防がれる。しかし、これは、ツールによって実施されない。

Ｍｉｃｒｏｓｏｆｔ ＶＳＴＳは、「Ｍｉｃｒｏｓｏｆｔ．ＶＳＴＳ．Ａｃｔｉｏｎｓ．＜ｙｏｕｒ ａｃｔｉｏｎ＞」を使用する。

自動遷移エラーチェックおよびＷＩＴ作成者の考慮
インテグレータが試みる可能性がある２タイプの自動遷移がある。第１は、あるユーザジェスチャに起因して発生する自動遷移であり、第２は、不在自動化（例えば、ナイトリビルド）として発生する自動遷移である。第１の場合に、ユーザが、起こる可能性があるすべてのルール関連問題を扱い、インテグレーションの知らない新しく必要なフィールドをＷＩＴ作成者が追加できるという事実をサポートしなければならないと仮定することができる。これを行うために、自動遷移を行った後に、ルール違反についてＷＩＴをチェックする必要があり、ルール違反が見つかった場合には、ユーザが解決するためのフォームを表示する必要がある。

第２の場合には、これらの問題を解決するユーザがいないので、これらの問題のいずれであっても扱うことができない。この場合には、インテグレーションは、優雅にエラーになり、自動遷移が試みられたことおよびそれがエラーになった理由の表示をエラーログに残さなければならない。

もちろん、理想的なケースは、ユーザ介入なしで自動遷移が行われる場合である。ＷＩＴ作成者は、これをサポートするために少数のことを行うことができる。第１に、ＷＩＴ作者は、必ずデフォルト理由を指定することができる。この形で、インテグレータおよびエンドユーザの両方が、遷移の理由を指定する必要がなくなる。第２は、遷移のすべての必要なフィールドのデフォルト値があることを確認することである。この形で、すべての適当な情報が、自動的に書き込まれる。

（ルール評価順序）
一般に、ルールは、ルールのスコープを反映した順序で実行される。例えば、あるルールのスコープが、特に現在の状態に制限されている場合に、そのルールは、グローバルなスコープを有するルールの前に呼び出される。下の例では、ワークアイテムタイプが、フィールドＳｔａｔｕｓに対するグローバル＜ＣＯＰＹ＞ルールと、状態「Ａｃｔｉｖｅ」にスコープを指定された＜ＣＯＰＹ＞ルールを有する。この場合に、ワークアイテムが「Ａｃｔｉｖｅ」状態に入る時に、値「Ａｃｔｉｖｅ」が、まずフィールドＳｔａｔｕｓにコピーされる。次に、これが、フィールドＳｔａｔｕｓへの空白ストリングのグローバルコピーによって上書きされる。

具体的に言うと、ワークフロースコープに基づく実行の順序は、次の通りである。
１．理由があるＳＴＡＴＥ ＴＲＡＮＳＩＴＩＯＮ
２．ＳＴＡＴＥ ＴＲＡＮＳＩＴＩＯＮ
３．ＳＴＡＴＥ
４．ＳＴＡＴＥスコープなし

上に示した各スコープの中で、ルールは、さらに、条件内のスコープによって順序付けられる。この順序は、次の通りである。
１．ＷＨＥＮ句
２．ＷＨＥＮＮＯＴ句
３．ＷＨＥＮ／ＷＨＥＮＮＯＴ句なし

最後に、上の条件スコープのそれぞれの中で、個々のルールが次のように順序付けられる。
１．＜ＤＥＦＡＵＬＴ＞ルール
２．＜ＣＯＰＹ＞ルール
３．＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞ルールを除く他のすべてのルール。＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞ルールは、ワークアイテムが保存される時に限って評価される。

ルールは、新しいワークアイテムが作成される時、既存ワークアイテムが開かれる時、およびユーザがルールをトリガする可能性があるフィールドを変更する時に評価される。ユーザがワークアイテムの保存を試みる時に、すべてのルールがルール衝突を見つけるために評価される。衝突がある場合には、保存が防がれる。

（特別なルール制約）
このセクションでは、プロビジョニングされ使用される時に問題を生じる可能性がある特別なケースのルールおよびルール組合せを扱う。これらは、３つのカテゴリすなわち、意味なし、問題あり、不正に分類される。最初の２つを下で述べる。不正なルール組合せとは、システムに関する深刻な問題を引き起こすルール組合せである。これらをプロビジョングすることは、システムによって防がれる。

カスタマが様々なルールに関する面倒を起こす可能性がある形のリスト全体を列挙することは不可能であるが、一般的なシナリオをリストする。ＷＩＴを作成する時には、プロダクション環境で適用する前に、分離されたシステムでそのＷＩＴをしっかりテストすることが、常に最善である。

ナンセンスなルール
ナンセンスなルールとは、明らかに誤っている、または意味がないルールである。このタイプのルールは、システムをクラッシュさせてはならず、予測不能な形で振る舞ってはならない。
１．同一のフィールドでの＜ＲＥＡＤＯＮＬＹ／＞ルールと＜ＲＥＱＵＩＲＥＤ／＞ルールの両方の使用
２．＜ＲＥＱＵＩＲＥＤ／＞ルールと＜ＥＭＰＴＹ／＞ルールの両方の使用
３．非日付フィールドへの「クロック」からのデフォルトまたはコピー
４．非ストリングフィールドへの「ｃｕｒｒｅｎｔｕｓｅｒ」からのデフォルトまたはコピー
５．非ストリングフィールドでの＜ＶＡＬＩＤＵＳＥＲ＞の使用
６．非日付フィールドでの＜ＶＡＬＩＤＤＡＴＥ＞の使用
７．異なるタイプのフィールドでの＜ＮＯＴＳＡＭＥＡＳ＞要素の使用
８．＜ＬＩＳＴＩＴＥＭＳ＞での整数フィールドに対するストリング値の指定
９．タイプｉｎｔｅｇｅｒのフィールドに対する＜ＧＲＯＵＰＩＴＥＭ＞アイテムまたは＜ＵＳＥＲＬＩＳＴ＞アイテムの指定

問題のあるルール
問題のあるルールとは、意味があるように見えるが、悪いか予測不能なシステム挙動をもたらすルールである。

このカテゴリに含まれるルールに、次が含まれる。
＜ＷＨＥＮＣＨＡＮＧＥＤ＞ルールを＜ＤＥＦＡＵＬＴ＞句および＜ＣＯＰＹ＞句と共に使用する複数のフィールドでの隠れた無限ループ。

無限ループを引き起こす、同一フィールドに関するある状態での＜ＡＬＬＯＷＥＤＶＡＬＵＥＳ＞の使用および別の状態での＜ＳＵＧＧＥＳＴＥＤＶＡＬＵＥＳ＞の使用
（フォーム）
ＵＩ要素の内容および配置は、ＷＩＴＤの＜ＦＯＲＭ＞セクションによって制御される。各ワークアイテムタイプは、１つのフォームだけを有しなければならない。このフォーム全体が、すべてのタブ、フィールド、およびグループを含めて記述される。

目的は、１つのフォーム定義から、Ｖｉｓｕａｌ Ｓｔｕｄｉｏで、ホスティングされるウィンドウズ（登録商標）フォームコントロールで、およびＷＳＳウェブパーツで、ワークアイテムフォームを正しくレイアウトできることである。１回設計し、どこでも使用することが、その哲学である。

＜Ｌａｙｏｕｔ＞、＜Ｇｒｏｕｐ＞、および＜Ｃｏｌｕｍｎ＞
トップレベルに、ＷＩＴＤの＜ＦＯＲＭ＞セクションへの３つの要素がある。
＜ＬＡＹＯＵＴ＞
この親要素に、ワークアイテムタイプフォームのすべてのレイアウト情報が含まれる。子要素は、このフォーム上にグループ、カラム、およびコントロールを配置する。
＜ＧＲＯＵＰ＞
子要素は、フォーム上の同一グループに含まれる。グループは、ボーダーおよびオプションのラベルによって画定される。隣接するグループは、垂直にスタックされる。
＜ＣＯＬＵＭＮ＞
すべての子要素を同一カラム内に保ち、フォームを水平に分割する。カラムは、＜ＧＲＯＵＰ＞の中に現れなければならない。＜ＣＯＬＵＭＮ＞要素内の＜ＧＲＯＵＰ＞要素は、ネストされたグループ化を作成するのに使用することができる。デフォルトで、カラムは＜ＧＲＯＵＰ＞を均等に分割する。オプションのＰｅｒｃｅｎｔＷｉｄｔｈ属性を使用して、カラム幅を変更することができる。

下のＸＭＬでは、２行のグループと各グループ内の２つのカラムを有するフォームが定義されている。

コントロール
コントロールは、フォームにフィールドまたは他の情報をレンダリングするのに使用される。各＜ＣＯＮＴＲＯＬ＞要素が、Ｔｙｐｅ属性およびオプションのラベルを有する。

Ｔｙｐｅ属性は、下で述べる複数のコントロールタイプを指定するのに使用される。
・ ＦｉｅｌｄＣｏｎｔｒｏｌ
・ ＴＦＳｔｒｕｃｔｕｒｅＣｏｎｔｒｏｌ
・ ＷｏｒｋＩｔｅｍＬｏｇＣｏｎｔｒｏｌ
・ ＬｉｎｋｓＣｏｎｔｒｏｌ
・ ＡｔｔａｃｈｍｅｎｔｓＣｏｎｔｒｏｌ
Ｌａｂｅｌ属性は、コントロールのとなりに表示されるテキストを指定する。関連するＬａｂｅｌＰｏｓｉｔｉｏｎ属性は、ラベルがコントロールに対してどこに表示されるかを指定する。

ＦｉｅｌｄＣｏｎｔｒｏｌ
このコントロールは、フォームにフィールドを表示するのに使用される。フィールドコントロールは、参照名によってフィールドを参照しなければならない。

ＴＦＳｔｒｕｃｔｕｒｅＣｏｎｔｒｏｌ
このコントロールは、Ａｒｅａ ＰａｔｈフィールドおよびＩｔｅｒａｔｉｏｎ Ｐａｔｈフィールドをツリーで表示する。ツリーは、展開でき縮小できる階層ノードを表示する。

ＷｏｒｋＩｔｅｍＬｏｇＣｏｎｔｒｏｌ
ワークアイテムのヒストリフィールドおよび会話フィールドをレンダリングする。ワークアイテムに対するヒストリカルリビジョンに関する詳細を、このコントロールを使用して展開し、縮小することができる。

ＬｉｎｋｓＣｏｎｔｒｏｌ
このワークアイテムから他のワークアイテムへのリンクを表示する。ユーザは、このコントロールを使用して、リンクを開き、編集し、追加し、除去することができる。

ＡｔｔａｃｈｍｅｎｔｓＣｏｎｔｒｏｌ
ワークアイテムに関するファイルアタッチメントを表示する。ユーザは、このコントロールを使用して、ファイルアタッチメントを開き、追加し、除去することができる。

すべての要素
次のテーブルに、＜ＦＯＲＭ＞セクションの許容可能な要素および属性のすべての詳細を示す。上で述べた要素ならびに他の要素が含まれる。

サンプル
ＷＩＴＤのサンプルフォームを示す。

（ＷＩＴＤローカライゼーションおよびグローバライゼーション）
一般に、エンドユーザから可視のＷＩＴＤのすべての要素をローカライズすることができ、その結果、これらが、ユーザのネイティブ言語で表示されるようになる。これには、様々な要素の状態の名前、理由の名前、遷移の名前、「ｌａｂｅｌ」属性の名前、および「ｎａｍｅ」属性の名前と、エンドユーザに示されることを意図されたワークアイテムタイプ記述およびフィールドヘルプテキストなどの情報が含まれ、これらのすべてがユニコード文字をサポートする。これに関する唯一の例外は、フィールドのフレンドリ名（ｆｒｉｅｎｄｌｙ ｎａｍｅ）であり、これは、フィールド名のセクションで述べたように、ユニコード文字の小さいサブセットに制限されている。

ＸＭＬ定義自体は、ローカライズ可能でない。したがって、＜ＷＯＲＫＩＴＥＭＴＹＰＥまたは＜ＦＩＥＬＤなどのタグは、英語でなければならない。さらに、＜ＶＡＬＩＤＤＡＴＥ ｍｕｓｔｂｅ＝“ａｆｔｅｒ ｎｏｗ”／＞の「ａｆｔｅｒ ｎｏｗ」値または＜Ｃｏｎｔｒｏｌ Ｔｙｐｅ＝”ＡｔｔａｃｈｍｅｎｔｓＣｏｎｔｒｏｌ”／＞の「ＡｔｔａｃｈｍｅｎｔｓＣｏｎｔｒｏｌ」値などの固定された属性値は、まったく同一の言葉で英語で使用されなければならない。最後に、フィールド参照名は、英語文字だけをサポートし（フィールド参照名を参照されたい）、これらの名前は、プログラム的使用を意図され、一般に、ＵＩに表示されない。

ＷＩＴＤのローカライズ可能な要素の例を、下に示す。
＜ＷＯＲＫＩＴＥＭＴＹＰＥ ｎａｍｅ＝”ｂｕｇ”＞
ｎａｍｅ属性の値をローカライズすることができる。
＜ＤＥＳＣＲＩＰＴＩＯＮ＞ Ｗｏｒｋ ｉｔｅｍ ｄｅｓｃｒｉｐｔｉｖｅ ｔｅｘｔ ｈｅｒｅ＜／ＤＥＳＣＲＩＰＴＩＯＮ＞
ワークアイテムタイプ記述をローカライズすることができる。
＜ＦＩＥＬＤ ｒｅｆｎａｍｅ＝”Ｓｙｓｔｅｍ．Ｔｉｔｌｅ” ｎａｍｅ＝”Ｔｉｔｌｅ” ｔｙｐｅ＝”Ｓｔｒｉｎｇ”＞
フィールド参照名およびタイプは、ローカライズ可能ではない。フィールド「ｎａｍｅ」属性の値は、ローカライズすることができる。しかし、フィールドについてユーザが選択した名前が、所与のＴＦＳのすべてのクライアントで使用されることを銘記されたい。また、ユーザが、ワークアイテムタイプクエリを作成する時にフィールド名を見ることを想起されたい。
＜ＨＥＬＰＴＥＸＴ＞Ｔｈｉｓ ｉｓ ａ ｗｏｒｋ ｉｔｅｍ ｆｏｒ ｂｕｇｓ＜／ＨＥＬＰＴＥＸＴ＞
フィールドのヘルプテキストは、ローカライズすることができる。これは、ワークアイテムタイプごとであり、ワークアイテムタイプはチームプロジェクトごとである。
＜ＬＩＳＴＩＴＥＭ ｖａｌｕｅ＝”Ｍｙ Ｖａｌｕｅ”＞
どのストリング値でもローカライズすることができる。
＜ＳＴＡＴＥ ｖａｌｕｅ＝”Ａｃｔｉｖｅ”／＞
＜ＳＴＡＴＥ ｖａｌｕｅ＝”Ｃｏｍｐｌｅｔｅ”／＞
＜ＴＲＡＮＳＩＴＩＯＮ ｆｒｏｍ＝”Ａｃｔｉｖｅ”ｔｏ＝”Ｃｏｍｐｌｅｔｅ”＞
＜ＲＥＡＳＯＮ ｖａｌｕｅ＝”Ｎｏ Ｐｌａｎｓ ｔｏ Ｆｉｘ”／＞
状態名および理由名をローカライズすることができる。
＜ＣＯＮＴＲＯＬ ＦｉｅｌｄＮａｍｅ＝”Ｆｏｕｎｄ Ｉｎ Ｂｕｉｌｄ” Ｌａｂｅｌ＝”Ｆｏｕｎｄ Ｉｎ” ＬａｂｅｌＰｏｓｉｔｉｏｎ＝”Ｔｏｐ”＞

フォームを定義する時に、フォーム上のグループ、タブ、およびフィールドにラベルを付けることができる。これらのすべてを、ローカライズすることができる。

したがって、あるプロジェクトで、フォーム上でフランス語の名前を使用されるｂｕｇ＿ｆｒｅｎｃｈ．ＸＭＬを定義し、別のプロジェクトで、フィールドの同一のセットを使用し、したがって、クロスプロジェクトクエリをサポートするｂｕｇ＿ｅｎｇｌｉｓｈ．ＸＭＬを定義することが可能である。しかし、クエリを作成する時に、ユーザが、フレンドリフィールド名だけにアクセスし、これは１つの言語にすることしかできないことに留意されたい。

（Ｖ１カットリスト）
このセクションの項目は、Ｖ１の仕様から除去されたが、後のリリースについて検討される可能性がある。

多値フィールド
ユーザがアイテムを複数選択できるリストフィールド。

状態アイコン／グリフ
ＵＩに表示される各状態に使用されるアイコンを指定する。

グローバルリスト
Ｄｅｌｅｔｅ − 深い洞察力がある管理者のためにこれを文書化する必要がある可能性がある
Ｓｏｒｔ
Ａｄｄ ｔｏ ｆｒｏｎｔ
Ａｄｄ ｔｏ ｂａｃｋ
Ａｄｄ ａｆｔｅｒ

フィールドタイプ
・ Ｂｏｏｌｅａｎ
我々は、フォームにチェックボックスとして表示されるＢｏｏｌｅａｎフィールドタイプをサポートすることができる。しかし、これは現在、ＰｒｏｄｕｃｔＳｔｕｄｉｏでよく使われてはおらず、ワークアラウンドがあり（０および１の値を有する整数フィールド）、我々は、Ｖ１についてはこれを検討しない。
・ ＤａｔｅＯｎｌｙ
年月日を表す。特定の瞬間ではなく、したがって、特定のタイムゾーンに結び付けられていない。
・ Ｄａｙ
このタイプのフィールドは、有効な曜日をとる（例えば、Ｔｕｅｓｄａｙ）。
・ Ｍｏｎｔｈ
このタイプのフィールドは、有効な月をとる（例えば、Ｆｅｂｒｕａｒｙ）。
・ Ｙｅａｒ
このタイプのフィールドは、有効な年をとる（例えば、２００４）。

フィールドルール
＜ＭＩＮ／＞／＜ＭＡＸ／＞ルール
Ｓｔｒｉｎｇフィールドタイプ
ストリングフィールドタイプの最小の文字および最大の文字をセットする
Ｉｎｔｅｇｅｒ／Ｄｏｕｂｌｅフィールドタイプ
整数フィールドタイプまたは浮動小数点フィールドタイプの最小値および最大値をセットする
＜ＧＲＡＹＯＵＴ／＞
フォームは、フィールドが読み取り専用であることを示すが、そのフィールドは、それでもＯＭを介して書き込み可能である。＜ＲＥＡＤＯＮＬＹ＞要素と異なって、すべてのＣｕｒｒｉｔｕｃｋクライアントが、このルールを尊重する責任を負う。
Ｄｏｕｂｌｅ Ｖａｌｉｄａｔｉｏｎルール
小数点以下の桁数を示すなど、ｄｏｕｂｌｅ値を検証するルール
Ｄｏｕｂｌｅ Ｄｉｓｐｌａｙオプション
通貨、丸めなど、ｄｏｕｂｌｅをフォーマットするためのフィールドディスプレイコントロールに関するオプション
ダイナミックリスト
ユーザが、フィールドに値をタイプすることができ、そのフィールドの許容される値のリストにそれを自動的に追加させることができるリスト。

フィールドインデクシング
いくつかのフィールド値は、クエリ作成またはレポート作成に特に重要である。ＷＩＴＤは、ユーザが、フィールドに関する２つの特別な属性を指定することを可能にする。両方がオプションである。単一のフィールドに、両方の属性を含めることができる。

ｉｎｄｅｘｅｄ
この属性を有するフィールドは、クエリ性能を改善するインデックスをビルドされる。この属性は、控え目に、ワークアイテムタイプのうちで重要なフィールドだけに使用されたい。インデクシングは、タイプＳｔｒｉｎｇ、Ｉｎｔｅｇｅｒ、またはＤａｔｅＴｉｍｅのフィールドだけに使用することができる。

付録ＩＩＩ
ワークアイテムタイプルール − カスタマシナリオ
生産的。統合。拡張可能。
１ 要約
２ 概要および範囲
３ ユーザがフィールド値を書き込むことを要求する
４ フィールド値をオートポピュレート（ａｕｔｏｐｏｐｕｌａｔｅ）する
５ フィールド値の編集を制限する
６ 柔軟なピックリストの管理
７ 厳密なピックリストの管理
８ フィールド値へのユーザの割り当て
９ ２レベル依存ピックリスト
１０ ２レベル依存ピックリスト（状態および理由）
１１ ３レベル依存ピックリスト
１２ 状態モデルの拡張
１３ Ｉｎｔｅｇｅｒフィールド値を検証する
１４ Ｓｔｒｉｎｇフィールド値を検証する
１５ ＤａｔｅＴｉｍｅフィールド値を検証する
１６ インデクシングを使用するクエリ性能の改善
１７ レポートにカスタムフィールド値を含める
１８ 監査証跡を実施する
１９ ユーザ／グループによるトランザクションを許可しない
２０ 終盤でコードレビューを要求する
２１ リストシナリオを通知する
２２ 複製リンクを要求する

１ 要約
この仕様書では、ワークアイテムタイプを作成する時にカスタマが実装することを望む重要なシナリオを説明する。

２ 概要および範囲
この文書の目的は、ワークアイテムタイプビジネスロジックを作成する時の重要なカスタマシナリオを識別し、そのサポートを保証することである。この文書では、カスタマが達成を試みているものを指定し、可能なＸＭＬルールコンストラクトを識別し、実装／実施されるべき所望のユーザインタフェースおよびＯＭ／ＢＲＩＥ挙動を定義する。この文書は、ワークアイテムタイプ作成文書化に直面するカスタマの基礎としても働く。

この文書では、カスタマがワークアイテムタイプへの適用を試みる可能性が高いすべての可能なシナリオを列挙することは試みない。この文書では、ワークアイテムタイプ定義言語でカスタマが使用可能なすべてのルールを扱うこともしない。

各シナリオは、それ自体のセクションで定義されている。灰色のセクションは、Ｍ３．３マイルストーンから削除された。

この文書は、ワークアイテムタイプ定義言語仕様書に対する補足仕様書である。

３ ユーザがフィールド値を書き込むことを要求する
ワークアイテムタイプ作成者は、ユーザが、ある時に、フィールドのセットの値を入力することを保証することを望む。言い換えると、識別されたフィールドを空のままにすることはできない。

３．１ ＸＭＬサンプル
ユーザは、ワークアイテムのタイトルを入力しなければならない。

３．２ ユーザインタフェースハンドリング
ユーザインタフェースの全体的な目標は、ユーザが、すべての値に正しい値を有するかどうかを視覚的にすばやく判定することを簡単にすることである。これを達成するために、必要なフィールドが現在値を有していない時に、そのフィールドを何らかの形で強調表示しなければならない。これは、バックグラウンドカラー、フィールドラベルカラー、および／またはアスタリスクとすることができる。アクセシビリティ要件も、この設計で考慮に入れなければならない。

必要なフィールドがタブにあり、そのタブが現在選択されていない場合には、タブのなんらかのインジケータが、そのタブに書き込まれる必要がある、必要なフィールドがあることを示さなければならない。

ユーザが値を書き込んだ時に、強調表示をなくさなければならない。このようにして、ユーザは、ワークアイテムを保存する要件を満たした時をすばやく判定することができる。

３．３ ＯＭ／ＢＲＩＥハンドリング
誰かが、まだ空である必要なフィールドを有するワークアイテムの保存を試みた時に、バックエンドは、意味のあるエラーを作らなければならない。ＯＭは、代替ユーザインタフェースの開発者がどのフィールドが値を必要とするかをすばやく判定し、したがって、ユーザのために意味のあるエラーメッセージを作ることができる方法を提供しなければならない。

ユーザが、空である複数の必要なフィールドを有するワークアイテムの保存を試みた時、エラーメッセージは、１フィールドずつエラーを提示することと対比して、書き込まれる必要があるすべてのフィールドを示さなければならない。

３．４ ルールスコープハンドリング
必要性は、加法的である。例えば、ワークアイテムタイプについて＜ＲＥＱＵＩＲＥＤ／＞ルールが定義されている場合に、そのフィールドは、状態、遷移、または理由にかかわりなく、必ず必要である。＜ＲＥＱＵＩＲＥＤ／＞ルールが所与の状態に関する場合に、そのフィールドは、ワークアイテムがその状態である時またはその状態に入る時に、遷移または理由にかかわりなく必要である。

３．５ シナリオ
３．５．１ 「Ｔｉｔｌｅ」フィールドは、必ず値を有する必要がある
必ず、ワークアイテムに関して説明を入力する必要がある。

３．５．２ 「Ｉｎｖｅｓｔｉｇａｔｉｎｇ」状態である時には、「Ａｓｓｉｇｎｅｄ Ｔｏ」フィールドが必要である
いくつかのワークアイテムは、「Ｓｕｂｍｉｔｔｅｄ」状態または「Ｎｅｗ」状態で生じる。そこから、これらのワークアイテムは別のアクティブ状態に移動する。この例では、そのアクティブ状態が「Ｉｎｖｅｓｔｉｇａｔｉｎｇ」になる。ワークアイテムが「Ｉｎｖｅｓｔｉｇａｔｉｎｇ」状態である時には、それは誰かに割り当てられなければならない。

３．５．３ 「Ｃｌｏｓｅｄ」状態に推移する時には、「Ｒｅｖｉｅｗｅｄ Ｂｙ」フィールドが必要である
ワークアイテムを閉じるためには（理由にかかわりなく）、そのワークアイテムが誰かによってレビューされていなければならない。

３．５．４ 理由「Ｄｕｐｌｉｃａｔｅ」のために「Ｒｅｓｏｌｖｅｄ」状態に遷移する時には、「Ｄｕｐｌｉｃａｔｅ ＩＤ」フィールドが必要である
だれかが、複製であるという理由のためにワークアイテムを解決している場合には、Ｄｕｐｌｉｃａｔｅ ＩＤフィールドに入力された複製ｉｄが存在しなければならない。他のすべての状態または理由について、このフィールドを空のままにすることができる。

３．５．５ 「Ｓｏｕｒｃｅ」フィールドが値「Ｆｒｏｍ Ｃｕｓｔｏｍｅｒ」を有する時には、「Ｃｕｓｔｏｍｅｒ Ｐｒｉｏｒｉｔｙ」フィールドが必要である
このワークアイテムは、ソースを識別するフィールドを有する。ソースがカスタマからである場合には、カスタマ優先順位フィールドが書き込まれていなければならない。

４ フィールド値をオートポピュレート（ａｕｔｏｐｏｐｕｌａｔｅ）する
ワークアイテム入力を単純にするために、カスタマができる限り多くのフィールドにオートポピュレートすることを試みている。これをサポートする４つのルール、＜ＤＥＦＡＵＬＴ＞、＜ＣＯＰＹ＞、＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞、および＜ＥＭＰＴＹ＞がある。

４．１ ＸＭＬサンプル
デフォルト優先順位に、Ｐ３をセットする。

現在のユーザ名を、ワークアイテムをレビューした人を示すフィールドにコピーするが、その値を変更できるようにする。

コミット時に現在のユーザ名および日付をフィールドにコピーする。これらのフィールドは、ＧＵＩでは変更可能でない。というのは、ユーザが変更をコミットした時に、値がサーバで上書きされるからである。

コミット時にフィールドの値をクリアする。フィールドは、クリアされ、ＧＵＩで変更可能ではない。というのは、ユーザが入力したすべての値が失われるからである。通常、このルールは、遷移中に使用される。例えば、ｂｕｇをもう一度開く時にＲｅｖｉｅｗｅｄ ｂｙフィールドをクリアしたい場合である（ＣｌｏｓｅｄからＡｃｔｉｖｅへの遷移）。

４．２ ユーザインタフェースハンドリング
デフォルトルールは、あるフィールドが空の場合にそのフィールドに値を置く。フィールドが既に値を有する場合には、デフォルトルールは無視されなければならない。コピールールは、フィールドの前の値に関わりなくフィールドに値を置く。デフォルトルールおよびコピールールの両方が、フィールドが読み取り専用または必要であるかどうかに関して何かを暗示してはならない。

デフォルトルールは、コピー挙動を駆動するフィールドにデフォルト値を挿入できるようにするために、コピールールの前に処理されなければならない。ユーザが新しいワークアイテムを作成する時、または既存ワークアイテムの編集を開始する時は、次の順序に従わなければならない。
− ＷＨＥＮ句の外のすべてのデフォルトルールを処理しなければならない
− ＷＨＥＮ句の外のすべてのコピールールを処理しなければならない
− ＷＨＥＮ、ＷＨＥＮＮＯＴ、ＷＨＥＮＣＨＡＮＧＥＤの順番で、ＷＨＥＮ句の中のすべてのデフォルトルールおよびその次にコピールールを処理する
− 必要に応じて３レベルまで繰り返す
− 制御をユーザに渡す
未解決の問題：実際にはこれはどのように働くのか？

ＳＥＲＶＥＲＤＥＦＡＵＬＴルールおよびＥＭＰＴＹルールは、コミットの後にサーバサイドで動作する。フィールドは、ＧＵＩでは読み取り専用にしなければならない。というのは、これらのフィールドにユーザが置いたすべての値が、コミット時に失われるからである。

４．３ ＯＭ／ＢＲＩＥハンドリング
ＯＭ／ＢＲＩＥは、上で説明したようにＧＵＩを駆動するためにルールを処理しなければならない。

また、ＯＭ／ＢＲＩＥは、フィールドの内容を検証し、ＷＩＴ作成者が誤ってデフォルトルールにおいた不正な値を把握しなければならない。デフォルト値が不正である次の例を検討されたい。

バックエンドは、ユーザがＳＥＲＶＥＲＤＥＦＡＵＬＴルールおよびＥＭＰＴＹルールに関するワークアイテムを保存する時に、サーバクロック時刻または現在のユーザを置くか、フィールドをクリアする。

４．４ ルールスコープハンドリング
加法的である、ＲＥＱＵＩＲＥＤルールと異なって、デフォルトルールおよびコピールールは、スコープが洗練された時にオーバーライドされなければならない。したがって、ワークアイテムタイプのデフォルト／コピールールは、状態固有デフォルト／コピールールによってオーバーライドされ、状態固有デフォルト／コピールールは、遷移固有デフォルト／コピールールによってオーバーライドされ、遷移固有デフォルト／コピールールは、理由固有デフォルト／コピールールによってオーバーライドされる。

デフォルトおよびコピーは、すべてのフィールドタイプについてサポートされる。
未解決の問題：これを達成できるか？

４．５ シナリオ
４．５．１ 優先順位フィールドのデフォルトをＰ３値にする
私は、許容される優先順位値のセットを有するが、Ｐ３のユーザのためにデフォルトが書き込まれることを望む。

４．５．２ 深刻度フィールドがＳ１の場合に優先順位フィールドにＰ１をコピーする
私は、ビジネス優先順位およびカスタマ報告深刻度を定義したワークアイテムタイプを有する。カスタマ報告深刻度がＳ１の場合に、デフォルトで、ビジネス優先順位をＰ１にしなければならない。
未解決の問題：＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ ｆｒｏｍ＝’ｆｉｅｌｄ’ ｖａｌｕｅ＝’Ｐ１’／＞が必要である。これをカットできるか？

４．５．３ 「Ｄｉｓｃｏｖｅｒｅｄ Ｏｎ」フィールドのデフォルトを現在時刻にするが、ユーザがこの値を変更できるようにする
私は、ワークアイテムが発見された日付を追跡したい。これは、そのワークアイテムがシステムに入力された日付の前である場合がある。しかし、ほとんどの場合に、これは、そのワークアイテムが入力された日付であり、したがって、「Ｄｉｓｃｏｖｅｒｅｄ Ｏｎ」フィールドのデフォルトを現在時刻にするが、必要な場合に、ユーザがこの値を変更できるようにする。
未解決の問題：このシナリオに必要な＜ＣＯＰＹ ｆｒｏｍ=’ｃｌｏｃｋ’／＞をカットできるか？

４．５．４ ユーザがワークアイテムを保存する時に、「Ｌａｓｔ Ｓａｖｅｄ Ｏｎ」フィールドにサーバクロック時刻をコピーする
ユーザがワークアイテムを保存する時に、必ず「Ｌａｓｔ Ｓａｖｅｄ Ｏｎ」フィールドの値を強制的にサーバクロック時刻にする。

４．５．５ 「Ａｓｓｉｇｎｅｄ」状態である時に、「Ａｓｓｉｇｎｅｄ Ｔｏ」フィールドのデフォルトを現在のユーザにする
ワークアイテムがまだ誰にも割り当てられていない場合に、Ａｓｓｉｇｎｅｄ状態である時に現在のユーザをデフォルトにする。

４．５．６ 理由「Ｎｏ Ｒｅｐｒｏ」を有するワークアイテムを解決する時に、「Ｒｅｖｉｅｗｅｄ Ｂｙ」フィールドが「Ａｓｓｉｇｎｅｄ Ｔｏ」と同一の値を有しなければならない
開発者が、再現できないワークアイテムを解決する時、そのワークアイテムに割り当てられた人の値をｒｅｖｉｅｗｅｄ ｂｙフィールドに書き込む。

５ フィールド値の編集を制限する
カスタマが、あるフィールドに対する変更を行うことを許可される人を制御することを望む。彼らは、＜ＲＥＡＤＯＮＬＹ／＞ルールを使用してこれを行うことができる。さらに、ｆｏｒ属性およびｎｏｔ属性の使用を使用して、これらのルールの適用可能性のスコープを個人のサブセットに制限することができる。

５．１ ＸＭＬサンプル
この例では、カスタマは、グループＴｒｉａｇｅＭｅｍｂｅｒｓのメンバだけがＴｒｉａｇｅフィールドの値を変更することを許可されることを望む。

５．２ ユーザインタフェースハンドリング
このフィールドは、灰色のバックグラウンドを有しなければならず、ユーザが、値を編集できてはならない。

５．３ ＯＭ／ＢＲＩＥハンドリング
＜ＲＥＡＤＯＮＬＹ＞フィールドへの書き込みのすべての試みが、ＯＭ／ＢＲＩＥによってブロックされなければならない。これに関する例外は、バックエンドで動作する＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞要素および＜ＥＭＰＴＹ＞要素である。

５．４ ルールスコープハンドリング
＜ＲＥＡＤＯＮＬＹ＞は加法的である。これには、ｆｏｒ制約およびｎｏｔ制約が含まれる。

５．５ シナリオ
５．５．１ グローバルＲＥＡＤＯＮＬＹ
期待される結果フィールドは、常に、ＧＵＩとＯＭの両方から読み取り専用である。

５．５．２ 状態固有ＲＥＡＤＯＮＬＹ
期待される結果フィールドは、状態フィールド＝’ｓｏｍｅ ｓｔａｔｅ’の時に読み取り専用である。

５．５．３ 遷移固有ＲＥＡＤＯＮＬＹ
期待される結果フィールドは、オリジナルの状態フィールド値＝’ｆｒｏｍ ｓｔａｔｅ’であり、新しい状態フィールド値＝’ｔｏ ｓｔａｔｅ’の時に、ＧＵＩとＯＭの両方から読み取り専用である。

５．５．４ 理由固有ＲＥＡＤＯＮＬＹ
期待される結果フィールドは、オリジナルの状態フィールド値＝’ｆｒｏｍ ｓｔａｔｅ’であり、新しい状態フィールド値＝’ｔｏ ｓｔａｔｅ’であり、理由フィールド値＝’ｓｏｍｅ ｒｅａｓｏｎ’の時に、ＧＵＩとＯＭの両方から読み取り専用である。

５．５．５ グローバルＧＲＡＹＯＵＴ
期待される結果フィールドは、ＧＵＩではグレイアウトされるが、ＯＭからは変更可能である。

５．５．６ 状態固有ＧＲＡＹＯＵＴ
期待される結果フィールドは、状態フィールド＝’ｓｏｍｅ ｓｔａｔｅ’の時に、ＧＵＩではグレイアウトされるが、ＯＭからは変更可能である。

５．５．７ 遷移固有ＧＲＡＹＯＵＴ
期待される結果フィールドは、オリジナルの状態フィールド値＝’ｆｒｏｍ ｓｔａｔｅ’であり、新しい状態フィールド値＝’ｔｏ ｓｔａｔｅ’の時に、ＧＵＩではグレイアウトされるが、ＯＭからは変更可能である。

５．５．８ 理由固有ＧＲＡＹＯＵＴ
期待される結果フィールドは、オリジナルの状態フィールド値＝’ｆｒｏｍ ｓｔａｔｅ’であり、新しい状態フィールド値＝’ｔｏ ｓｔａｔｅ’であり、理由フィールド値＝’ｓｏｍｅ ｒｅａｓｏｎ’の時に、ＧＵＩではグレイアウトされるが、ＯＭからは変更可能である。

５．５．９ ｆｏｒを伴う４ｘ
ｆｏｒを使用して５．５．１から５．５．４までを繰り返す。期待される挙動、フィールドは、グループに含まれるか具体的に指定されたユーザについて読み取り専用であるが、他のユーザについては読み取り専用でない。

５．５．１０ ｎｏｔを伴う４ｘ
ｎｏｔを使用して５．５．１から５．５．４までを繰り返す。期待される挙動、フィールドは、グループに含まれないか具体的に指定されていないユーザについて読み取り専用であるが、このグループのユーザについては読み取り専用でない。

５．５．１１ ｆｏｒｇｒｏｕｐおよびｎｏｔｇｒｏｕｐの両方を伴う８ｘ
ｆｏｒｇｒｏｕｐコンストラクトおよびｎｏｔｇｒｏｕｐコンストラクトを使用して５．５．１から５．５．８までを繰り返す。

６ 柔軟なピックリストの管理
カスタマが、ユーザが選択できる推奨される値のセットを伴うフィールドを有することを望む。しかし、彼らは、ユーザが彼ら自身の値を入力するのを制約することを望んでいない。

６．１ ＸＭＬサンプル
カスタマは、バグが見つかったビルドを追跡することを望む。彼らは、ナイトリビルドのリストを有するが、開発者がローカルビルド番号も入力できるようにすることを望む。

６．２ ユーザインタフェースハンドリング
ユーザに、彼らが提案される値の１つを選択できるようにするドロップダウンを提示しなければならない。ユーザは、手で値を入力することもできる。フィールドについて不正である値は絶対にない（フィールドが＜ＲＥＱＵＩＲＥＤ／＞要素も有する場合を除く。この場合には、ＮＵＬＬ値が不正である）。

１つの提案される値がある場合に、それを事前にポピュレートしなければならない（デフォルトルールがあるかのように）。ユーザは、もちろん、値を変更することができる。

未解決の問題：この最後の段落はサポートされるか？
６．３ ＯＭ／ＢＲＩＥハンドリング
柔軟なピックリストに関する特定のＯＭ／ＢＲＩＥハンドリング実施はない。

６．４ ルールスコープハンドリング
提案される値ルールは、提案される値セットの和集合を用いて作成される。同等の値をＯＭによってリストから除去し、ユーザに複数だが等しいオプションが提示されないようにしなければならない。ワークアイテムタイプ作成者が理由ごとに特定のリストを望む場合には、彼らは、理由レベルでのみ、提案される値を指定することができる。

６．５ シナリオ
上のＸＭＬサンプルを参照されたい。

７ 厳密なピックリストの管理
カスタマが、所与のフィールドの正しい値のリストを厳密に管理することを望む。ユーザは、所与のリストから正しい値だけを選択することができる。

７．１ ＸＭＬサンプル
詳細については下のシナリオを参照されたい。

７．２ ユーザインタフェースハンドリング
ユーザに、そこから選択すべき正しい値の最新のリストを提供するドロップダウンを提示しなければならない。値がフィールドに既に存在し、その値が禁止される値のリストに含まれるか、禁止される値のルールおよび既存の値を許可するルールの両方がない場合には、そのフィールドを強調表示して、ユーザが変更を行う必要があることを示さなければならない。値がフィールドに既に存在し、ａｌｌｏｗｅｘｉｓｔｉｎｇｖａｌｕｅｓルールがある場合には、何も強調表示してはならない。

７．３ ＯＭ／ＢＲＩＥハンドリング
バックエンドは、最新のルールのセットに基づいて、常にフィールドが正しい値を有することを実施しなければならない。例外は、フィールドが正しい前の値（編集の前）を有し ＡＮＤ 許容される値のルールがある場合に、バックエンドが、コミットを受け入れなければならず、フィールドの値を無変更のままにしなければならないことである。

７．４ ルールスコープハンドリング
許容される値リストルールは、許容される値の交わりを用いて作成され、これには、禁止される値が含まれる。ワークアイテムタイプ作成者が、特定の理由レベルルールを指定することを望む場合には、彼らは、理由レベルだけに値リストを置くことによってこれを行うことができる。
未解決の問題：禁止される値は和集合か交わりか？

７．５ シナリオ
７．５．１ デフォルトを有する正しい値のリストの管理
ワークアイテムタイプ作成者が、Ｅｍｅｒｇｅｎｃｙ、Ｍａｊｏｒ、Ｍｉｎｏｒ、またはＶｅｒｙＭｉｎｏｒのいずれかの値を有する欠陥の深刻度を示すために深刻度フィールドを望む。デフォルト値は、「Ｍｉｎｏｒ」である。

７．５．２ 延期された必要な更新を用いる、前に正しかった値の除去
その後、彼らは、ＶｅｒｙＭｉｎｏｒが実際にはそれほど有用でないと判断する。かれらは、これを許容される値のリストから除去することを望み、編集される時に既存レコードからこれを除去することを望む。次のＸＭＬに、この変更を示す。値が単純に除去されており、ワークアイテムが編集される時に、必ず、「ＶｅｒｙＭｉｎｏｒ」値を有する以前のワークアイテムが、変更される必要があることに留意されたい。

７．５．３ 更新を必要としない、前に正しかった値の除去
その後、その会社が、エンジニアリングからの大量のフィードバックの後に、既存の「ＶｅｒｙＭｉｎｏｒ」値を「Ｍｉｎｏｒ」に変更することが意味をなさないと判断する。これらの値を、前のままにしておくことが、よりよい。ワークアイテムタイプ作成者は、次の変更を行う。

７．５．４ 複数のフィールドが同一であるリストの管理
複数のフィールドが同一のリストを必要とすることがありえる。例えば、ｆｏｕｎｄ ｏｎ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍフィールドとｆｉｘｅｄ ｏｎ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍフィールドを有すると仮定する。その両方が、必要なオペレーティングシステムのリストを有する。次のＸＭＬは、このリストを一ヵ所に保持し、管理するのに使用される。デフォルト値が、ｆｏｕｎｄ ｏｎ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍフィールドからであることに留意されたい。

７．５．５ 値が別のシステムに保管されるリストの管理
我々がサポートしたいもう１つのリストシナリオは、カスタマが、Ｃｕｒｒｉｔｕｃｋの外部に保管されたデータを有するＣｕｒｒｉｔｕｃｋリストを自動的に最新状態に保つ能力である。これは、グローバルリスト（上と同様）を作成することによって行われる。しかし、開発者が我々のＯＭを使用して、
・ リスト値を追加し（前に、後に、インデックスの前に挿入）、
・ リスト値を除去し、
・ リスト内の値の個数を入手し、
・ リストに対して反復し、
・ リストをソートする
ことを可能にするＯＭインタフェースが必要である。

ここでの主要な例は、ビルドｉｄのリストである。ＸＭＬは、次のように単純にリストを定義する（このＸＭＬで少なくとも１つのアイテムを指定しなければならないことに留意されたい）。

８ フィールド値へのユーザの割り当て
ユーザが、ワークアイテムを割り当てることを望む。しかし、割り当ては、多くの意味を持つ可能性がある。例えば、時々、バグが、そのバグがサブミットされたエリアに基づいてあるユーザにデフォルトで暗黙のうちに割り当てられることが望まれる。もう１つの例は、バグを、レビューされるグループに割り当てることである（ＴｒｉａｇｅＴｅａｍに割り当てるなど）。もう１つの場合に、作成者は、ユーザが、システムの全ユーザのサブシステムから、明示的な割り当てを行うことを望む。このセクションでは、これらの様々なシナリオの概要を示す。

８．１ ＸＭＬサンプル
ＸＭＬサンプルは、下でシナリオごとに概要を示す。

８．２ ユーザインタフェースハンドリング
Ｖ１には、タイプ「ｕｓｅｒ／ｇｒｏｕｐ」のフィールドはなく、「ｓｔｒｉｎｇ」だけがある。それでも、ワークアイテムタイプ作成者は、ユーザ割り当てを検証する３つの手段を有する。

３つの手段とは、＜ＶＡＬＩＤＵＳＥＲ／＞ルール、＜ＶＡＬＩＤＵＳＥＲ ｇｒｏｕｐ＝’ｇｒｏｕｐ’／＞、ルール、および＜ＡＬＬＯＷＥＤＶＡＬＵＥＳ＞／＜ＰＲＯＨＩＢＩＴＥＤＶＡＬＵＥＳ＞ルールである。
＜ＶＡＬＩＤＵＳＥＲ／＞
有効ユーザルールは、入力されたユーザｉｄがシステムの正しいユーザであるかどうかの検証に使用される。そうでない場合には、そのフィールドを、無効な値を有するものとして強調表示しなければならない。グループを伴うＶＡＬＩＤＵＳＥＲコンストラクトは、入力されたユーザがそのグループに含まれることを保証しなければならない。
＜ＡＬＬＯＷＥＤＶＡＬＵＥＳ＞／＜ＰＲＯＨＩＢＩＴＥＤＶＡＬＵＥＳ＞挙動は、下でシナリオごとに説明する。

８．３ ＯＭ／ＢＲＩＥハンドリング
Ｖ１には、タイプ「ｕｓｅｒ／ｇｒｏｕｐ」のフィールドはなく、「ｓｔｒｉｎｇ」だけがあるので、ＯＭ／ＢＲＩＥは、適当なルール（上を参照されたい）を実装するだけでよい。

８．４ ルールスコープハンドリング
＜ＶＡＬＩＤＵＳＥＲ／＞ルールは、加法的なので、フィールドが、スコープのすべての下位レベルで有効なユーザＩｄを要求するようにする。

８．５ シナリオ
８．５．１ 現在のユーザをフィールドに割り当てる
新しいワークアイテムが作成される時に、そのワークアイテムを作成するユーザが、デフォルトでフィールドに割り当てられる。許容される値のリストがなく、このフィールドが＜ＶＡＬＩＤＵＳＥＲ／＞ルールを有するので、ＴＦＳで定義されたすべてのユーザが、割当可能であり、このフィールドのピックリストから使用可能でなければならない。さらに、ユーザは、手でユーザＩｄをタイプすることができる。ＧＵＩ強調表示が、ユーザが有効な選択を行うのを助ける。ＯＭ／ＢＲＩＥは、有効なユーザＩｄが入力されることを保証する。

未解決の問題：正確には、有効なユーザとは何か？ Ｃｕｒｒｉｔｕｃｋデータベース内のユーザか、ＢＩＳ内のユーザか？
８．５．２ 特定のグループからのユーザをフィールドに割り当てる
このプロジェクトでワークアイテムに割り当てられるユーザは、プロジェクトチームのメンバでなければならない。すべてのプロジェクトチームメンバが、（ＢＩＳまたはＷｉｎｄｏｗｓ（登録商標）の）グループ「ＭｙＰｒｏｊｅｃｔＭｅｍｂｅｒｓ」の一部である。ａｓｓｉｇｎｅｄ ｔｏフィールドのデフォルトは、現在のユーザである。ドロップダウンは、ＭｙＰｒｏｊｅｃｔＭｅｍｂｅｒｓのメンバであるすべてのサブグループのメンバを含むように拡張されたＭｙＰｒｏｊｅｃｔＭｅｍｂｅｒｓの全ユーザのリストでなければならない。例えば、ＭｙＰｒｏｊｅｃｔＭｅｍｂｅｒｓが、３つのサブグループ、Ｄｅｖｅｌｏｐｅｒｓ、Ｔｅｓｔｅｒｓ、およびＰｒｏｇｒａｍＭａｎａｇｅｒｓだけを有する場合に、この３つのサブグループは表示されないが、この３つのサブグループの全メンバのリストが表示される。

ｃｕｒｒｅｎｔｕｓｅｒがこのグループのメンバでない場合、またはユーザがこのグループのメンバでないユーザｉｄを手で入力した場合に、ＧＵＩは、フィールドを強調表示し、無効な値を示さなければならない。バックエンドは、＜ＶＡＬＩＤＵＳＥＲ ｖａｌｕｅ＝’ＭｙＰｒｏｊｅｃｔＭｅｍｂｅｒｓ’／＞ルールに起因して、このフィールドに、示されたグループからの有効なユーザが含まれることを検証しなければならない。

８．５．３ ユーザ、グループ、または値に割り当てる
この場合に、ワークアイテムを、ユーザ、グループ、または特定の値に割り当てることができる。この例について、このプロジェクトに割り当てられたユーザ（ｂｏｂ、ｓｈｉｒｌｅｙ、ｄａｖｅ、ｂｒｉａｎ、およびｍａｘ）のフラットリストであるグループ「ＭｙＰｒｏｊｅｃｔＭｅｍｂｅｒｓ」がある。サブグループ「Ｄｅｖｅｌｏｐｍｅｎｔ、Ｔｅｓｔ、Ｄｏｃｕｍｅｎｔａｔｉｏｎ、ＰｒｏｇｒａｍＭａｎａｇｅｍｅｎｔ」を有し、このレベルでユーザを有しないグループ「ＭｙＰｒｏｊｅｃｔＧｒｏｕｐｓ」もある。さらに、バグを、まったくグループではない「Ｔｒｉａｇｅ」に割り当てることを望むことができる。

この例では、ドロップダウン値は、次のようになる
Ｔｒｉａｇｅ、ｂｏｂ、Ｓｈｉｒｌｅｙ、ｄａｖｅ、ｂｒｉａｎ、ｍａｘ、Ｄｅｖｅｌｏｐｍｅｎｔ、Ｔｅｓｔ、Ｄｏｃｕｍｅｎｔａｔｉｏｎ
未解決の問題：これらが値、ユーザ、またはグループであることの表示をＧＵＩでユーザに与える必要はあるか？
このフィールドに有効なユーザでない値を含めることができるので、有効ユーザルールはない。

８．５．４ エリアに基づくユーザの割り当て
しばしば、会社は、バグが報告されているエリア、コンポーネント、またはアプリケーションに基づいて、入ってくるバグにデフォルトプロジェクトリーダーを割り当てることを望む。エリアパスを与えられて、これを達成できなければならない。

この例では、カスタマが、次のルールを実施することを望む。
・ Ｃｕｒｒｉｔｕｃｋワークアイテムタイプ定義言語のバグを「ｂｒｉａｎｗｈ」に自動的に割り当てる。
・ Ｃｕｒｒｉｔｕｃｋリンキングサブシステムのバグを「ｌｉｎｇｂａｏ」に自動的に割り当てる。
・ それ以外の場合に、バグを「ｂｒｙａｎｍａｃ」に割り当てる。
・ サブミットする側がプロジェクトチームのメンバ（事情がよりよく分かっていると仮定する）でない限り、サブミットする側がこの割当をオーバーライドすることを許可してはならない。
・ 入力が有効なユーザであることを保証する。
・ 入ってきたバグが未割り当てになることは絶対に許容してはならない。

９ ２レベル依存ピックリスト
ユーザは、２つのフィールドを有し、一方が他方に依存する。すなわち、一方のフィールドで許容される値が、第１のフィールドの値に依存する。この例では、２つのフィールド、ＰｌａｔｆｏｒｍおよびＶｅｒｓｉｏｎを使用し、Ｐｌａｔｆｏｒｍは基本オペレーティングシステムであり、Ｖｅｒｓｉｏｎはそのオペレーティングシステムのバージョンを表す。

９．１ ＸＭＬサンプル
次が、２レベル依存ピックリストシナリオの基本的なＸＭＬである。追加のＸＭＬまたは変更を、下でシナリオごとに示す。また、Ｐｌａｔｆｏｒｍの値がＵｎｋｎｏｗｎの場合にＶｅｒｓｉｏｎフィールドをクリアするルールに留意されたい。

９．２ ユーザインタフェースハンドリング
望まれる挙動を、下でシナリオごとに説明する。

９．３ ＯＭ／ＢＲＩＥハンドリング
ＯＭ／ＢＲＩＥハンドリングは、主に、セクション３の必要なフィールドおよびセクション７の厳密なピックリストの管理と同一の正しい値を実施することである。

９．４ ルールスコープハンドリング
この例は、状態、遷移、または理由にスコープを制限されない。

９．５ シナリオ
９．５．１ 新しいワークアイテム、デフォルトをとる
ユーザが、新しいワークアイテムを作成し、その後、保存する。期待される結果は、フィールドＰｌａｔｆｏｒｍにデフォルト値Ｗｉｎｄｏｗｓ（登録商標）が割り当てられ、フィールドＶｅｒｓｉｏｎにデフォルト値ＸＰが割り当てられることである。

９．５．２ 新しいワークアイテム、Ｖｅｒｓｉｏｎを変更する
ユーザは、「Ｗｉｎｄｏｗｓ（登録商標）」というデフォルト値を受け入れる。次に、ユーザは、「Ｖｅｒｓｉｏｎ」フィールドのドロップダウンを選択する。これには、値「９５、９８、Ｗ２Ｋ、ＸＰ」が含まれる。ユーザは、９５を選択し、保存する。

９．５．３ 新しいワークアイテム、プラットフォームを変更する（デフォルトあり）
ユーザが、新しいワークアイテムを作成する。「Ｗｉｎｄｏｗｓ（登録商標）」および「ＸＰ」というデフォルト値が、プラットフォームフィールドおよびバージョンフィールドに置かれる。次に、ユーザは、フィールド「Ｐｌａｔｆｏｒｍ」のドロップダウンを選択する。ユーザは、値「Ｗｉｎｄｏｗｓ（登録商標）」、「Ｕｎｉｘ（登録商標）」、「Ｌｉｎｕｘ」、および「Ｕｎｋｎｏｗｎ」を得る。ユーザは、「Ｕｎｉｘ（登録商標）」を選択する。この時に、フィールド「Ｖｅｒｓｉｏｎ」が強調表示される。というのは、不正な値「ＸＰ」が含まれるからである。ユーザは、これを見、バージョンフィールドのドロップダウンを選択し、選択肢「ＳｕｎＯＳ，ＨＰ−ＵＸ，ＡＩＸ，ａｎｄ Ｓｏｌａｒｉｓ」を見る。ユーザは、「Ｓｏｌａｒｉｓ」を選択する。バージョンフィールドの強調表示がなくなる。ユーザは、保存する。

９．５．４ 既存ワークアイテム、プラットフォームを変更し、変更を元に戻し、保存する
ユーザは、プラットフォーム値が「Ｗｉｎｄｏｗｓ（登録商標）」であり、バージョンが「ＸＰ」である既存ワークアイテムを開く。ユーザは、プラットフォームフィールドのドロップダウンを選択し、「Ｕｎｉｘ（登録商標）」を選ぶ。「ＸＰ」という値を有するバージョンフィールドが、不正なので強調表示される。ユーザは、プラットフォームドロップダウンを選択し、これを「Ｗｉｎｄｏｗｓ（登録商標）」に変更し、バージョンフィールドが、もはや強調表示されなくなる。

９．５．５ Ｕｎｋｎｏｗｎに変更し、保存する
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは、「Ｗｉｎｄｏｗｓ（登録商標）」であり、バージョンフィールドは、「ＸＰ」である。ユーザは、プラットフォームのドロップダウンを選択し、「Ｕｎｋｎｏｗｎ」に変更する。バージョンフィールドは、ＧＵＩでは、クリアされた読み取り専用である。

９．５．６ ＰｌａｔｆｏｒｍをＵｎｋｎｏｗｎに変更し、Ｌｉｎｕｘに変更し、保存する
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは、「Ｗｉｎｄｏｗｓ（登録商標）」であり、バージョンフィールドは、「ＸＰ」である。ユーザは、プラットフォームのドロップダウンを選択し、「Ｕｎｋｎｏｗｎ」に変更する。バージョンフィールドは、クリアされる。ユーザは、プラットフォームが「Ｌｉｎｕｘ」であることを思い出す。ユーザは、プラットフォームフィールドについてこの選択を行う。バージョンフィールドのデフォルトは、値「ＲｅｄＨａｔ」である。

１０ ２レベル依存ピックリスト（状態および理由）
ワークアイテムタイプのワークフローでは、ワークアイテムが通過する状態、遷移、および理由を定義する。これは、ＸＭＬの＜ＷＯＲＫＦＬＯＷ＞セクションで定義される。しかし、ユーザが状態モデルを操作する場所である２つのコアフィールド、Ｓｔａｔｅ（Ｓｙｓｔｅｍ．Ｓｔａｔｅ）およびＲｅａｓｏｎ（Ｓｙｓｔｅｍ．Ｒｅａｓｏｎ）がある。これらのフィールドは、デフォルトを有する２レベル依存ピックリストのように振る舞う。

１０．１ ＸＭＬサンプル

１０．２ ユーザインタフェースハンドリング
望まれる挙動を、下でシナリオごとに説明する。この２つのフィールドの挙動は、２レベル依存ピックリストに似ているが、いくつかの相違があり、これらの相違を、下でシナリオごとに太字で強調する。

１０．３ ＯＭ／ＢＲＩＥハンドリング
ＯＭ／ＢＲＩＥハンドリングは、主に、セクション３の必要なフィールドおよびセクション７の厳密なピックリストの管理と同一の正しい値を実施することである。

１０．４ ルールスコープハンドリング
理由は、遷移にスコープを制限され、遷移は、状態対にスコープを制限される。

１０．５ シナリオ
１０．５．１ 新しいワークアイテム、保存する
ユーザは、新しいワークアイテムを作成する。Ｓｔａｔｅに「ＮＥＷ」がセットされ、Ｒｅａｓｏｎに「Ｎｅｗ」がセットされる。

１０．５．２ 新しいワークアイテム、Ｒｅａｓｏｎを変更し、保存する
ユーザは、新しいワークアイテムを作成する。Ｓｔａｔｅに「ＮＥＷ」がセットされ、Ｒｅａｓｏｎに「Ｎｅｗ」がセットされる。ユーザは、理由のドロップダウンを選択し、「Ｆｏｕｎｄ Ｂｙ Ｃｕｓｔｏｍｅｒ」を選び、保存する。

１０．５．３ 新しいワークアイテム、Ｓｔａｔｅを変更する
ユーザは、新しいワークアイテムを作成する。Ｓｔａｔｅに「ＮＥＷ」がセットされ、Ｒｅａｓｏｎに「Ｎｅｗ」がセットされる。ユーザは、状態の変更を試みるが、できない。というのは、これが、新しいワークアイテムの唯一の正しい状態であるからである。

１０．５．４ Ｓｔａｔｅを変更し、デフォルトのＲｅａｓｏｎになる
ユーザは、状態値が「ＮＥＷ」であり、理由に「Ｎｅｗ」がセットされた既存ワークアイテムを開く。ユーザは、Ｓｔａｔｅのドロップダウンを選択し、このドロップダウンは、「ＮＥＷ」、「ＡＳＳＩＧＮＥＤ」、または「ＣＬＯＳＥＤ」を提供する。ユーザは、「ＡＳＳＩＧＮＥＤ」を選択し、理由フィールドが、デフォルトの「Ｔｒｉａｇｅｄ」になる。

１０．５．５ Ｓｔａｔｅを変更し、変更を元に戻し、保存する
ユーザは、状態値が「ＮＥＷ」であり、理由に「Ｎｅｗ」がセットされた既存ワークアイテムを開く。ユーザは、Ｓｔａｔｅのドロップダウンを選択し、このドロップダウンは、「ＮＥＷ」、「ＡＳＳＩＧＮＥＤ」、または「ＣＬＯＳＥＤ」を提供する。ユーザは、「ＡＳＳＩＧＮＥＤ」を選択し、理由フィールドが、デフォルトの「Ｔｒｉａｇｅｄ」になる。次に、ユーザは、考えを変え、状態フィールドをもう一度選択し、「ＮＥＷ」に変更する。理由フィールドが強調表示されて、もはや有効な値が含まれないことを示す。ユーザは、理由フィールドをリセットするか、変更を保存せずにそのワークアイテムを閉じることができる。

１１ ３レベル依存ピックリスト
多くのカスタマは、Ｎレベルピックリストを望む。このシナリオでは、セクション９の２レベルピックリストに基づいて作られる３レベルピックリストの例の概要を示す。この例では、我々は、前の例からのＰｌａｔｆｏｒｍフィールドおよびＶｅｒｓｉｏｎフィールドを有するが、オペレーティングシステムが有する可能性のあるすべてのパッチを示す第３のレベル「Ｐａｔｃｈ」を追加する。

１１．１ ＸＭＬサンプル
このＸＭＬサンプルでは、Ｐａｔｃｈフィールドを定義する。ＰｌａｔｆｏｒｍフィールドおよびＶｅｒｓｉｏｎフィールドは、セクション９．１で説明した。

１１．２ ユーザインタフェースハンドリング
この例および上の３レベルピックリストに関して留意すべき２つのことがある。第１に、プラットフォームフィールドがＵｎｋｎｏｗｎの場合に、Ｖｅｒｓｉｏｎフィールドと同様にＰａｔｃｈフィールドをクリアする。第２に、ユーザが、Ｐｌａｔｆｏｒｍ＝ＬｉｎｕｘおよびＶｅｒｓｉｏｎ＝Ｏｔｈｅｒを選択した場合に、ユーザが、明示的に許可される値のリストではなく、自由形式テキストを入力できるようにする。

１１．３ ＯＭ／ＢＲＩＥハンドリング
バックエンドは、単に、通常の必要な値および許容される値の実施を行う。

１１．４ ルールスコープハンドリング
この例について、状態、遷移、および理由によってスコープを指定された異なるルールを有することは、意味をなさない。私は、これがあてはまるシナリオを想像することができないが、それがあると確信している。このケースでの我々の推奨は、フィールドの明瞭な分離のためである。したがって、フィールドＣがフィールドＢの値に依存し、フィールドＢがフィールドＡの値に依存し、フィールドＣが理由にも依存する場合に、我々は、フィールドＡおよびＢをグローバル＜ＦＩＥＬＤＳ＞セクションで定義するように薦める。特定の理由の下の＜ＷＯＲＫＦＬＯＷ＞セクションでフィールドＣの＜ＷＨＥＮ＞を定義されたい。

この形で、依存ピックリストの唯一の完全な定義がある。すなわち、フィールドＣは、あるグローバルに許容される値および理由セクションで許容される値の異なるセットを有しない。これは、ルールが現在のシステムの加法的な挙動であるということになる。

１１．５ シナリオ
１１．５．１ 新しいワークアイテム、デフォルトをとる
ユーザが、新しいワークアイテムを作成し、その後、保存する。期待される結果は、フィールドＰｌａｔｆｏｒｍにデフォルト値Ｗｉｎｄｏｗｓ（登録商標）が割り当てられ、フィールドＶｅｒｓｉｏｎにデフォルト値ＸＰが割り当てられ、フィールドＰａｔｃｈにデフォルト値「Ｎｏｎｅ」が割り当てられることである。

１１．５．２ 新しいワークアイテム、Ｐａｔｃｈを変更する
ユーザが、新しいワークアイテムを作成する。ユーザは、「Ｗｉｎｄｏｗｓ（登録商標）」および「ＸＰ」というデフォルト値を受け入れる。次に、ユーザは、「Ｐａｔｃｈ」フィールドのドロップダウンを選択する。これには、値「Ｎｏｎｅ」および「ＳＰ１」が含まれる。ユーザは、「ＳＰ１」を選択し、保存する。

１１．５．３ 新しいワークアイテム、Ｐｌａｔｆｏｒｍを変更し、Ｖｅｒｓｉｏｎを変更し、Ｐａｔｃｈを変更する
ユーザが、新しいワークアイテムを作成する。「Ｗｉｎｄｏｗｓ（登録商標）」、「ＸＰ」、および「Ｎｏｎｅ」というデフォルト値が、プラットフォームフィールド、バージョンフィールド、およびパッチフィールドに置かれる。次に、ユーザが、「Ｐｌａｔｆｏｒｍ」のドロップダウンを選択する。ユーザは、値「Ｗｉｎｄｏｗｓ（登録商標）」、「Ｕｎｉｘ（登録商標）」、「Ｌｉｎｕｘ」、および「Ｕｎｋｎｏｗｎ」を得る。ユーザは、「Ｕｎｉｘ（登録商標）」を選択する。この時に、フィールド「Ｖｅｒｓｉｏｎ」が、不正な値「ＸＰ」含むので強調表示される。パッチフィールドは、「Ｎｏｎｅ」という正しい値を含むので、強調表示されない。ユーザは、バージョンフィールドのドロップダウンを選択し、選択肢「ＳｕｎＯＳ，ＨＰ−ＵＸ，ＡＩＸ，ａｎｄ Ｓｏｌａｒｉｓ」を見る。ユーザは、「Ｓｏｌａｒｉｓ」を選択する。バージョンフィールドの強調表示がなくなる。次に、ユーザは、Ｐａｔｃｈドロップダウンを選択し、「Ｎｏｎｅ」または「．０１」を得る。ユーザは、「．０１」を選択し、保存する。

１１．５．４ 既存ワークアイテム、Ｐｌａｔｆｏｒｍを変更し、変更を元に戻し、保存する
ユーザは、プラットフォーム値が「Ｗｉｎｄｏｗｓ（登録商標）」であり、バージョンが「ＸＰ」であり、パッチが「ＳＰ１」である既存ワークアイテムを開く。ユーザは、プラットフォームフィールドのドロップダウンを選択し、「Ｕｎｉｘ（登録商標）」を選ぶ。バージョンフィールドおよびパッチフィールドが、不正なので強調表示される。ユーザは、プラットフォームドロップダウンを選択し、これを「Ｗｉｎｄｏｗｓ（登録商標）」に変更し、バージョンフィールドおよびパッチフィールドが、もはや強調表示されなくなる。

１１．５．５ Ｕｎｋｎｏｗｎに変更し、保存する
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは「Ｗｉｎｄｏｗｓ（登録商標）」であり、バージョンフィールドは「ＸＰ」であり、パッチフィールドは「Ｎｏｎｅ」である。ユーザは、プラットフォームのドロップダウンを選択し、「Ｕｎｋｎｏｗｎ」に変更する。バージョンフィールドおよびパッチフィールドがクリアされる。

１１．５．６ ＰｌａｔｆｏｒｍをＵｎｋｎｏｗｎに変更し、Ｌｉｎｕｘに変更し、保存する
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは、当初は「Ｗｉｎｄｏｗｓ（登録商標）」であり、バージョンフィールドは「ＸＰ」であり、パッチフィールドは「ＳＰ１」である。ユーザは、プラットフォームのドロップダウンを選択し、「Ｕｎｋｎｏｗｎ」に変更する。バージョンフィールドは、クリアされる。ユーザは、プラットフォームが「Ｌｉｎｕｘ」であることを思い出す。ユーザは、プラットフォームフィールドについてこの選択を行う。バージョンフィールドのデフォルトは、値「ＲｅｄＨａｔ」であり、パッチフィールドのデフォルトは、「Ｎｏｎｅ」である。

１１．５．７ Ｌｉｎｕｘ、Ｏｔｈｅｒ、Ｐａｔｃｈを入力し、保存する
ユーザは、新しいワークアイテムを開く。プラットフォーム、バージョン、およびパッチのデフォルトは、「Ｗｉｎｄｏｗｓ（登録商標）」、「ＸＰ」、および「Ｎｏｎｅ」である。ユーザは、プラットフォームに「Ｌｉｎｕｘ」を選択する。バージョンフィールドが無効として強調表示される（ＸＰを有する）。ユーザは、バージョンに「Ｏｔｈｅｒ」を選択する。パッチフィールドは、「Ｎｏｎｅ」のままになる。ユーザは、「Ｎｏｎｅ」を選択し、このフィールドをクリアする。ユーザは、パッチフィールドに「ＢＬ５」を入力し、保存する。

１２ 状態モデルの拡張
ユーザは、状態フィールドに結び付けられた「Ｓｕｂ−Ｓｔａｔｅ」フィールドを作成することによって、ｏｕｔ−ｏｆ−ｔｈｅ−ｂｏｘワークフローを拡張することを望む。Ｓｕｂ−ｓｔａｔｅは、ワークアイテムが所与の状態である間の状況を示し、Ｓｔａｔｅ変化がある時に必ずクリアされなければならない。

１２．１ ＸＭＬサンプル

１２．２ ユーザインタフェースハンドリング
状態が変化した時に、必ず「ＳｕｂＳｔａｔｅ」フィールド値をクリアする。状態ごとに、許容される値のドロップダウンリストが、ユーザがそれから選択するのに使用可能である。

１２．３ ＯＭ／ＢＲＩＥハンドリング
＜ＲＥＱＵＩＲＥＤ／＞ルールがないので、ワークアイテムをＳｕｂＳｔａｔｅ値なしで保存することができる。所与の状態である時に、値は、許容される値のリストのうちの１つまたは空でなければならない。

１２．４ ルールスコープハンドリング
状態が何になろうとしているかにかかわりなく、状態が変化する時に、必ずクリア動作が行われる。

１２．５ シナリオ
１２．５．１ Ｓｕｂ−Ｓｔａｔｅの割り当て
ユーザは、既存ワークアイテムを開く。状態は、「ＡＣＴＩＶＥ」であり、サブ状態フィールドは、空である。ユーザは、サブ状態フィールドのドロップダウンを選択し、「Ｂｌｏｃｋｅｄ」、「Ｉｎｖｅｓｔｉｇａｔｉｎｇ」、および「Ｆｉｘｉｎｇ」という選択肢を得る。ユーザは、「Ｆｉｘｉｎｇ」を選択し、ワークアイテムを保存する。

１２．５．２ Ｓｔａｔｅの変更およびＳｕｂ−Ｓｔａｔｅを空のままにすること
ユーザは、既存ワークアイテムを開く。状態は、「ＡＣＴＩＶＥ」であり、サブ状態フィールドは、「Ｆｉｘｉｎｇ」である。ユーザは、状態を「ＡＣＴＩＶＥ」から「ＲＥＳＯＬＶＥＤ」に変更する。サブ状態フィールドがクリアされる。ユーザは、ワークアイテムを保存する。

１２．５．３ 無効な状態
ユーザは、既存ワークアイテムを開く。状態は、「ＡＣＴＩＶＥ」であり、サブ状態フィールドは、空である。ユーザは、サブ状態値「Ｏｎ Ｈｏｌｄ」をタイプする。フィールドが、無効として強調表示される。ユーザは、サブ状態フィールドのドロップダウンを選択し、「Ｂｌｏｃｋｅｄ」を選択し、ワークアイテムを保存する。

１３ Ｉｎｔｅｇｅｒフィールド値を検証する
カスタマは、フィールドに整数値を望むが、正しいエントリを制限することを望む。

１３．１ ＸＭＬサンプル
次の例では、カスタマが、優先順位を１と５の間の整数値にすることを望む。

１３．２ ユーザインタフェースハンドリング
ユーザは、優先順位フィールドに手で値を入力する。これが最小／最大ルールを満足しない場合に、そのフィールドを強調表示して、その値が不正であることをユーザに示さなければならない。ユーザは、そのフィールド上で移動（ｈｏｖｅｒ）して、ヘルプテキスト（有用でなければならない）を得ることができる。ユーザが問題を訂正したならば、強調表示が除去される。

１３．３ ＯＭ／ＢＲＩＥハンドリング
バックエンドは、値が最小／最大制約を満足しない場合にエラーにならなければならない。

１３．４ ルールスコープハンドリング
ルールは、加法的であり、したがって、有効な範囲は、制約の交わりである。したがって、例えば、グローバル制約が＜ＭＩＮ ｖａｌｕｅ＝’５’＞であり、状態固有制約が＜ＭＡＸ ｖａｌｕｅ＝’２０’＞であり、遷移固有制約が＜ＭＩＮ ｖａｌｕｅ＝’８’／＞であり、理由固有制約が＜ＭＡＸ ｖａｌｕｅ＝’１０’＞である場合に、所与の状態のワークアイテムについて、特定の遷移中に、この理由を与えられれば、正しい値は８〜１０の範囲内になる。

有効フィールドおよび無効フィールドについては、下のシナリオを参照されたい。

１３．５ シナリオ
１３．５．１ Ｍｉｎのみ
＜ＭＩＮ ｖａｌｕｅ＝’−５’／＞を検討されたい。正しい値は、−５以上である。

１３．５．２ Ｍａｘのみ
＜ＭＡＸ ｖａｌｕｅ＝’１００’を検討されたい。正しい値は、１００以下である。

１３．５．３ ＭｉｎおよびＭａｘ、有効
＜ＭＩＮ ｖａｌｕｅ＝’１’／＞ ＜ＭＡＸ ｖａｌｕｅ＝’５’／＞を検討されたい。正しい値は、両端を含めて１〜５である。

１３．５．４ ＭｉｎおよびＭａｘ、端
＜ＭＩＮ ｖａｌｕｅ＝’５’／＞ ＜ＭＡＸ ｖａｌｕｅ＝’５’／＞を検討されたい。このフィールドは唯一の正しい値を有し、その値は５である。この場合に、ＵＩは、フィールドにまだ値がない場合に、フィールド値を５というデフォルトにしなければならない。

１３．５．５ ＭｉｎおよびＭａｘ、無効
＜ＭＩＮ ｖａｌｕｅ＝’１０’／＞ ＜ＭＡＸ ｖａｌｕｅ＝’５’／＞を検討されたい。正しい値はない。インポータは、この状態を把握し、ワークアイテムタイプのプロビジョニングに失敗しなければならない。

１３．５．６ スコープ付きのＭｉｎのみ、有効
ある最小値ルールが、状態に関わりなくフィールドについて指定され、状態固有であるもう１つの最小値ルールが指定されていると考えられたい。次のケースおよび結果のそれぞれが、（フィールドレベル／状態レベル）最小値について処理されなければならない。
・ １０／５（より小さいｍｉｎ）
○ 正しい値は１０以上である。ルールは、加法的であり、より制限的であり、したがって、ここではグローバルルールが優先される。
・ １０／２０（より大きいｍｉｎ）
○ 状態固有である時を除いて、正しい値は１０以上である。状態固有である時には、このフィールドは２０以上でなければならない。

１３．５．７ スコープ付きのＭａｘのみ
ある最大値ルールが、状態に関わりなくフィールドについて指定され、状態固有であるもう１つの最大値ルールが指定されていると考えられたい。次のケースおよび結果のそれぞれが、（フィールドレベル／状態レベル）最大値について処理されなければならない。
・ １０／５（より小さいｍａｘ）
○ 状態固有の時を除いて、正しい値は、１０以下である。状態固有の時には、このフィールドは５以下でなければならない。
・ １０／２０（より大きいｍａｘ）
○ 正しい値は、１０以下である。ルールは、加法的であり、より制限的であり、したがって、ここではグローバルルールが優先される。

１３．５．８ スコープ付きのＭｉｎ／Ｍａｘ
最小値ルールと最大値ルールの両方が、状態に関わりなくフィールドについて指定され、状態固有であるもう１つの最小値／最大値ルールが指定されていると考えられたい。次のケースおよび結果のそれぞれが、（最小−最大グローバルレベル／最小−最大状態レベル）について処理されなければならない。
・ １０−２０／５−８（内側）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、５〜８である。
・ １０−２０／５−２５（外側）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、同一の１０〜２０である。
・ １０−２０／５−１５（下側スパン）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、１０〜１５である。
・ １０−２０／１５−２５（上側スパン）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、１５〜２０である。
・ １０−２０／１０−３０（同一のｍｉｎ、より大きいｍａｘ）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、同一の１０〜２０である。
・ １０−２０／１０−１５（同一のｍｉｎ、より小さいｍａｘ）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、１０〜１５である。
・ １０−２０／５−２０（より小さいｍｉｎ、同一のｍａｘ）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、５〜２０である。
・ １０−２０／１５−２０（より大きいｍｉｎ、同一のｍａｘ）
○ 正しい値は、１０〜２０であり、状態固有の正しい値は、１５〜２０である。

１３．５．９ スコープ付きのＭｉｎ／Ｍａｘ、無効
次のシナリオは、無効であり、インポータは、これらを把握し、プロビジョニング中にエラーにならなければならない。
・ １０−２０／１−５
・ １０−２０／２５−３０
○ 両方が、グローバルには正しいが、状態固有の正しい値がない。

１４ Ｓｔｒｉｎｇフィールド値を検証する
時々、＜ＡＬＬＯＷＥＤＶＡＬＵＥＳ＞を使用して行われるように、ストリングフィールドの値の明示的なリストを指定するのではなく、ワークアイテムタイプ作成者が、ストリングエントリへのある規則を実施することを望む。これのよい例が、ビルドｉｄまたはバージョンｉｄである。これは、＜ＭＡＴＣＨ＞句を使用して行われる。

マッチングは、すべての可能なｉｄを列挙したくない場合に、数を含むｉｄを指定するために行うこともできる。

ストリング検証が、必ず大文字小文字を区別しないことに留意されたい。

１４．１ ＸＭＬサンプル

１４．２ ユーザインタフェースハンドリング
理想的には、ユーザインタフェースは、無効なストリング値が入力された場合に強調表示する。しかし、私は、これがＰ２であると考える。最高の優先順位は、ユーザがフィールド上で移動（ｈｏｖｅｒ）した場合にフィールドのヘルプテキストを表示することである。我々は、フィールドのフォーマット要件がヘルプテキストで表示されることを推奨する。

１４．３ ＯＭ／ＢＲＩＥハンドリング
バックエンドは、フィールドの値が＜ＭＡＴＣＨ＞ストリングに従うことを検証しなければならない。無効であるフィールドおよびマッチストリングを含むフィールド（ユーザがヘルプテキストをミスタイプした場合）の両方について、エラーをユーザに報告しなければならない。

１４．４ ルールスコープハンドリング
＜ＤＥＦＡＵＬＴ＞ルールと同様に、＜ＭＡＴＣＨ＞は、互いにオーバーライドしなければならず、加法的ではない。

１４．５ シナリオ
有効な組合せと無効な組合せの両方および複数のマッチストリングをテストしなければならない。

１５ ＤａｔｅＴｉｍｅフィールド値を検証する
カスタマは、ユーザが日付または日時を入力することを望むが、入力された値が正しいことを保証することを望む。これは、＜ＶＡＬＩＤＤＡＴＥ＞コンストラクトを使用して行われる。

１５．１ ＸＭＬサンプル
カスタマが作成を試みる可能性があるサンプルのワークアイテムタイプ定義を説明する。
＜ＶＡＬＩＤＤＡＴＥ ｍｕｓｔｂｅ＝’ａｆｔｅｒ ｎｏｗ’／＞
日付フィールドを検証する。Ｍｕｓｔｂｅ値は、「ａｆｔｅｒ ｎｏｗ」または「ｎｏｔ ａｆｔｅｒ ｎｏｗ」のいずれかとすることができる。「ａｆｔｅｒ ｎｏｗ」は、現在時刻の後である。「ｎｏｔ ａｆｔｅｒ ｎｏｗ」は、フィールド値が現在時刻またはそれ以前であることを要求する。ＤａｔｅＴｉｍｅフィールドタイプに使用される。

１５．２ ユーザインタフェースハンドリング
望まれるＵＩハンドリングを、下でシナリオごとに説明する。

１５．３ ＯＭ／ＢＲＩＥハンドリング
望まれるＯＭ／ＢＲＩＥハンドリングを、下でシナリオごとに説明する。

１５．４ ルールスコープハンドリング
＜ＶＡＬＩＤＤＡＴＥ＞ルールは、加法的である。「ａｆｔｅｒ ｎｏｗ」ルールと「ｎｏｔ ａｆｔｅｒ ｎｏｗ」ルールの両方を有することは、不正である。このケースは、プロビジョニング時に把握されなければならない。

１５．５ シナリオ
１５．５．１ 現在時刻をデフォルトとし、ユーザが後の時刻にオーバーライドできるようにする
ユーザは、タスクが完了のためにスケジューリングされた時に、フィールドが時刻を保持することを望む。ユーザは、正しいフォーマットの考え方をユーザに与えるために現在時刻をデフォルトにすることを望むが、ユーザがその値をオーバーライドできるようにすることを望む。ユーザは、入力される時刻が現在または将来であることを保証することを望む。最後に、タスクが完了した場合に、ユーザは、ヒストリック監査のためにその値を読み取り専用にすることを望む。

ユーザは、新しいワークアイテムを作成し、Ｅｓｔｉｍａｔｅｄ Ｄａｔｅフィールドは、将来の値を含まなければならない。

ユーザは、タスクをもう一度開き、推定日時フィールドは、まだ編集可能である。ユーザは、Ｓｔａｔｅフィールドのドロップダウンを選択し、その値をＣｏｍｐｌｅｔｅに変更する。Ｅｓｔｉｍａｔｅｄ Ｄａｔｅフィールドが、編集不能に変化する。

１５．５．２ 日付を将来にすることが絶対にできない
ユーザは、バグがクローズされた日付を保持するフィールドを有することを望む。ユーザは、ユーザがバグを保存する時にこれが書き込まれることを望み、ユーザがこのフィールドを直接に変更できることを望まない。ユーザは、ＣＬＯＳＥＤ状態でない限りこのフィールドが空のままになり、ＣＬＯＳＥＤ状態ではこのフィールドがＲＥＱＵＩＲＥＤになることを望む。ユーザは、ＯＭを介するすべての変更が、このフィールドに将来の日付を絶対に置かないことを保証することも望む。次のＸＭＬは、ワークアイテムタイプ作成者がこの問題にどのようにアプローチするかである。

ユーザは、新しいバグをサブミットし、Ｆｉｘｅｄ Ｏｎフィールドは、空であり、編集不能である。ユーザは、バグを開き、状態をＲＥＳＯＬＶＥＤからＣＬＯＳＥＤに変更する。フィールドＦｉｘｅｄ Ｏｎは、現在時を書き込まれ、編集不能である。ユーザは、会議のために中断する。１時間後に、ユーザは、変更を保存する。Ｆｉｘｅｄ Ｏｎフィールドの古い時刻は、バグ変更がコミットされている時のサーバ時刻に更新される。

１６ インデクシングを使用するクエリ性能の改善
ワークアイテムタイプ作成者は、新しいフィールドＣｕｓｔｏｍｅｒＩＤを追加しており、彼は、このフィールドがクエリに激しく使用されることを知っている。彼は、これに関するクエリ性能が非常によいことを保証することを望む。

１６．１ ＸＭＬサンプル

１６．２ ユーザインタフェースハンドリング
エンドユーザＵＩ変更は不要である。ワークアイテムタイプエディタは、ユーザが、フィールドがインデックス付きであるか否かを調べることを可能にする。

および、その値を変更することを可能にする？
１６．３ ＯＭ／ＢＲＩＥハンドリング
フィールドは、インデクシングされる。

１６．４ ルールスコープハンドリング
適用可能ではない。

１６．５ シナリオ
我々は、これが性能を改善することを検証しなければならない。例えば、１００００個のレコードを作成する。クリアキャッシュおよびロードされたキャッシュを用いてクエリ性能をテストする。ワークアイテムタイプエディタを使用して、インデクシングされる主フィールドを変更する。クエリを再実行する。期待される挙動は、クリアキャッシュに関する性能を大きく改善する。キャッシングされたデータに関して、性能改善はわずかであるか、ない。

１７ レポートにカスタムフィールド値を含める
ワークアイテムタイプ作成者は、新しいフィールドＣｕｓｔｏｍｅｒＩＤを追加しており、彼は、このフィールドがレポートに激しく使用されることを知っている。彼は、カスタマｉｄデータがデータウェアハウスで使用可能であることを保証することを望む。

１７．１ ＸＭＬサンプル

１７．２ ユーザインタフェースハンドリング
エンドユーザインタフェース変更は不要である。Ｒｏｓｅｔｔａレポートライタは、このフィールドがウェアハウスに送られたならば、このフィールドをレポートでの使用に使用可能にしなければならない。ワークアイテムタイプエディタは、作成者が、フィールドがレポート可能であるか否かを調べることを可能にしなければならない。

１７．３ ＯＭ／ＢＲＩＥハンドリング
このフィールドの値を有するすべてのワークアイテムを、適当に定義された間隔でウェアハウスに送らなければならない。

１７．４ ルールスコープハンドリング
適用可能ではない。

１７．５ シナリオ
カスタムフィールドを有する新しいワークアイテムタイプをプロビジョニングする。いくつかのワークアイテムを作成する。Ｒｏｓｅｔｔａに移り、そのカスタムフィールドを使用するレポートを作成する。レポートを実行して、それが動作することを検証する。

１８ 監査証跡を実施する
Ｃｕｒｒｉｔｕｃｋを使用して、ユーザは、ワークアイテムタイプに関する彼らの状態を定義することができる。状態名に対する制約がないことに留意することが重要である。我々は、ワークアイテムのリビジョンごとに変更されたもののフル監査証跡に似た、ワークアイテムタイプの監査のいくつかのコアレベルを提供し、Ｃｒｅａｔｅｄ Ｏｎ値、Ｃｒｅａｔｅｄ Ｂｙ値、Ｌａｓｔ Ｍｏｄｉｆｉｅｄ Ｏｎ値、およびＬａｓｔ Ｍｏｄｉｆｉｅｄ Ｂｙ値を追跡する。

カスタマは、ヒストリログ（すなわち、会話コントロール）から、状態への出入りの情報を得ることができるが、カスタマは、ワークアイテムが最後にいつ特定の状態に入ったまたは出たかならびに誰がその状態に入ったまたは出たかに関するクエリを実行できることを望む場合がある。カスタマは、この情報がユーザ変更可能ではなくなり、セキュア監査証跡を有することも望む。これは、彼ら自身の状態に関するＲｅｓｏｌｖｅｄ ＯｎおよびＲｅｓｏｌｖｅｄ Ｂｙ（Ｒｅｓｏｌｖｅｄから出る）またはＡｃｔｉｖａｔｅｄ ＯｎおよびＡｃｔｉｖａｔｅｄ Ｂｙ（Ａｃｔｉｖｅに入る）などのクエリをサポートする。次のサンプルで、Ｒｅｓｏｌｖｅｄ Ｏｎ状態およびＲｅｓｏｌｖｅｄ Ｂｙ状態に関してこれをどのように行うかを識別する。

１８．１ ＸＭＬサンプル

１８．２ ユーザインタフェースハンドリング
これらのルールは、ワークアイテムがＡｃｔｉｖｅであり、Ｒｅｓｏｌｖｅｄ ＯｎフィールドおよびＲｅｓｏｌｖｅｄ Ｂｙフィールドが空である時を示す。これらのフィールドは、ＵＩでは読み取り専用に見え、値を有しない。

ワークアイテムがＲｅｓｏｌｖｅｄである時に、これらのフィールドはＲＥＱＵＩＲＥＤであり（空にしてはならない）、最初の更新時のサーバ時刻および現在ユーザにセットされ、フリーズされる。ＲＥＱＵＩＲＥＤは、フィールドが値を有することを保証する。ＳＥＲＶＥＲＤＥＦＡＵＬＴによって、このワークアイテムがＲｅｓｏｌｖｅｄ状態で初めて保存される時に、これにサーバ時刻およびユーザがセットされる。ＦＲＯＺＥＮは、Ｒｅｓｏｌｖｅｄ Ｏｎ値およびＲｅｓｏｌｖｅｄ Ｂｙ値が、セットされた後に変更されないことを保証する。

このワークアイテムがクローズされた時、これらのフィールドはＲＥＱＵＩＲＥＤ（値を有しなければならない）であり、ＦＲＯＺＥＮ（誰もその値を変更できない）である。

このワークアイテムが再アクティブ化された（Ａｃｔｉｖｅ状態に遷移した）時には、これらのフィールドはクリアされる。

１８．３ ＯＭ／ＢＲＩＥハンドリング
このシナリオは、より複雑であり、複数のルール、＜ＥＭＰＴＹ／＞、＜ＦＲＯＺＥＮ／＞、＜ＳＥＲＶＥＲＤＥＦＡＵＬＴ＞、および＜ＲＥＱＵＩＲＥＤ／＞の調整を示す。これらのルールは、ユーザがカスタム状態を監査することを可能にするために、共同して働かなければならない。

１８．４ ルールスコープハンドリング
適用可能ではない。

１８．５ シナリオ
上を参照されたい。

１９ ユーザ／グループによるトランザクションを許可しない
カスタマは、遷移にセキュリティを適用し、一部のユーザおよびグループがある遷移を行うことを許可され、それ以外のものが同一のことを行うことを拒絶されることを望む。

１９．１ ＸＭＬサンプル

１９．２ ユーザインタフェースハンドリング
Ｖ１について、特別なユーザインタフェースハンドリングはない。Ｖ１ｂａｒ以降に進むと、我々は、ユーザがその遷移を行うアクセス権を有しないことを我々が知っている場合に状態フィールドのドロップダウンリストから状態値を除去する。

１９．３ ＯＭ／ＢＲＩＥハンドリング
バックエンドは、ワークアイテムタイプの保存を許可する前に、ユーザが状態遷移を行うアクセス権を有することを保証しなければならない。ユーザがアクセスを拒絶される場合に、バックエンドは、ＵＩを介してレポートし、エラーにならなければならない。例えば、「You do not have permission to transition the work item from Resolved to Complete state」（ワークアイテムをＲｅｓｏｌｖｅｄ状態からＣｏｍｐｌｅｔｅ状態に遷移させるアクセス権がありません）。

１９．４ ルールスコープハンドリング
適用可能ではない。これらのコンストラクトは、遷移だけについて有効である。

１９．５ シナリオ
１９．５．１ ＡｌｌＴｅｓｔｅｒｓのメンバ
ユーザは、遷移を実行することを許可される。

１９．５．２ ＮｅｗＴｅｓｔｅｒｓのメンバ
ユーザは、遷移を実行することを許可されない。

１９．５．３ ＡｌｌＴｅｓｔｅｒｓとＮｅｗＴｅｓｔｅｒｓの両方のメンバ
ユーザは、遷移を実行することを許可されない。拒絶が優先する。

１９．５．４ ＡｌｌＴｅｓｔｅｒｓおよびＮｅｗＴｅｓｔｅｒｓのどちらのメンバでもないメンバ
ユーザは、遷移を実行することを許可されない。任意のＡＬＬＯＷ／ＤＥＮＹコンストラクトが、暗黙の「このワークアイテムへのアクセスを有する誰もが、遷移を許可される」を制限する。

１９．５．５ あるユーザだけを許可する
特定のユーザを、これらのルールについて指定することができるが、遷移ごとに１つの＜ＡＬＬＯＷ＞または＜ＤＥＮＹ＞だけを設けることができる。
未解決の問題：このステートメントを検証せよ。

２０ 終盤でコードレビューを要求する
ワークアイテムタイプ作成者は、開発プロジェクトが終盤である時に、すべてのバグが、割り当てられたユーザ以外の誰かによってコードレビューされなければならないという会社ポリシを実施することを試みている。彼らは、このプロセスを誰もが回避しないことを保証することも望む。

私は、我々が有しないこのルールを実装するために３つのことを必要とする
フィールド値を現在のユーザと比較するＷＨＥＮ句：<WHEN field="fieldname" value=currentuser>
フィールドが特定の値でない時に遷移を停止する句：<ALLOWWHEN field="fieldname" value="somevalue">
<ALLOWWHEN>ルールをバイパスする方法
このすべてから、私は、我々がこのシナリオを再訪し、これを最もよくサポートする方法を調べる必要があると考える。

２０．１ ＸＭＬサンプル

２０．２ ユーザインタフェースハンドリング
下で説明する。

２０．３ ＯＭ／ＢＲＩＥハンドリング
下で説明する。

２０．４ ルールスコープハンドリング
適用可能ではない。

２０．５ シナリオ
２０．５．１ プロジェクトが終盤に入る
プロジェクトが終盤に入った時に、ワークアイテムタイプ作成者は、コードレビューを実行せずにＲｅｓｏｌｖｅｄに遷移することを効果的に停止させるルール＜ＡＬＬＯＷＷＨＥＮ＞を追加する。

２０．５．２ バグがＢｏｂによって修正される
Ｂｏｂは、割り当てられたバグを修正する。Ｂｏｂは、彼らが終盤にいることの電子メールを読む暇がなく、したがって、誰にもコードレビューを要求しなかった。Ｂｏｂは、Ｓｔａｔｅを選択し、その値を「Ａｃｔｉｖｅ」から「Ｒｅｓｏｌｖｅｄ」に変更する。通常通り、終盤の前に、Ｒｅｖｉｅｗｅｄフィールドには「ｎｏｔｄｏｎｅ」がセットされ、Ｒｅｖｉｅｗ Ｎｏｔｅｓは空である。この両方のフィールドが、読み取り専用である。

Ｂｏｂは、保存を選択する。バックエンドは、エラー「Unable to transition from Active to Resolved, the field "Reviewed" must have the value "passed"」（ＡｃｔｉｖｅからＲｅｓｏｌｖｅｄに遷移できません。フィールド「Ｒｅｖｉｅｗｅｄ」は値「ｐａｓｓｅｄ」を有しなければなりません）を報告する。Ｂｏｂは、プロジェクトが終盤であることと、自分の変更をコードレビューさせる必要があることとを知る。

ＯＫ、私の夢では、Ｂｏｂは、ワークアイテムを右クリックし、「Ｓｅｎｄ ｔｏ．．．」を選択し、これによって、このバグへのＵＲＬを含む電子メールメッセージが作成される。Ｂｏｂは、コードレビューするようにＳａｍに求めるテキストをタイプする。

２０．５．３ バグが、Ｓａｍによってレビューされる
Ｓａｍは、バグのところに行き、ｌｉｎｋｓタブを調べる。Ｓａｍは、Ｂｏｂが行った変更セットへのリンクを見る。Ｓａｍは、そのリンクをダブルクリックして、Ｈａｔｔｅｒａｓに行き、各ソースファイルを選択し、「ｄｉｆｆ ｗｉｔｈ ｐｒｅｄｅｃｅｓｓｏｒ」を行う。レビューの後に、Ｓａｍは、バグを立ち上げる。

Ｒｅｖｉｅｗｅｄフィールドは、Ｓａｍには読み取り専用ではなく、Ｓａｍは、その値を「ｐａｓｓｅｄ」に変更する。その時に、Ｒｅｖｉｅｗ Ｎｏｔｅｓフィールドが、ＲＥＱＵＩＲＥＤとして強調表示される。Ｓａｍは、手短に書き込む。強調表示がオフになり、Ｓａｍは、バグを保存し、Ｂｏｂに電子メールを送る。

２０．５．４ Ｂｏｂがバグを解決する
Ｂｏｂは、バグを立ち上げ、ＡｃｔｉｖｅからＲｅｓｏｌｖｅｄに遷移する。これは、今回はうまくいく。

２０．５．５ バグが例外を与えられる
もう１つの場合に、バグが、レビューなしで持ち込まれる必要がある場合があり、ある人がこのプロセスをバイパスする方法が必要である。この場合に、＜ＡＬＬＯＷ＞ルールは、＜ＡＬＬＯＷＷＨＥＮ＞ルールに優先する。ＴｒｉａｇｅＬｅａｄは、コードレビューされたか否かに関わりなく、バグを解決することができる。

２１ リストシナリオを通知する
ここでの基本的なシナリオは、カスタマが、所与のワークアイテムの通知リストを維持することを望むというものである。その通知リストに含まれるすべてのメンバが、ワークアイテムが編集された時に必ず電子メールを送られる。

私は、ＢＩＳイベント通知がこのシナリオをサポートするかどうか確信がない。サポートしないと仮定すると、私は、次のようなことを試みるであろう。これが、おそらくはＷＩＴの問題ではなく拡張性の問題であることに留意されたい。

私は、この仕様書からこれを除去するつもりであるが、今すぐ捨てたくはない。

２１．１ ＸＭＬサンプル

２１．２ ユーザインタフェースハンドリング
適用可能ではない。

２１．３ ＯＭ／ＢＲＩＥハンドリング
適用可能ではない。

２１．４ ルールスコープハンドリング
適用可能ではない。

２１．５ シナリオ
ユーザは、ワークアイテム変化イベントをリスン（ｌｉｓｔｅｎ）するイベントハンドラを記述する。イベントが到着し、「ＮｏｔｉｆｙＬｉｓｔ」フィールドに値がある場合に、このハンドラは、電子メールを構成し、通知リスト内の全ユーザに送信する。

２２ 複製リンクを要求する
カスタマは、次のルールを実施することを望む。バグが解決され、理由が「Ｄｕｐｌｉｃａｔｅ」である場合に、少なくとも１つの複製リンクが確立されていることを必要とする。

私は、ここで新しいものを１つ必要とする：
１）そのフィールドをテストする方法、＜ＡＬＬＯＷＷＨＥＮ ｇｒｅａｔｅｒｔｈａｎ＝’０’を使用した
もちろん、これは、ｌｅｓｓｔｈａｎ、ｅｑｕａｌｓ、ｎｏｔｅｑｕａｌｓなどのすべてを暗示する。

我々は、これを調査する必要がある。というのは、これが、我々がよい答えを有しないと私が思う単純な作業であるからである。

２２．１ ＸＭＬサンプル

２２．２ ユーザインタフェースハンドリング
下を参照されたい。

２２．３ ＯＭ／ＢＲＩＥハンドリング
バックエンドは、リンクタイプごとにコアフィールドを維持し、作成されたタイプのリンクの個数のカウントを記録しなければならない。

２２．４ ルールスコープハンドリング
適用可能ではない。

２２．５ シナリオ
ユーザは、複製リンクを確立せずに、ワークアイテムを、理由ＤｕｐｌｉｃａｔｅとしてＲｅｓｏｌｖｅｄに遷移させることを試みる。提供されるエラー「You are unable to transition to Resolved for reason Duplicate, field DuplicateLinkCount must be greater than 0」（理由ＤｕｐｌｉｃａｔｅでＲｅｓｏｌｖｅｄに遷移することはできません。フィールドＤｕｐｌｉｃａｔｅＬｉｎｋＣｏｕｎｔが０より大きくなければなりません）。

本発明のいくつかの実施形態による、ワークアイテムトラッキングシステムのワークアイテムルールを実施するシステムの例を示すブロック図である。 本発明のいくつかの実施形態による、ワークアイテムタイプ定義の例を示す図である。 本発明のいくつかの実施形態による、ワークアイテムタイプ定義のフィールドセクションの例を示す図である。 本発明のいくつかの実施形態による、ワークアイテムタイプ定義のワークフローセクションの例を示す図である。 本発明のいくつかの実施形態による、遷移ルールの例を示す図である。 本発明のいくつかの実施形態による、ユーザがプロダクトツリーのノードを選択することを可能にするためにユーザに提供されうるユーザインタフェースディスプレイの例を示すスクリーンショットである。 本発明のいくつかの実施形態による、ユーザが１つまたは複数のセキュリティベースのワークアイテムルールを指定することを可能にするユーザインタフェースディスプレイの例を示すスクリーンショットである。 本発明のいくつかの実施形態による、ユーザが１つまたは複数のセキュリティベースのワークアイテムルールを指定することを可能にするユーザインタフェースディスプレイの例を示すスクリーンショットである。 本発明のいくつかの実施形態による、ワークアイテムを作成し、および／または変更するユーザインタフェースディスプレイの例を示すスクリーンショットである。 本発明のいくつかの実施形態による、ワークアイテムトラッキングシステムでワークアイテムルールを実施する方法の例を示す流れ図である。 本発明のいくつかの実施形態を実施できるコンピュータシステムの例を示すブロック図である。 本発明のいくつかの実施形態を実施するためにコンピュータシステムの一部として使用することができるストレージシステムの例を示すブロック図である。

符号の説明

１０２ ＷＩＴＳクライアント
１０４ ＷＩＴＳクライアント
１０６ ＷＩＴＳクライアント
１１０ ワークアイテムＩＦ
１１２ セキュリティＩＦ
１１４ クライアントＷＩＲエンジン
１１６ ＷＩＲキャッシュ
１１８ ネットワーク
１２０ ＷＩＴＳサーバ
１２２ ＷＩＲクライアント／サーバＩＦ
１２４ サーバＷＩＲエンジン
１２８ ＷＩＴＳ情報
１３０ ＷＩＲ情報
１１０１ 出力デバイス
１１０２ 入力デバイス
１１０３ プロセッサ
１１０４ メモリ
１１０５ 相互接続機構
１１０６ ストレージ
１２０２ ストレージシステムメモリ

Claims (14)

1. サーバと少なくとも１つのクライアントコンピュータとを含むワークアイテムトラッキングシステムの１つまたは複数のワークアイテムに影響するクライアントコンピュータアクションを統制するコンピュータ実装方法であって、
   前記システムは、論理階層に編成された複数のワークアイテムを備え、第１のワークアイテムは、前記階層の第１のレベルに対応し、第２のワークアイテムは、前記第１のレベルに優先する前記階層の第２のレベルに対応し、
   前記方法は、
   （Ａ）前記コンピュータのプロセッサが、前記ワークアイテムトラッキングシステムの第１のワークアイテムに影響する、第１のクライアントコンピュータによる第１のクライアントコンピュータアクションに応答して、前記第１のクライアントコンピュータおよび／または前記第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定する動作であって、前記第１のワークアイテムに対応する第１のワークアイテムルールを判定することと、前記第２のワークアイテムに対応する第２のワークアイテムルールを判定することとを含む動作と、
   （Ｂ）前記コンピュータのプロセッサが、前記１つまたは複数の判定されたワークアイテムルールを解釈する動作であって、前記第１および第２のワークアイテムルールを解釈することと、前記第１のレベルに優先する前記階層の前記第２のレベルに少なくとも部分的に基づいて、前記第１のワークアイテムルールの前記解釈を前記第２のワークアイテムルールの前記解釈によってオーバーライドすることとを含む動作と、
   （Ｃ）前記コンピュータのプロセッサが、前記１つまたは複数の判定されたワークアイテムルールの前記解釈に基づいて前記第１のクライアントコンピュータアクションに応答する動作と
   を含み、
   前記ワークアイテムトラッキングシステムは、少なくとも第１のネットワーク要素および１つまたは複数の通信媒体によって前記第１のネットワーク要素に接続された第２のネットワーク要素に渡って分散され、前記第１のネットワーク要素は、第１のモジュールを備え、前記第２のネットワーク要素は、第２のモジュールを備え、前記方法は、
   （Ｄ）前記第１のモジュールが前記第１のワークアイテムに影響する前記クライアントコンピュータアクションを指定する前記クライアントコンピュータからの入力を受け取る動作
   をさらに含み、前記動作（Ａ）〜（Ｃ）は、前記第１のモジュールによって実行され、前記方法は、
   （Ｅ）前記第２のモジュールが前記１つまたは複数の判定されたワークアイテムルールを解釈する動作
   をさらに含むことを特徴とする方法。
2. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、前記第１のクライアントコンピュータまたは前記第１のクライアントコンピュータが属する前記クライアントコンピュータのグループに対応し、
   前記動作（Ｂ）は、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項１に記載の方法。
3. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの内容に対応し、
   前記動作（Ｂ）は、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項１に記載の方法。
4. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの１つまたは複数のプロパティに対応し、
   前記動作（Ｂ）は、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項１に記載の方法。
5. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、プロダクトの少なくとも１つの態様に対応し、
   前記動作（Ｂ）は、前記少なくとも１つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項１に記載の方法。
6. （Ｄ）前記クライアントコンピュータが１つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェースを提供する動作
   をさらに含むことを特徴とする請求項１に記載の方法。
7. サーバと少なくとも１つのクライアントコンピュータとを含むワークアイテムトラッキングシステムの１つまたは複数のワークアイテムに影響するクライアントコンピュータアクションを統制するシステムであって、
   前記システムは、論理階層に編成された複数のワークアイテムを備え、第１のワークアイテムは、前記階層の第１のレベルに対応し、第２のワークアイテムは、前記第１のレベルに優先する前記階層の第２のレベルに対応し、
   前記ワークアイテムトラッキングシステムの第１のワークアイテムに影響する、第１のクライアントコンピュータによる第１のクライアントコンピュータアクションに応答して、前記第１のクライアントコンピュータおよび／または前記第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定し、前記１つまたは複数の判定されたワークアイテムルールを解釈し、前記解釈に基づいて前記第１のクライアントコンピュータアクションに応答する、第１のワークアイテムルールエンジンであって、
   前記第１のワークアイテムに対応する第１のワークアイテムルールを判定し、前記第２のワークアイテムに対応する第２のワークアイテムルールを判定するように動作し、
   前記第１および第２のワークアイテムルールを解釈し、前記第１のレベルに優先する前記階層の前記第２のレベルに少なくとも部分的に基づいて、前記第２のワークアイテムルールの前記解釈による前記第１のワークアイテムルールの前記解釈のオーバーライドを制御するように動作する、第１のワークアイテムルールエンジン
   を備え、
   前記第１のワークアイテムルールエンジンは、第１のネットワーク要素に常駐し、前記第１のワークアイテムルールエンジンは、前記第１のクライアントコンピュータアクションを指定する前記クライアントコンピュータからの入力を受け取るように動作し、
   １つまたは複数の通信媒体によって前記第１のネットワーク要素に接続された第２のネットワーク要素に常駐する第２のワークアイテムルールエンジンであって、前記第１のモジュールによって適用されるのと異なって前記１つまたは複数の判定されたワークアイテムルールを解釈するように動作する第２のワークアイテムルールエンジンをさらに備えることを特徴とするシステム。
8. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、前記第１のクライアントコンピュータまたは前記第１のクライアントコンピュータが属する前記クライアントコンピュータのグループに対応し、
   前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項７に記載のシステム。
9. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの内容に対応し、
   前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項７に記載のシステム。
10. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、ワークアイテムの１つまたは複数のプロパティに対応し、
    前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項７に記載のシステム。
11. 前記１つまたは複数の判定されたワークアイテムルールのうちの少なくとも１つは、プロダクトの少なくとも１つの態様に対応し、
    前記第１のワークアイテムルールエンジンは、前記少なくとも１つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項７に記載のシステム。
12. 前記クライアントコンピュータが１つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェース
    をさらに備えることを特徴とする請求項７に記載のシステム。
13. コンピュータ読み取り可能な記録媒体に保管され、コンピュータによって実行された結果として、サーバと少なくとも１つのクライアントコンピュータとを含むワークアイテムトラッキングシステムの１つまたは複数のワークアイテムに影響するクライアントコンピュータアクションを統制するプロセスを実行するように前記コンピュータを制御するプログラムであって、
    前記システムは、論理階層に編成された複数のワークアイテムを備え、第１のワークアイテムは、前記階層の第１のレベルに対応し、第２のワークアイテムは、前記第１のレベルに優先する前記階層の第２のレベルに対応し、
    前記プロセスは、
    （Ａ）前記コンピュータのプロセッサが、前記ワークアイテムトラッキングシステムの第１のワークアイテムに影響する、第１のクライアントコンピュータによる第１のクライアントコンピュータアクションに応答して、前記第１のクライアントコンピュータおよび／または前記第１のワークアイテムに対応する１つまたは複数のワークアイテムルールを判定する動作であって、前記第１のワークアイテムに対応する第１のワークアイテムルールを判定することと、前記第２のワークアイテムに対応する第２のワークアイテムルールを判定することとを含む動作と、
    （Ｂ）前記コンピュータのプロセッサが、前記１つまたは複数の判定されたワークアイテムルールを解釈する動作であって、前記第１および第２のワークアイテムルールを解釈することと、前記第１のレベルに優先する前記階層の前記第２のレベルに少なくとも部分的に基づいて、前記第１のワークアイテムルールの前記解釈を前記第２のワークアイテムルールの前記解釈によってオーバーライドすることとを含む動作と、
    （Ｃ）前記コンピュータのプロセッサが、前記１つまたは複数の判定されたワークアイテムルールの前記解釈に基づいて前記第１のクライアントコンピュータアクションに応答する動作と
    を含み、
    前記ワークアイテムトラッキングシステムは、少なくとも第１のネットワーク要素および１つまたは複数の通信媒体によって前記第１のネットワーク要素に接続された第２のネットワーク要素に渡って分散され、前記第１のネットワーク要素は、第１のモジュールを備え、前記第２のネットワーク要素は、第２のモジュールを備え、前記プロセスは、
    （Ｄ）前記第１のモジュールが前記第１のワークアイテムに影響する前記クライアントコンピュータアクションを指定する前記クライアントコンピュータからの入力を受け取る動作
    をさらに含み、前記動作（Ａ）〜（Ｃ）は、前記第１のモジュールによって実行され、前記プロセスは、
    （Ｅ）前記第２のモジュールが前記１つまたは複数の判定されたワークアイテムルールを解釈する動作
    をさらに含むことを特徴とするプログラム。
14. 前記プロセスは、
    （Ｄ）前記クライアントコンピュータが１つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェースを提供する動作
    をさらに含むことを特徴とする請求項１３に記載のプログラム。

Images