JP5238138B2 - ワークアイテムトラッキングシステム用のワークアイテムルール - Google Patents
ワークアイテムトラッキングシステム用のワークアイテムルール Download PDFInfo
- Publication number
- JP5238138B2 JP5238138B2 JP2006086542A JP2006086542A JP5238138B2 JP 5238138 B2 JP5238138 B2 JP 5238138B2 JP 2006086542 A JP2006086542 A JP 2006086542A JP 2006086542 A JP2006086542 A JP 2006086542A JP 5238138 B2 JP5238138 B2 JP 5238138B2
- Authority
- JP
- Japan
- Prior art keywords
- work item
- field
- rule
- rules
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000009471 action Effects 0.000 claims description 94
- 238000000034 method Methods 0.000 claims description 61
- 238000004891 communication Methods 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 14
- 230000008569 process Effects 0.000 claims description 13
- 230000001276 controlling effect Effects 0.000 claims 1
- 230000001105 regulatory effect Effects 0.000 claims 1
- 230000007704 transition Effects 0.000 description 143
- 230000008859 change Effects 0.000 description 82
- 239000000047 product Substances 0.000 description 62
- 230000006399 behavior Effects 0.000 description 23
- 230000015654 memory Effects 0.000 description 19
- 238000003860 storage Methods 0.000 description 18
- 238000005516 engineering process Methods 0.000 description 16
- 238000011156 evaluation Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 15
- 230000000007 visual effect Effects 0.000 description 14
- 230000001419 dependent effect Effects 0.000 description 13
- 239000000654 additive Substances 0.000 description 11
- 230000000996 additive effect Effects 0.000 description 11
- 238000013461 design Methods 0.000 description 11
- 230000010354 integration Effects 0.000 description 11
- 238000012552 review Methods 0.000 description 10
- 238000012360 testing method Methods 0.000 description 10
- 238000011161 development Methods 0.000 description 9
- 238000007726 management method Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 238000009826 distribution Methods 0.000 description 8
- 230000014509 gene expression Effects 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 8
- 238000012986 modification Methods 0.000 description 7
- 230000004048 modification Effects 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 6
- 238000013474 audit trail Methods 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 5
- 230000007547 defect Effects 0.000 description 5
- 238000012797 qualification Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 230000008520 organization Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000004807 localization Effects 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 238000012550 audit Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000007667 floating Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 241000143437 Aciculosporium take Species 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000012854 evaluation process Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000011867 re-evaluation Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- VOCBWIIFXDYGNZ-IXKNJLPQSA-N testosterone enanthate Chemical compound C1CC2=CC(=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H](OC(=O)CCCCCC)[C@@]1(C)CC2 VOCBWIIFXDYGNZ-IXKNJLPQSA-N 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
- F25—REFRIGERATION OR COOLING; COMBINED HEATING AND REFRIGERATION SYSTEMS; HEAT PUMP SYSTEMS; MANUFACTURE OR STORAGE OF ICE; LIQUEFACTION SOLIDIFICATION OF GASES
- F25B—REFRIGERATION MACHINES, PLANTS OR SYSTEMS; COMBINED HEATING AND REFRIGERATION SYSTEMS; HEAT PUMP SYSTEMS
- F25B21/00—Machines, plants or systems, using electric or magnetic effects
- F25B21/02—Machines, plants or systems, using electric or magnetic effects using Peltier effect; using Nernst-Ettinghausen effect
-
- A—HUMAN NECESSITIES
- A47—FURNITURE; DOMESTIC ARTICLES OR APPLIANCES; COFFEE MILLS; SPICE MILLS; SUCTION CLEANERS IN GENERAL
- A47J—KITCHEN EQUIPMENT; COFFEE MILLS; SPICE MILLS; APPARATUS FOR MAKING BEVERAGES
- A47J47/00—Kitchen containers, stands or the like, not provided for in other groups of this subclass; Cutting-boards, e.g. for bread
- A47J47/14—Carriers for prepared human food
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06311—Scheduling, planning or task assignment for a person or group
- G06Q10/063114—Status monitoring or status determination for a person or group
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06316—Sequencing of tasks or work
-
- F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
- F25—REFRIGERATION OR COOLING; COMBINED HEATING AND REFRIGERATION SYSTEMS; HEAT PUMP SYSTEMS; MANUFACTURE OR STORAGE OF ICE; LIQUEFACTION SOLIDIFICATION OF GASES
- F25B—REFRIGERATION MACHINES, PLANTS OR SYSTEMS; COMBINED HEATING AND REFRIGERATION SYSTEMS; HEAT PUMP SYSTEMS
- F25B2321/00—Details of machines, plants or systems, using electric or magnetic effects
- F25B2321/02—Details of machines, plants or systems, using electric or magnetic effects using Peltier effects; using Nernst-Ettinghausen effects
- F25B2321/023—Mounting details thereof
Landscapes
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Physics & Mathematics (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Educational Administration (AREA)
- Development Economics (AREA)
- Game Theory and Decision Science (AREA)
- Data Mining & Analysis (AREA)
- Food Science & Technology (AREA)
- Mechanical Engineering (AREA)
- Thermal Sciences (AREA)
- General Engineering & Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
Description
図1は、ワークアイテムトラッキングシステム(WITS)のワークアイテムルール(WIR)を実施するためのシステム100の例を示すブロック図である。システム100は、ワークアイテムトラッキングシステムのワークアイテムルールを実施するシステムの例示的な実施形態にすぎず、本発明の範囲を制限することを意図されたものではない。そのようなシステムの多数の他の実施形態、例えばシステム100の変形形態が可能であり、本発明の範囲に含まれることが意図されている。例えば、主にWIRに関する図100に示されたいくつかの要素は、多少はWITS要素内に統合されたものとして図示されている。しかし、WIR要素は、実際にはWITS要素と別々の別個の要素とすることができる。
1.ユーザ1が、グループAのメンバである。
2.第1のセキュリティベースのルールは、グループAのユーザがプロジェクトノード604のワークアイテムを編集することを許可されることを指定する。
3.第2のセキュリティルールは、ユーザ1がノード606のワークアイテムを編集することを許可されない(すなわち、拒絶される)ことを指定する。
4.プロジェクトノード604のノード606の下で、ユーザ1が、タイプ「bug」の第1のワークアイテムの優先順位フィールドの値に対する変更を保存することを試みる。
設計文書
ビジネスルールの説明および使用
目次
要約
設計目標および正当化
設計
ルールの評価
個々のルール
アイテム
フィールド
ツリーノード
定数および定数のセット
セキュリティおよび修飾(qualification)の実施のバイパス
admin onlyサブツリー
クライアントサイドルール評価エンジンの実装および制限
パフォーマンスアイテム
プログラム化可能性
ルールを操作し使用するストアドプロシージャ
ルールを操作するストアドプロシージャ
プロダクトツリーを操作するストアドプロシージャ
プロダクトフィールドを操作するストアドプロシージャ
プロダクトルールを作成するSQLのサンプル
ルールのサンプル
ノーダッシュ(no−dash)ドメインユーザに対する全アイテムについてのリスト読み取りアクセス権の許可
リストの1つへのノードタイプの制約
エリアタイプノードはサブエリアタイプノードまたはコンポーネントタイプノードを子として有することができる
「Redmond\pstest」のメンバは、ノード12をルートとするプロダクトツリーの枝の「Folder」タイプでないノードを作成することができない
タイトルは、全員の必須フィールドである
誰もが、かれらがオープンしたすべてのアイテムを読むことができる
Warはダイナミックリストである
Closed Dateは、状態がクローズドでない時について空でなければならない
「Redmond\markradp」配布リストのすべてのドメインユーザは、どこでも何でも行うことができる
ルールは、Team Foundation Serverのワークアイテムトラッキングのランタイムコンフィギュレーションの主要なソースである。ルールは、フィールドによって提供される柔軟性を拡張して、プロジェクトまたはサーバの寿命の間、管理者の未知のおよび変化するビジネスニーズを記述し、実施する。単一の機構が、これらのニーズに使用され、サーバの内容のセキュリティおよび保全性をカバーする。ルールは、クライアント、中間(Mid)、およびデータという、このアーキテクチャのすべてのティアの間で共有できるビジネスルールの定義を提供する。これらのルールは、宣言的(規定的でなく)であり、したがって、各ティアがその特定の環境に適当であるようにこれらのルールを解釈することができる。
目標は、
1)ワークアイテムトラッキングシステムで必要なビジネスルールを記述でき、
2)各プロダクトフィーチャの管理を委任できると同時に、より高いレベルの判断がより低いレベルで逆転またはバイパスされることを防ぐようにするためにプロダクトツリーを活用でき、
3)プロダクトツリーおよびドメイングループ/ユーザに基づくセキュリティセッティングを提供でき、
4)将来の要件を自然な形で追加できるのに十分にオープンエンデッドとすることができ、
5)許容不能に低速でないとすることができる
豊富なセットのプリミティブを提供することであった。
セキュリティおよびビジネスルールの実施は、中間ティアとデータティアとの間で共有される協力的努力である。それぞれが、非常に重要な態様について他方に頼り、どちらもが、単独では完全に効果的ではない。
1)中間ティアは、W2000統合認証を使用してドメインアカウントを識別する。
2)中間ティアは、この情報を使用して、データ読み取りにどのデータティアプリミティブを使用するかを判断する。
3)データ変更(挿入/更新)について、中間ティアは、
a)データティアプリミティブを使用してドメインユーザの内部IDを見つけ、
b)この内部IDを、それが変更するすべての行に保管し、
c)データティアプリミティブを呼び出して、それが行ったばかりの変更をオーソライズし、
d)何かが不首尾になった場合にトランザクションをロールバックする。
4)データティアは、セキュリティ環境を反映するドメインユーザごとのパーソナライズされたSQLビューを作成し、組み合わせることによって、「オーソライゼーション」プリミティブを提供する責任を負う。セキュリティ環境は、
a)アクティブディレクトリからインポートされ、データベース内にキャッシングされたドメインアカウント情報と、
b)現在のルール(「セキュリティ」、アイテム内容、および管理者データ内容をカバーする)
からなる。
5)低優先順位バックグラウンドタスクとして(クライアントクエリおよび更新などの有用なタスクのために大量のCPUを保存するために)、データティアは、
a)アクティブディレクトリからのユーザおよびグループメンバの情報を検証し、そのキャッシュを更新し、
b)セキュリティ環境の変更を組み込むために個々のドメインユーザのSQLビューを更新する。
擬似コードでは、あるアイテムのプロダクトルール評価が、
1.セキュリティプリンシパル(これを行う人)に適用されるすべてのルールを識別し、
2.セキュリティ対象(そのアイテムがあるプロダクトツリー内のノード)に適用されるすべてのルールを識別し、
3.そのアイテムの内容を使用してルールを評価する。
A)中間ティアは、同一の変更者IDおよびその変更の変更日付をすべての行に記録することによって、データベース変更をグループ化する。変更日付は、最初の変更が行われる前にとられた、SQL ServerのUTCシステムクロック時刻である。変更者IDは、その変更がそれのためであるドメインアカウントのコンスタントID(constant ID)である。0の変更者IDは、アプリケーションが開始した変更である。UTCは、「Universal Time Co−ordinated」(協定世界時)である。これは、ほとんどの形でGMTタイムゾーンの同義語であるが、UTCには「夏時間」がない。
B)読み取りは、特定のドメインアカウント用にパーソナライズされたSQLビューを介して行われる。中間ティアは、ドメインアカウントの名前に基づいてビューを選択する。ビューが存在しない場合には、中間ティアが実行するSQLバッチが、構文エラーを生成する。この場合に、中間ティアエラーパスが、ストアドプロシージャを呼び出して、欠けているパーソナルビューを再ビルドし、SQL selectを再試行する。
C)変更は、シリアライズ可能なトランザクション内で特定の順序で行われる。中間ティアは、最初からコミットまでのすべてを行うSQLバッチを生成する。このトランザクションがストアドプロシージャによってロールバックされた場合に、そのSQLバッチは、さらなるデータベース変更を行わずにリターンしなければならない。SQL Serverによるエラーの送出は、SQLバッチが終了(terminate)したことを意味しない場合がある。必要な順序(テーブル上のデバッグビルドトリガによって可能な限り実施される)は、次の通りである。
2)セキュリティプリンシパルに関連するパーソナルビューを再ビルドする
3)すべての種類のアイテム変更(すなわち、依存リンク要求、撤回、受け入れ、および拒絶と、複製作成およびクリアと、関連するセットの追加および除去を含む)を行う
4)アイテム変更をオーソライズする
5)フィールド属性変更を行う
6)フィールド使用変更を行う
7)フィールド変更(属性および使用)をオーソライズする
8)ツリー変更を行う
9)ツリー変更をオーソライズする
10)新しいルール定数を追加する
11)ルールセット変更を行う
12)ルール変更を行う
13)<必要に応じて他のメタデータ変更を追加する>
14)ルール変更をオーソライズする
15)アイテム変更を適用する
16)フィールド変更を適用する
17)ツリー変更を適用して、展開されたツリーテーブルを再ビルドする
18)ルール変更を適用する
a.古い展開されたセットテーブルを用いる再ビルドのためにパーソナルビューをマークする
b.展開されたセットテーブルを再ビルドする
c.新しい展開されたセットテーブルを用いる再ビルドのためにパーソナルビューをマークする
d.古いパーソナル読み取りビューを除去して、中間ティアに、使用の時点でこれらを再ビルドさせる
プロダクトルールは、そのオブジェクトを指定しない。同一のプロダクトルールを、多数のオブジェクト、例えば、アイテムまたは管理者データに適用することができ、同一のプロダクトルールは、次からなる。
1)条件。条件は、論理If−Then(別名インプライズ(implies))式である。
2)スコープ
3)使用フラグのセット
1)ストリングへの数値IDのマッピングからとられた単純なストリング
2)定数セット式の結果である定数
3)ルールが評価されている環境に依存する値をとる特別な定数
との間の比較に使用することができる。
1.フィールド値と定数の間のストリング同等性。これは、定数が特別でない限り、演算子フラグをセットしない演算子である。
2.パターンが定数の展開からのストリングである場合のストリングパターンマッチ。値が真と評価されるために、値は、パターンのうちの1つだけに一致しなければならない。パターンマッチは、「In」セット演算子についてのみサポートされる。
3.特別な定数に出会った時には、必ず、特別なケースの処理にエスケープする。
4.fThenConstLargeTextフラグがセットされている時には、ThenConstIDと等しいPropIDを有するTree Propertiesテーブル内の行の大きいテキスト値を使用する。
・ Leafグループ
○ fThenLeaf − 葉定数をとることを指示する
○ fThenInterior − 内側定数(別名、セット名)をとることを指示する
・ Depthグループ
○ fThenOneLevel − 展開される定数の直接の子ノードをとることを指示する
○ fThenTwoPlus − 間接的な子ノードをとることを指示する
展開されたセットに含まれる定数について、グループのそれぞれで少なくとも1つのフラグがセットされなければならない。
・ 定数のセットの直接メンバ(fThenLeaf=1、fThenInterior=1、fThenOneLevel=1、fThenTwoPlus=0)。これをMember演算子と呼ぶ。
・ ネストされたセットの名前を除く定数のセットの直接のおよび間接のメンバ、すなわちルート以外の、セットの展開からの葉ノードまたは外側ノードの、それぞれのストリング(fThenLeaf=1、fThenInterior=0、fThenOneLevel=1、fThenTwoPlus=1)。これをin演算子と呼ぶ。
・ すべてのネストされたセットの名前を含む定数のセットの直接のおよび間接のメンバ、すなわちルート以外の展開からの内側ノードおよび外側ノード(fThenLeaf=1、fThenInterior=1、fThenOneLevel=1、fThenTwoPlus=1)。これを「In With Set Names」演算子と呼ぶ。
○ 「Empty Value」
○ 「Was Empty Value」
○ 「Same As Old Value」
○ 「Name Of Security Principal」
○ 「Old Value Plus 1」
○ 「Value from a different field」
○ 「Server’s date/time stamp」
○ 「Client’s date/time stamp」
○ 「Old value from a different field」
これらの名前の大半は、自己説明的であるが、いくつかは、包括的サポートを保証するのに十分に一般的でないあるカスタマの特別な状況に対処するために任意であり、例えば「Name of Security Principal」は、フィールドが、アクセス権を必要とするドメインアカウント名の値を有する時にアクセス権を許可/拒絶するのに使用される。
□ ドメインアカウント − AD(Eleadコンポーネント)のプロキシを介して公開された、現在有効であることがわかっているすべての電子メールニックネーム
□ ドメインユーザ − ユーザであることがわかっているドメインアカウントのサブセット
□ ドメイングループ − グループまたは配布リストであることがわかっているドメインアカウントのサブセット
鍵になる概念は、「アイテム」である。これは、ほとんどのルールのターゲットである。アイテムは、Areテーブル内の1つの行であり、このAreテーブルは、すべての「単一の値を有する」フィールド、すなわちコア、共通、およびカスタムについて、1つの列を有する。この行は、アイテムの最新バージョンである。Wereテーブルがあり、このWereテーブルは、Areテーブルと同一のレイアウトに加えて「Revised Date」列を有する。あるアイテムが更新される時に、Areテーブルの行の古い内容が、Items Areテーブル行の新しい内容のUTC変更日付と共にWereテーブルに挿入される。AreテーブルおよびWereテーブルを一緒にすることによって、アイテムの「単一の値を有する」フィールドのすべてのバージョンの完全なヒストリができる。ほとんどのクエリは、Items Areテーブルだけを用いる。これらのテーブルのほかに、複数の「拡張」テーブルがある。「単一の値を有する」フィールドでないすべてのItemフィールドの値は、これらのテーブルのうちの1つに送られる。Words、Files、Related Items、およびKeywordsの拡張テーブルがある(1つのフィールドに、一時に複数の値をセットすることができる)。拡張テーブルの各行は、特定のタイムスパンの間「有効」である。このタイムスパンは、拡張がその瞬間に「有効」である場合に、遠い将来に達する場合がある。この形で、各拡張テーブルが、すべてのItemsの最新バージョンおよび置換されたバージョンの両方を有する。ルールは、Itemsの最新バージョンおよび以前のバージョンに関する。
アイテムは、個々のフィールドからなる。各フィールドは、「フレンドリ名」、整数ID、およびフィールドストレージタイプを有する。「ストレージタイプ」のハードコードされたパレットがある。各フィールドは、これらのタイプのうちの1つである必要があるが、多数の別個のフィールドが同一のタイプを有することができる。
Date time。これらは、Areテーブルに埋め込まれる。例は、「Opened Date」または「Closed Date」である。
Integer。これらは、Areテーブルに埋め込まれる。例は、「Beta ID」である。
Double。これらは、Areテーブルに埋め込まれる。例は、「Percentage completed」であり、これは、値25.25をとることができる。
Keyword。これらは、Areテーブルに埋め込まれる。例は、「Status」または「Assigned To」である。これらは、一時に1つの値だけを選択できるラジオボックス機能性に使用される。
Words。これらは、長いテキストである。これらは、ヘルパテーブルに保管される。例は、「Description」または「Repro Steps」である。
Multi−valued keyword。これらは、ヘルパテーブルに保管される。例は、「Processor」または「OS」である。これらは、一時に多数の値を選択できるチェックボックス機能性に使用される。これらは、現在はCurrituckに使用されていない。
Files。これらは、ヘルパテーブルに保管される、例は、「Attachment」または「Linked File」である。
プロダクトツリーは、単一辺を有するグラフである。これは、プロダクトツリーがノードからなることを意味する。各ノードは、その親にもどる1つのリンクを有する。ノードは、整数IDによって識別される。ノードは、ルートノードを除いてそれ自体にリンクされず、ルートノードは、それ自体の親として働く。各ノードは、タイプおよび名前を有する。ノード名は、テーブル内で一意ではないが、兄弟ノードの間では一意に保たれる。すべてのアイテムが、1つのツリーノードに「置かれる」。ツリーノードは、削除済みまたはadmin onlyとしてマークすることができる。削除済みノードは、アイテムを有することができず、その下のすべてのノードが、アイテムを有することができない。ツリーノードがadmin onlyであるか、admin onlyであるノードの下にある場合には、そのツリー位置でアイテムを作成するか変更するために、書き込みアクセス権のほかに管理者アクセス権が必要である。
定数は、絶対にルールの対象ではない。定数は、ルールによって内部的に使用される整数idにストリングを関連付けるだけのために存在する。しかし、定数は、プロダクトデポの将来のバージョンをマルチリンガルにするためのフックを与える。
・ 「Administrators」 − ルートノードおよびその下に対する管理を許可する
・ 「Users」 − ルートノードおよびその下に対する読み取り/書き込みを許可する
・ 「Guests」 − ルートノードおよびその下に対する読み取りを許可する
時々、書き込み(セキュリティと修飾の両方)の通常のオーソライゼーションを「バイパス」することができる必要がある。これをCurrituckで行う形は、まだ未知である。1つの手法は、ユーザを「Write All」グループに追加するか、これから除去することを可能にすることであろう。このグループのメンバは、その書込動作についてセキュリティを実施されない。これは、そのメンバが読み取りセキュリティを実施されない既存の「Read All」を補足するものである。
プロダクトツリーの一部を、そのサブツリーのルートノードのフラグをセットすることによって、「admin only」モードにすることができる。admin onlyモードの時に、このサブツリー内の書込動作は、書き込みアクセス権に加えて、「admin only」サブツリー全体に対する管理者アクセス権を必要とする。
目標は、多くのコンテキストで使用できる、異なるタイプのオブジェクト(アイテム、ケースなど)用のエンジンを作成することであった。BRIEインタフェースは、コールバックベースであり、したがって、実際のデータを得るために、BRIEは、その呼出し側をコールバックする。これによって、BRIE呼出し側が、データをどのように取り出すかに関する柔軟な手法を使用することが可能になり、BRIEがそのフィールドの値を必要とするルールに出会った時にオンデマンドで行うことができ、あるいは、呼出し側が、あるフィールドの値を取り出すことができないかそうしないことを望む場合にルール処理をスキップすることを選択することができる。
・ フィールドプロパティ − どの種類のルールがフィールドについて存在するかを示すフラグのセット。BRIEは、フィールドプロパティを次のカテゴリに副分割する。
○ Forbidden − フィールド値がこのカテゴリのルールのどれかに一致する場合に、アクセスが拒絶される
○ Required − フィールド値がこのカテゴリのどのルールにも一致しない場合に、アクセスが拒絶される
○ Allowed − フィールド値がこのカテゴリのルールと一致する場合に、アクセスが許可される(他のルールによって拒絶される場合がある)
○ Suggested − 提案として働くルールに関するフラグのマスク
○ Not suggested − 否定の提案として働くルールに関するフラグのマスク
・ 値リスト/フォーマット − 上で説明したフィールドプロパティカテゴリに対応する、オプションの定数/フォーマットリスト
AccessCheckアルゴリズムは、次のように動作する。
・ オブジェクト(アイテム、ツリーノードなど)から、プリンシパルがそれへのアクセスを要求したツリー位置を見つける。
・ 対象のタイプidを見つける。
・ admin−onlyフラグを有する場合に、要求されたアクセスに書き込みアクセスが含まれるならば、古い/新しいツリー位置をチェックする。
・ パーソンアクセストークンについて、セキュリティプリンシパルに適用されるすべてのルールを列挙する。
・ ルールごとに、次の条件のいずれかが満足されない場合に、そのルールをスキップする。
○ ルールのアクセス権利のどれもが、要求されたアクセスマスクに含まれない場合。
○ ルールで言及されたフィールドが、チェックされるオブジェクトタイプで使用されていない場合。
○ ルールの階層位置が提要されない場合に、そのルールをスキップする。
○ ルールで使用されているフィールドをオブジェクトから読み取る。ルールで言及されたフィールドのいずれかが欠けている場合には、そのルールをスキップする。
○ ルールを評価する。ルールがアクセスを拒絶し、呼出し側が有効なアクセスマスクを望まないかフィールドプロパティの計算を望まない場合には、即座にリターンする。そうでない場合には、ルールアクセスマスクをグローバル許可アクセスマスクまたはグローバル拒絶アクセスマスクに追加する。
○ いくつかのルール特殊化について、ルールのthen部分であるフィールドを、強制的に要求された値にする(「値を強制的に空にする」、「値を強制的にFROZENにする」、「値を強制的にREADONLYにする」など)。
○ すべてのルールを評価した後に、要求されたアクセスマスクに対してグローバル許可/拒絶マスクをチェックする。
・ フィールドプロパティが要求された場合に、ルール評価アルゴリズムは、ルールに望まれる結果を渡される。所望の結果は、アクセスフラグから演繹される。所望の結果およびルール式フラグ(fUnless、fThenNot)に基づいて、このアルゴリズムは、ルールのターゲットカテゴリ(forbidden、required、allowed、suggested、not suggested)を選択する。
・ ルールを評価する。If部分を計算する。If部分が真である場合には、Then部分を計算する。「If部分」は、2つの式すなわち、「If1」および「If2」の組合せである。欠けているどちらかの部分式は、部分式の成功と解釈される。両方の部分式が真と評価される場合に、「If部分」が真と評価されるという。
結果はIf=>Thenである。次の式アルゴリズムが使用可能である。
○ パターンマッチ
○ セットメンバシップ(Set membership)
○ 同等性
○ 特別な式(CodeDefect特別定数などのハックを置くための拡張可能な場所)。
・ このアルゴリズムは、出会ったルールのタイプに関するフラグをセットする。フラグの例は、次の通りである。
○ 値が空であるかどうかをチェックするルール
○ 値が前と同一であるかどうかをチェックするルール
○ リストメンバシップをチェックするルール
○ パターンマッチをチェックするルール
○ リストメンバシップをチェックし、空のおよび古い値をとるルール
○ パターンマッチをチェックし、古い値をとるルール
○ ドメインユーザをとるルール
○ ドメイングループをとるルール
○ フィールドにデフォルトをセットするルール
○ 値をフィールドにコピーするルール
・ ルールが、望まれない結果に評価される場合には、フィールド状況フラグが、計算されたばかりのルールフラグと論理和をとられる。
・ 要求された場合に、値/フォーマットリストを作成する。
・ アクセストークンのビルド。AccessCheckメソッドは、BRIE呼出し側がアクセストークンを使用してセキュリティプリンシパルを識別することを必要とする。BRIEは、アクセストークンをビルドし、BRIE呼出し側は、アクセスがチェックされる時にそれを渡す責任を負う。アクセストークンを有することの主な理由は、冗長な計算の必要をなくすことである。アクセストークンには、セキュリティプリンシパルが属する定数セットのセットと、セキュリティプリンシパルに適用されるルールのセットが含まれる。
・ クエリビルダ用の提案される値の計算(FieldInfoAllowedValues)。非常に単純なアルゴリズムが、それを行うのに使用される。用いられる、問題とされているフィールドを有するすべてのルールが処理される。fIfNotが0の時に、If部分からのすべての値がとられる。fThenNot^fUnless^DenyWriteが偽の時に、ThenPart部分からのすべての値がとられる。ツリーノードタイプも計算される。特別に処理されるフィールドは、ツリーフィールド、Node Name、Node Type、およびPerson Nameである。
・ デフォルト値:「アイテム」の状態を与えられれば、brieは、そのアイテムのフィールドのデフォルト値を計算することができる。
・ 計算フィールドの無効化。フィールドIdを与えられれば、BRIEは、計算フィールドのどれが変化のゆえに影響を受けるかを知らせることができる。
・ 計算フィールドの計算。BRIEは、次の計算フィールドの値を計算することができる。
○ ツリータイプフィールド
○ Node Name
○ Node Type
○ Tree Path
○ Person Name
また、BRIEは、いくつかの読み取り専用フィールド(依存性関連フィールド、Regressions)を計算することができない。これらの計算フィールドは、アイテムが保存された後に、中間ティアによって返される。
最大の問題は、暗黙のセットメンバシップを識別し、どのノードがプロダクトツリー内の他のどのノードの下にあるかを識別するハウスキーピングにある。これは、ドメイングループおよび配布リストに関するメンバシップ情報を同期化するコストと、アクティブディレクトリに対するすべてのドメインアカウントの継続する存在によって倍加される。より小さい懸念が、個々のドメインユーザについてSQLビューを生成するコストと、それが古くなった(それがもはやルールおよびセットメンバシップを反映しないので)時の識別である。多数のビューを担持することに対するコストはほとんどないが、これらのビューを使用して、データベース変更をロールバックしなければならない時を検出すること、または読み取りに関してパーソナルビューを介してユーザselectをフィルタリングすることに関するコストがある。
1.Assigned to例外を実装するルール(なくなる可能性がある)
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))
Adminテーブルのタイムスタンプ列(Rulesなど)は、楽観的ロックを行うのに使用される。ロックを保持するのではなく、我々は、動作のセットの始めにDBのタイムスタンプを保管する。
ルールを操作し使用するためのストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: AuthorizeItemChanges
//
// 特定の日付に変更されたアイテムが、アイテム内容ルールに違反していないことを
// チェックする。いずれかのアイテムがいずれかのルールを破壊している場合には、
// トランザクションをロールバックする。このプロシージャは、シリアライズ可能な
// トランザクション内で実行されると期待され、したがって、結果は、同一のUTC // クロック時刻にアイテムを追加または変更する他のトランザクションによって影響 // されなくなる。
//--------------------------------------------------------------------------*/
// 名前: AuthorizeRuleChanges
//
// 特定の瞬間のセキュリティプリンシパルによるすべてのルール変更がどのルールに
// も違反していないことをチェックする。ルールによって参照される定数セットのメ
// ンバの変更は、ルールに対する変更としてカウントされる。Setsテーブルのト // リガは、RuleSet変更によって影響を受けるルールのChangerIDお // よびChangedDateを変更することによって、これを実装する。定数ID // のストリングは、更新または削除することができず、したがって、ルールに対する // 類似する変更を引き起こさない。
/---------------------------------------------------------------------------*/
// 名前: AuthorizeTreeChanges
//
// 特定の瞬間のセキュリティプリンシパルによるすべてのルール変更がどのルールに
// も違反していないことをチェックする。ルールによって参照される定数セットのメ
// ンバの変更は、ルールに対する変更としてカウントされる。Setsテーブルのト // リガは、RuleSet変更によって影響を受けるルールのChangerIDお // よびChangedDateを変更することによって、これを実装する。定数ID // のストリングは、更新または削除することができず、したがって、ルールに対する // 類似する変更を引き起こさない。
/---------------------------------------------------------------------------*/
// 名前: AuthorizeFieldChanges
//
// 特定の瞬間のセキュリティプリンシパルによるすべてのルール変更がどのルールに
// も違反していないことをチェックする。これは、プロダクトフォームに対する変更
// もチェックする。
//--------------------------------------------------------------------------*/
ルールを操作するストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: AddConstant
//
// 定数をデポに導入するのに使用されるストアドプロシージャ。定数がドメイン
// アカウントである場合には、アクティブディレクトリと同期化される、すなわちそ
// のセットメンバシップが、アクティブディレクトリからとられる。
//--------------------------------------------------------------------------*/
// 名前: ChangeRuleSet
//
// 既存の定数をセット/リストに追加する。
//
// セキュリティ違反または他の保全性違反の際に、トランザクションがロールバック
// される。トランザクションがロールバックされる場合には、SQLエラー266が
// 送出される。
//--------------------------------------------------------------------------*/
// 名前: LookupRule
//
// 条件の特定のセットを有するルールを追加する/見つける。ルールの個数は、最小
// 限に保たれ、したがって、新しいルールは、必要な条件を有する既存ルールがない
// 場合に限って追加される。
//--------------------------------------------------------------------------*/
/*---------------------------------------------------------------------------
// 名前: ChangeRule
//
// 既存ルールのフラグを変更する。冗長なデータベース更新は行わない。
// 入力引数値としてヌルを使用することによって、すべてのアクセス権フラグを未変
// 更のままにすることができる。
// ルールは、削除されず、すべてのフラグが0の場合には関連しない。
// セキュリティ違反または他の保全性保全性違反の際に、トランザクションがロール // バックされる。
// トランザクションがロールバックされる場合には、SQLエラー266が送出され // る。
//--------------------------------------------------------------------------*/
// 名前: ApplyRuleChanges
//
// 変更がオーソライズされた後、およびツリー変更が適用された後だが、ルール変更
// が適用される前に呼び出す。これによって、セキュリティプリンシパルによって所
// 与の時に行われたSetsに対する変更に従って、ExplodedSets(遷 // 移的セットメンバシップ)に行が追加され、除去される。
//--------------------------------------------------------------------------*/
プロダクトツリーを操作するストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: ChangeTree
// 既存ノードを変更するか、新規ノードをプロダクトツリーに追加する。冗長なデー
// タベース更新または挿入は行わない。入力引数値としてヌルを使用することによっ
// て、すべての列を未変更のままにすることができる。
// 新規ノードは、ヌルのTreeIDが入力として渡された場合に追加される。
// セキュリティ違反または他の保全性保全性違反の際に、トランザクションがロール // バックされる。
// トランザクションがロールバックされる場合には、SQLエラー266が送出され // る。
//--------------------------------------------------------------------------*/
// 名前: ApplyTreeChanges
//
// プロダクトツリーに対する変更に基づいて、ツリーパステーブルに対する増分変更
// を行う。プロダクトツリーに対する変更の共通のケースは、サブツリー全体を伴う
// 些細な変更のためである。
//--------------------------------------------------------------------------*/
プロダクトフィールドを操作するストアドプロシージャ
/*---------------------------------------------------------------------------
// 名前: ChangeField
//
// 既存フィールドを変更するか新規カスタムフィールドを追加する。
// セキュリティ違反または他の保全性保全性違反の際に、トランザクションがロール // バックされる。
// トランザクションがロールバックされる場合には、SQLエラー266が送出され // る。
//--------------------------------------------------------------------------*/
// 名前: ApplyFieldChanges
//
// 「短く狭い」フィールドが使用されるようになる時に、AreテーブルおよびWe
// reテーブルを変更する。これらは、Product Studio UIの結果
// ペインに表示できるフィールドである。すべての未使用のデータベース列をフィル
// タアウトするこれらのテーブルに対するビューが、必要な場合に再ビルドされる。
// これらのビューは、保護されたアイテムの読み取りに使用されるパーソナルビュー
// の基礎である。
//--------------------------------------------------------------------------*/
次のサンプルルールでは、ビジネスシナリオと、プロダクトルールがそれにどのように対処するかを説明する。「Decoded Rules」ビューに現れるルールおよびそれが依存する定数のセットのすべてのストリングが、リストされる。(形式張った)英語の解釈と共にすべてのルールを見るには、
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'
を行う。
注:IDとして使用される数は、固定されていない。異なるデポが、まったく異なるストリング、フィールド、またはツリーノードに同一の数を使用することができる。
(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
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
ワークアイテムタイプ定義言語
(要約)
この文書は、ワークアイテムタイプ定義(WITD)言語を定義する。
この文書は、ワークアイテムタイプ定義言語を定義する。この文書は、この言語をどのように使用するかは定義しない。使用法については、ワークアイテムタイプルールおよびカスタマシナリオ仕様書を参照されたい。
ワークアイテムタイプ
・ ワークアイテムタイプに関する詳細
ワークアイテムタイプルールおよびカスタマシナリオ
・ ワークアイテムタイプ定義言語を使用するためのカスタマ中心のシナリオ
ポートフォリオプロジェクト管理
・ ワークアイテムタイプの管理に関する詳細
Whidbey Bug
・ インハウス使用に関するワークアイテムタイプ定義(ドッグフーディング)
要約
範囲
関連文書
目次
シナリオ
ワークアイテムタイプの概要
高水準WITD構造
フィールド
<FIELD>定義
フィールド名
フィールド参照名
フィールドタイプ
フィールドレポーティング
フィールドヘルプテキスト
フィールドルール
フィールド制約
フィールドリスト
フィールドリストアイテム
グローバルリスト
フィールドリストタイプ
リストアイテム展開
例
組合せでのリストタイプの使用
正しい値の判定
ピックリスト値判定
複数リストの指定
フィールドデフォルト
フィールド条件
<WHEN*>ルール、<DEFAULT>ルール、および<COPY>ルールの期待される挙動
条件フィールドルール属性
ユーザおよびグループの参照
ワークフロー
概要
遷移セキュリティ
状態、遷移、または理由によるフィールドルールのスコープ指定
状態遷移アクション(状態遷移の自動化)
適切な状態遷移の識別
遷移の自動化
遷移アクションの詳細
自動遷移エラーチェックおよびWIT作成者の考慮
ルール評価順序
特別なルール制約
ナンセンスなルール
問題のあるルール
フォーム
<Layout>、<Group>、および<Column>
コントロール
すべての要素
サンプル
WITDローカライゼーションおよびグローバライゼーション
V1カットリスト
フィールドタイプ
フィールドルール
フィールドインデクシング
indexed
WITD言語は、次のシナリオをサポートすることが期待される。
カスタマが、新しいチームプロジェクト(TP)を作成することを望む。カスタマは、チームプロジェクト作成ウィザードを介してこれを行う。TP作成の一部として、カスタマは、「方法論(methodology)」(例えば、MSF Agile)を選択する。各「方法論」は、ワークアイテムタイプのセットを識別する。終了した時に、TPに、その方法論によって定義されたデータベース内のワークアイテムタイプのセットが含まれ、ユーザは、これらのタイプの新しいワークアイテムインスタンスを作成することができる。
パートナが、カスタマがVisual Studio Team Systemツールを用いてSEI−CMMプロセスでより高いレベルを達成するのを助けることを望む。あるいは、システムインテグレータが、彼らが奨励する開発方法論をVisual Studio Team Systemツールを用いて自動化できると判断する。パートナは、WITD言語でワークアイテムタイプのセットを設計する。パートナ/システムインテグレータは、これらのWITD XMLファイルをウェブを介して、CDで、その他の方法でカスタマに配布する。
AdventureWorks社の部署Aは、しばらくVisual Studio Team Systemを使用してきた。彼らは、カスタマイズされたワークアイテムタイプを使用している複数のチームプロジェクトを有する。彼らは、彼らがプロジェクトに関する問題を追跡するのに使用する新しいワークアイテムタイプも作成済みである。別の部署、部署Bで、新しいTeam Foundation Serverがセットアップされた。部署Bは、良いことが部署Aで起きていることを聞き、やはりIssueワークアイテムタイプを使用すると判断した。部署Aのチームプロジェクト管理者が、XMLファイルとしてIssueをエクスポートする。部署BのTP管理者は、自分のチームプロジェクトにIssueワークアイテムタイプをインポートする。
次が、WITD言語の主要な設計目標である。
・ 将来の機能性に対処するために拡張可能
・ 単純 − 基本言語は、理解と作成が単純でなければならない
・ 人間可読 − ユーザは、単純なWITDをタイプし、特定の設計ツールに頼らずにそれらを働かせることができなければならない。
名前:これは、チームプロジェクト内で一意でなければならない。例に、bug、feature、requirement、taskが含まれる。
記述:これは、ランタイムにプロジェクト内のワークアイテムタイプの概要が必要な時に使用できるヘルプテキストである。
フィールドのリスト:これは、ワークアイテムタイプのフィールドの関連するセットを定義する。フィールド定義は、Team Foundation Serverにグローバルである。すべてのワークアイテムタイプに、Team Foundationワークアイテムトラッキングに必要なコアフィールドのセットが含まれる。
ワークフロー:これは、有効な状態および正しい遷移のセットと、誰がこれらの遷移を実行することを許可されるかを定義する。
フィールドルールのセット:これは、ワークアイテムがその状態遷移図を通って移動する時のフィールドおよびフィールド値に対する制約を定義する。
フォーム:これは、関連するフィールドがエンドユーザによってどのように表示され、操作されるかを定義する。
オプションとして、グローバルリストのセット:複数のフィールドに再利用できる値の名前付きリスト(例えば、found on OSフィールド、fixed on OSフィールド、supported on OSフィールドに使用されるオペレーティングシステム)。
下は、ワークアイテムタイプ定義(WITD)の高水準構造である。
ワークアイテムタイプ定義は、タグ<WITD>によって囲まれる。後のリリースで、XMLスキーマが変更される可能性がある。アップデートは、後方互換である。
ワークアイテムタイプ名は、所与のチームプロジェクト内で一意でなければならない。この名前は、ランタイムに使用される。例えば、ユーザが、bug、task、risk、またはissueを選択する。
記述は、ランタイムにプロジェクトのワークアイテムタイプの概要が必要な時に使用できるヘルプテキストである。例えば、aが、リスクと問題の間の相違を理解することを望む。
所与のワークアイテムタイプに関連する関連フィールドは、XMLの<FIELDS>セクションで定義される。定義(<FORM>内および<WORKFLOW>内など)セクションの他の場所で参照されるすべてのフィールドは、コアフィールドを除いて、まず<FIELDS>セクションで宣言されなければならない。
フィールドは、名前、参照名、およびタイプによって定義される。フィールドは、様々なレポートする挙動(reporting behavior)を用いてセットすることもできる。
フィールド名は、Team Foundation Serverのフィールドに関する一意のユーザ可視のハンドルである。これは、所与のTFS内のすべてのチームプロジェクトおよびワークアイテムタイプにまたがる一貫性を奨励するためのものである。フィールド名は、クエリを作成するかワークアイテムタイプエディタ内で作業する時に使用される。ワークフロー内またはWITDのフォームセクションで参照されるすべてのフィールドが、<FIELDS>セクション内でそのフィールドを定義する<FIELD>要素を有しなければならない。
・ 小文字{Ll}
・ 大文字{Lu}
・ 題字{Lt}
・ 他の文字{Lo}
・ 数字{Nd}
・ スペース{Zs}
句読点コネクタの単一の出現{Pc}
句読点ダッシュの単一の出現{Pd}
モディファイヤ(modifier)文字{Lm}
ユニコードサロゲート(surrogate){Cs}
フィールド名は、前後のスペースをトリミングされる。
WITD言語およびWIQL(ワークアイテムクエリ言語)の重要な目的は、これらの定義をTFSの間でポータブルにすることである。サードパーティインテグレーションがあるフィールドを見つけられ、参照できることも重要である。フィールド名は変更される可能性があるので、これらはこの目的には良くない。
System.Id
System.Title
System.CreatedBy
System.CreationDate
System.ChangedBy
System.ChangedDate
System.State
System.Reason
Microsoft.Common.Status
Microsoft.Common.Priority
Microsoft.Scheduling.Duration
Microsoft.Scheduling.PercentComplete
Microsoft.Testing.TestCaseName
Accenture.Common.Severity
Accenture.Common.Phase
Accenture.RiskManagement.RiskType
Accenture.RiskManagement.Resolution
EDS.Common.BusinessPriority
EDS.Bug.FoundInPhase
EDS.Bug.FixInPhase
・ 英語小文字a〜z
・ 英語大文字A〜Z
・ 数字0〜9
・ ピリオド「.」
・ ハイフンの単一の出現「−」
・ アンダースコアの単一の出現「_」
フィールド参照名は、前後のピリオド「.」をトリミングされる。フィールド参照名には、少なくとも1つの「.」が含まれなければならない。
フィールドのタイプは、ユーザがそのフィールドに保管することを期待するデータの種類およびサイズを定義する。フィールドは、TFSごとに1つのタイプだけを有することができる。これは、組織がプロジェクトおよびワークアイテムタイプに渡って共通のフィールドを使用することを奨励するためである。
・ String
ワンライナ(one−liner)および短いストリングフィールドに使用される。クエリフィルタおよび結果リストで自由に使用される。255ユニコード文字まで。
・ Integer
整数値に使用される。クエリフィルタおよび結果リストで自由に使用される。32ビット符号付き整数。
・ Double
浮動小数点値に使用される。クエリフィルタおよび結果リストで自由に使用される。
・ DateTime
保管された時間の特定の瞬間をUTCで表し、ローカル時間帯に合わせて調整される必要がある。
・ PlainText
記述などに使用される長いテキストフィールド。
・ HTML
記述などに使用される長いテキストフィールド。これは、HTMLに強く型付けされている点がPlainTextフィールドと異なる。このフィールドは、情報のより豊かな表示を可能にする。
・ TreePath
CSS領域またはイテレーションパスを保管するのに使用されるストリングフィールド。このフィールドタイプは、コアフィールドSystem.AreaPathまたはSystem.IterationPathだけについてサポートされる。
・ History
会話スレッドおよびリビジョンヒストリを表示するのに使用される長いテキストフィールド。このフィールドタイプは、コアフィールドSystem.Historyだけについてサポートされる。
一部のフィールド値は、レポート目的に特に有用である。WITDは、ユーザがこれらのフィールドの特別な属性を指定することを可能にする。この属性は、オプションである。属性が指定されていない場合に、そのフィールドデータは、データウェアハウスにエクスポートされない。
integerフィールド、stringフィールド、またはdatetimeフィールドだけに使用される。データは、ウェアハウスおよびキューブに送られ、したがって、レポートのフィルタリングに使用することができる。formula属性を指定する必要はないが、指定された場合に、formula属性は値「none」だけをとることができる。
integerフィールド、doubleフィールド、stringフィールド、またはdatetimeフィールドだけに使用される。データは、ウェアハウスには送られるが、キューブには送られない。formula属性を指定してはならない。
integerフィールドおよびdoubleフィールドだけに使用される。集約(aggregation)は、formula属性によって定義される。formula属性が指定されていない場合のデフォルト集約は、sumである。
sum
count
distinctcount
avg
min
max
フィールドは、ユーザがフィールドに入力しなければならないものに関してユーザを案内するのにランタイムに使用されるヘルプテキストも有する。フィールドヘルプテキストは、オプションである。フィールド名およびタイプと異なって、フィールドヘルプテキストは、TP内の所与のワークアイテムタイプにスコープを指定される。これによって、各TPが、任意の所与のワークアイテムタイプに対する任意の所与のフィールドの使用に関する、それ自体のガイドラインを定義することが可能になる。
フィールドルールは、フィールドの挙動および制約を定義し、<FIELD></FIELD>ブロックの中にリストされる追加要素である。
・ 制約
・ リスト
・ デフォルト
・ 条件
フィールド制約は、フィールド値の要件を定義する。
このフィールドは、空でないことが要求される。すべてのフィールドタイプを、REQUIREDとしてマークすることができる。
このフィールドを変更することはできない。
このフィールド値は、コミット時にクリアされ、ユーザは、値を入力することを許可されない。主に状態遷移中に使用される。
フィールドがコミットの後に値を得たならば、もはや変更することはできない。しかし、<EMPTY/>制約を使用してクリアし、その後にもう一度書き込むことはできる。主に状態遷移中に使用される。
フィールドが値を得たならば、クリアすることも空にすることもできない。
このフィールド値は、フィールド「Foo」の値と同一の値を有することができない。例えば、2つのフィールドを同時に空にすることができず、あるいは、「code reviewer」フィールド値を「assigned to」フィールド値と同一にすることができない。これは、類似するタイプのフィールドに使用されなければならない。これは、PlainTextフィールドまたはHTMLフィールドについてはサポートされない。
このフィールド値は、TFS Everyoneのメンバである有効なメンバでなければならない。
日付フィールドを検証する。mustbe値は、「after now」または「not after now」のいずれかにすることができる。「after now」は、現在時刻の後である。「not after now」は、フィールド値が現在時刻またはそれ以前であることを要求する。DateTimeフィールドタイプに使用される。
フィールドが既に値を有するが、許容される値のリスト(下を参照されたい)で表された値でない場合に、そのままであることを可能にする。代替のデフォルト挙動は、編集時にユーザがそのフィールドに対する最新の許容される値に従うことを強制することである。この要素は、「for」属性または「not」属性を受け入れることができない。
ルールがフィールド定義にスコープを指定されている場合には、いつでもそのフィールドに適用される。したがって、既存の値がコミットされたならば、ワークアイテムがどの状態であり、どの条件ルールを適用できるかに無関係に、将来のリビジョンでその値が許容される。
このルールが、フィールド条件の下でスコープを指定されている場合、親フィールド条件が満たされるときに、既存の値をコミットすることだけが許容される。
ルールが状態の下でスコープを指定されている場合、ワークアイテムが親状態であるときまたはワークアイテムがその状態に遷移するときに、既存の値が許容される。これは、それらの遷移にスコープを指定されているすべての理由に適用される。
ルールが遷移の下でスコープを指定されている場合、ワークアイテムが親遷移を行うときに、既存の値が許容される。これは、遷移にスコープを指定されているすべての理由に適用される。
ルールが理由の下でスコープを指定されている場合、ワークアイテムが指定された理由で親遷移を行うときに、既存の値が許容される。
ストリングだけについて基本パターンマッチングを実施する。<pattern>は、マッチパターンに置換されなければならない。有効な値は、「A」、「N」、「X」であり、他のすべての値は、リテラルと解釈される。「A」は、アルファベット文字を表す。「N」は、数字文字を表す。「X」は、アルファベットまたは数字のいずれかを表す。これは、ストリングタイプフィールドだけについてサポートされる。
リリース番号
ANN.NN.NN 妥当 R01.03.04またはV05.08.99
非妥当 1.3.4またはV5.8.99またはv1.3
ある柔軟なid
XXX−XXX 妥当 001−abcまたはa00−b02
非妥当 1−abcまたは001.abc
優先順位
PN 妥当 P1またはP5またはP9
非妥当 1またはP10
マッチタグは、大文字小文字の区別がないので、「PN」はP1およびp1にマッチする。マッチタグは、空白値をサポートする。
フィールドリストは、フィールドのピックリストを管理するのに使用される。ピックリストには、許容される値、提案される値、および禁止される値という3タイプがある。フィールドリストは、Stringフィールドタイプ、Integerフィールドタイプ、およびDoubleフィールドタイプに使用することができる。
フィールドリストは、個々のアイテムから構成される。リストには、少なくとも1つのアイテムが含まれなければならない。<LISTITEM value=””>要素は、リスト内のアイテムを指定するのに使用される。指定される値は、単なるストリングとすることができ、あるいは、ユーザまたはグループを指定することができる。この値は、空にすることができない。
ワークアイテムタイプを定義するときに、いくつかのフィールドが同一のセットの値を共有していることに気がつく。しばしば、この共有は、複数のワークアイテムタイプに渡り、複数のチームプロジェクトに渡る場合もある。これらのリストの一部が、頻繁に変更される場合がある(例えば、ナイトリビルドのビルド番号)。
・ リストを作成する
・ リスト値を追加する
・ リスト値を除去する
・ TFS内のグローバルリストのリストを得る
・ リストの内容を得る
グローバルリストは、あるサードパーティシステムからリストを導出しなければならない場合にも使用される。例えば、ある会社が、別々のカスタマデータベースを維持していると仮定する。カスタマによって発見されたバグが入力された時に、彼らは、カスタマの名前を有する必要がある「Found By Customer」フィールドを有する。このバージョンについて、カスタマ名リストを入手するためにランタイムにカスタマデータベースのダイナミッククエリを可能にするプログラマチックアクセスが、サポートされていない。ダイナミック機能の近似は、OMに対するコードを記述して、カスタマリストがカスタマデータベース内で変更された時に必ずグローバルリストを更新することである。
<ALLOWEDVALUES>
ドロップダウンとして提示される値の列挙されたリスト。ユーザは、これらの値のうちの1つを選択しなければならない。
ドロップダウンとして提示される値の列挙されたリスト。ユーザは、これらの値のうちのどの1つでも選択することができる。ユーザは、提案の1つでない彼ら自身の値を入力することもできる。
ユーザは、フィールドに禁止される値が含まれる場合に、ワークアイテムを保存することができない。禁止される値は、通常、値が前に許容されたがもはや有効でない時に使用される。
リストタイプ要素<ALLOWEDVALUES>、<SUGGESTEDVALUES>、<PROHIBITEDVALUES>は、2つのオプション属性expanditemsおよびfilteritemsを有する。
expanditemsにtrueがセットされている時に、グループまたはグローバルリストを表すリストアイテムは、再帰的に展開される。すなわち、グループはそのサブグループを展開され、サブグループのサブグループが展開される。展開の後に、グループを表していたリストアイテムに、リストアイテム値としてグループとユーザの両方が含まれる。expanditemsにfalseがセットされている場合には、グループまたはグローバルリストの展開は実行されない。
この属性/値の対が現れた時に、すべてのリストアイテムが評価され、すべてのグループが除去される。これは、グループなしのユーザのリストだけが欲しい時に使用される。
[Project]\Business Analystsは、ビジネスアナリストユーザ、jsmith、bbob、およびdmillerのチームプロジェクトグループである。
Redmond\MyTeamは、3つのサブグループ、Development、Test、およびPMを有するグループである。各サブグループは、それぞれ、1つのユーザ「devuser」、「testuser」、および「pmuser」を有する。Redmond\MyTeamは、1つのユーザ「juser」も有する。
Redmond\MyReportsは、ユーザ「userone」、「usertwo」、および「userthree」と、「userfour」および「userfive」を有する1つのサブグループMyRemotesとを有するグループである。
BoolValuesは、2つのエントリ「true」および「false」を有するグローバルリストである。
展開がオンでグループをフィルタアウトされた状態における、ストリング値、グローバルリスト、およびグループ。
string、true、false、jsmith、bbob、dmiller
グループフィルタリングは実行されない。
string、true、false、juser、juser2、devuser、testuser、pmuser、Development、Test、PM
リストアイテム展開は実行されない。
string、MyTeam、MyReports
注:グローバルリスト名および内容は、表示されない。
グループを除外し、展開なし。
string
注:MyTeamは、除外され、展開されないグループであり、BoolValuesは、グローバルリストであり、したがって、展開も表示もされない。
単一のフィールドについて複数のタイプのリストを指定することが可能である。このセクションでは、アイテムの結果のリストを判定する方法を定義する。
あるフィールドについて許容される正しい値は、{セットA}から{セットP}を引くことによって得られる。{セットA}がエントリを有しない場合には、{セットA}は、すべての可能な値と考えられる(すなわち、許容される値が定義されておらず、したがって、{セットP}で具体的に識別される値以外のすべてが許容される)。{セットS}は、フィールドの正しい値の判定では役割を演じない。
{セットS}AND{セットA}がエントリを有しない場合
結果:空のリスト
{セットS}がエントリを有し、{セットA}がエントリを有しない場合
結果:{セットS}から{セットP}を引くことによって得られる値
{セットS}AND{セットA}がエントリを有する場合
結果:
a.{セットA}と{セットS}の交わりをとって{中間セットI}を得、
b.{中間セットI}から{セットP}を引く
ことによって得られる値のリスト
{セットS}がエントリを有しないが、{セットA}がエントリを有する場合
結果:{セットA}から{セットP}を引くことによって得られる値のリスト
複数リストの指定
所与の時点に複数の<ALLOWEDVALUE>(例えば、WIT <ALLOWEDVALUE>セットと状態固有)を指定した場合に、これらの複数のセットの交わりが、最終的な{セットA}として採用される。
フィールドデフォルトは、フィールド値を自動的に書き込む方法を扱うルールである。3タイプの要素、<DEFAULT>、<COPY>、および<SERVERDEFAULT>がある。
<DEFAULT>
ユーザが新しいワークアイテムを作成するかワークアイテムを編集する時に、<DEFAULT>要素は、フィールドが空の場合にフィールド値を書き込む。フィールドが既に値を有する場合には、デフォルトルールは無視される。
<COPY>
ユーザが新しいワークアイテムを作成するかワークアイテムを編集する時に、<COPY>
<SERVERDEFAULT>
編集の始めに値を書き込む<DEFAULT>および<COPY>と異なって、<SERVERDEFAULT>ルールは、ワークアイテムがデータベースにコミットされる時に値を書き込む。これは、保存時にバックグラウンドで行われ、ユーザはその値をオーバーライドすることができない。フィールドは、フォーム上で読み取り専用のように見える。このルールは、セキュア監査証跡(audit trail)をサポートするために、「Last Changed By」および「Last Changed On」などのフィールドに使用される。
・ value
指定されたストリング定数からの値をとる。value=”xxx”属性を必要とする。<COPY>ルールおよび<DEFAULT>ルールだけに使用される。
・ field
指定されたフィールドからの値をとる。コピーされる値は、最後に成功裡にコミットされたリビジョンからのターゲットフィールドの値である。field=”xxx”属性を必要とする。デフォルトで、指定されたfromフィールドが空の場合に、何も行わない。<COPY>ルールおよび<DEFAULT>ルールだけに使用される。
・ clock
値として現在の日時を使用する。追加属性は不要である。DateTimeフィールドに使用される。<COPY>ルールおよび<DEFAULT>ルールについて、この値は、ローカルマシンクロック時刻から取られる。<SERVERDEFAULT>について、この値は、コミット時のサーバクロックから与えられる。
・ currentuser
値として現在のユーザの短いユーザ名を使用する。追加属性は不要である。ストリングフィールドに使用される。
依存ピックリストに使用され、詳細なセキュリティ挙動またはカスタマ挙動を提供するのに使用される追加の句がある。
<WHEN field=”xxx”value=”yyy”>
この要素内のすべてが、フィールドxxxが値yyyを有する間に適用可能である。
この要素内のすべてが、フィールドxxxが値を有するがその値がyyyでない間に適用可能である。
この要素内のすべてが、フィールドxxxがユーザによって変更済みである時に適用可能である。
このセクションでは、<DEFAULT>ルール、<COPY>ルール、および<WHEN*>ルールを使用する時に期待される挙動および相互作用の概要を示す。
1)ユーザが、新しいワークアイテムを作成するか既存ワークアイテムを編集することをジェスチャで表す。
2)フィールドデフォルトを書き込む。すべてのフィールドについて、<WHEN*>ルールの外にあるすべての<DEFAULT>ルールを使用する。
3)フィールド値をコピーする。すべてのフィールドについて、<WHEN*>ルールの外にあるすべての<COPY>ルールを使用する。
4)最初にマッチする<WHEN>ルールを有するすべてのフィールドについて、まず内側の<DEFAULT>ルール、次に内側の<COPY>ルールを行う。
5)最初にマッチする<WHENNOT>ルールを有するすべてのフィールドについて、まず内側の<DEFAULT>ルール、次に内側の<COPY>ルールを行う。
必ず、<WHENNOT>ルールの前に<WHEN>ルールを処理する。
6)#1以降に値を変更され、<WHENCHANGED>ルールを有するすべてのフィールドについて、まず内側の<DEFAULT>ルール、次に内側の<COPY>ルールを行う。
7)ユーザに編集を開始させる。
8)ユーザが、フィールド値を変更し、そのフィールドのほかの部分に移動する。
9)新しい値にマッチする、そのフィールドのすべての<WHEN>ルールを発火させる。
10)新しい値にマッチする、そのフィールドのすべての<WHENNOT>ルールを発火させる。
11)新しい値にマッチする、そのフィールドのすべての<WHENCHANGED>ルールを発火させる。
12)編集能力をユーザに返す。
13)ユーザが、データベースに変更を保存することをジェスチャで表す。
14)すべてのフィールドについて、<WHEN>ルールまたは<WHENNOT>ルールの下で直接にまたは間接にのいずれかでそのフィールドについて定義された<SERVERDEFAULT>動作を実行する。
時々、フィールドルールのスコープを、特定のグループまたはユーザに制限したくなる。属性「for」および「not」を追加して、これをサポートすることができる。これらは、タグを単一のBISグループに固有または単一のBISグループに含まれない全員に固有にするために、複数のタグで使用される。拒絶は、許可に優先する。
注:このバージョンでは、フィールドルールのスコープを特定のユーザに制限することはサポートされない。
フィールドリストアイテム、条件フィールドルール属性、および遷移セキュリティなどの複数のルールが、ユーザおよびグループを参照する。WITD言語は、ユーザおよびグループを参照する次のトークンをサポートする。
このトークンは、サーバスコープ付きのTFSグループを参照するのに使用される。
このトークンは、チームプロジェクトスコープ付きのTFSグループを参照するのに使用される。
ドメイン修飾子は、ドメインユーザまたはグループを参照するのに使用される。いくつかのルールが、グループだけをサポートし、ドメインユーザの参照をサポートしないことに留意されたい。
概要
WITDのワークフローセクションでは、有効な状態、正しい遷移、および遷移の正しい理由を記述する。理由は、なぜユーザがある状態から別の状態に変更しようとしているかを識別する。
2つの状態の間のすべての正しい遷移を指定しなければならない。遷移が指定されていない場合に、デフォルトは、その遷移の実行を許可しないことである。
これまでに我々が定義したフィールドルールは、フィールド名、そのタイプ、ヘルプテキスト、およびワークアイテムタイプ全体の挙動を識別する。すなわち、bugの状態に無関係なフィールドの挙動である。例えば、1つのフィールドが、何であっても必ず必要である。
"MyField Value" != NULL
状態固有ルールのスコープは、ワークアイテムインスタンスがある状態であるときに、そのワークアイテムインスタンスに制限される。したがって、チェックは次のようになる。
State field value == "MyState" && "MyField Value" != NULL
遷移固有ルールのスコープは、ある遷移を受けつつあるワークアイテムに制限される。このルールに関するチェックは、より複雑である。
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL
理由固有ルールのスコープは、特定の遷移に対する特定の理由に制限される。これに関するチェックは、最も複雑である。
Reason field = "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL
スコープ付きフィールドルールは、<STATE>要素、<TRANSITION>要素、および<REASON>要素の中で<FIELDS>要素および<FIELD>要素を使用することによって行われる。
注:ワークフロー内のフィールドをリストするときには、フィールド参照名だけを指定しなければならない。
カスタマおよびパートナは、チームシステム内のどこかで発生したイベントまたはチームシステム自体の外(例えば、コールトラッキングツール(call tracking tool))で発生したイベントに基づいて、ワークアイテムを状態から状態に自動的に遷移させることを望む場合がある。他のシステム(我々自身のシステムを含む)によるワークアイテムの自動遷移をサポートするために、我々は、ワークアイテムタイプモデルおよびOMを拡張しつつある。例によってこれらの拡張に目を向けよう。
例えば、Team Foundationバージョンコントロールシステムは、チェックイン時のワークアイテムの自動遷移をサポートする必要がある。「microsoft.vsts.actions.checkIn」アクションが定義されている。WIT作成者が、開発者が変更を行っている時のための「Working」という状態と、欠陥が開発者によってナイトリビルドの準備ができたと宣言された時を識別する「Ready To Build」というもう1つの状態とを有する「Defect」ワークアイテムを定義すると仮定する。作成者は、次を宣言することによって、チェックイン動作中にワークアイテムを状態「Working」から「Ready To Build」に自動的に遷移させることができる。
インテグレータにとって、アクションの定義は第1のステップにすぎない。ツールは、そのアクションを実行している時に、遷移を行わなければならない。例えば、Team Foundationバージョンコントロールシステムが、チェックイン動作を実行しており、自動遷移を実行することを望むと仮定する。バージョンコントロールシステムは、OM呼出しを介してワークアイテムトラッキングシステムに問い合わせて、関連するワークアイテムを遷移させるべき正しい「To」状態を見つける。
nextState =
workiteminstance.GetNextState("microsoft.vsts.actions.checkin");
ワークアイテムインスタンスの現在の状態が、指定されたアクションのアクションエントリを有する場合に、そのインスタンスは「To」状態を返す。そうでない場合には、戻り値はNullである。
アクションは、オプションである。インテグレーションは、Null戻り値を優雅に処理しなければならない。すなわち、a)エラーにせず、b)アクション「xyz」を探していたが見つからなかったので自動遷移しなかったことのトレース/ログを残し、このアクションを追加させるためにWIT作成者に連絡する。
インテグレータが試みる可能性がある2タイプの自動遷移がある。第1は、あるユーザジェスチャに起因して発生する自動遷移であり、第2は、不在自動化(例えば、ナイトリビルド)として発生する自動遷移である。第1の場合に、ユーザが、起こる可能性があるすべてのルール関連問題を扱い、インテグレーションの知らない新しく必要なフィールドをWIT作成者が追加できるという事実をサポートしなければならないと仮定することができる。これを行うために、自動遷移を行った後に、ルール違反についてWITをチェックする必要があり、ルール違反が見つかった場合には、ユーザが解決するためのフォームを表示する必要がある。
一般に、ルールは、ルールのスコープを反映した順序で実行される。例えば、あるルールのスコープが、特に現在の状態に制限されている場合に、そのルールは、グローバルなスコープを有するルールの前に呼び出される。下の例では、ワークアイテムタイプが、フィールドStatusに対するグローバル<COPY>ルールと、状態「Active」にスコープを指定された<COPY>ルールを有する。この場合に、ワークアイテムが「Active」状態に入る時に、値「Active」が、まずフィールドStatusにコピーされる。次に、これが、フィールドStatusへの空白ストリングのグローバルコピーによって上書きされる。
1.理由があるSTATE TRANSITION
2.STATE TRANSITION
3.STATE
4.STATEスコープなし
1.WHEN句
2.WHENNOT句
3.WHEN/WHENNOT句なし
1.<DEFAULT>ルール
2.<COPY>ルール
3.<SERVERDEFAULT>ルールを除く他のすべてのルール。<SERVERDEFAULT>ルールは、ワークアイテムが保存される時に限って評価される。
このセクションでは、プロビジョニングされ使用される時に問題を生じる可能性がある特別なケースのルールおよびルール組合せを扱う。これらは、3つのカテゴリすなわち、意味なし、問題あり、不正に分類される。最初の2つを下で述べる。不正なルール組合せとは、システムに関する深刻な問題を引き起こすルール組合せである。これらをプロビジョングすることは、システムによって防がれる。
ナンセンスなルールとは、明らかに誤っている、または意味がないルールである。このタイプのルールは、システムをクラッシュさせてはならず、予測不能な形で振る舞ってはならない。
1.同一のフィールドでの<READONLY/>ルールと<REQUIRED/>ルールの両方の使用
2.<REQUIRED/>ルールと<EMPTY/>ルールの両方の使用
3.非日付フィールドへの「クロック」からのデフォルトまたはコピー
4.非ストリングフィールドへの「currentuser」からのデフォルトまたはコピー
5.非ストリングフィールドでの<VALIDUSER>の使用
6.非日付フィールドでの<VALIDDATE>の使用
7.異なるタイプのフィールドでの<NOTSAMEAS>要素の使用
8.<LISTITEMS>での整数フィールドに対するストリング値の指定
9.タイプintegerのフィールドに対する<GROUPITEM>アイテムまたは<USERLIST>アイテムの指定
問題のあるルールとは、意味があるように見えるが、悪いか予測不能なシステム挙動をもたらすルールである。
<WHENCHANGED>ルールを<DEFAULT>句および<COPY>句と共に使用する複数のフィールドでの隠れた無限ループ。
(フォーム)
UI要素の内容および配置は、WITDの<FORM>セクションによって制御される。各ワークアイテムタイプは、1つのフォームだけを有しなければならない。このフォーム全体が、すべてのタブ、フィールド、およびグループを含めて記述される。
トップレベルに、WITDの<FORM>セクションへの3つの要素がある。
<LAYOUT>
この親要素に、ワークアイテムタイプフォームのすべてのレイアウト情報が含まれる。子要素は、このフォーム上にグループ、カラム、およびコントロールを配置する。
<GROUP>
子要素は、フォーム上の同一グループに含まれる。グループは、ボーダーおよびオプションのラベルによって画定される。隣接するグループは、垂直にスタックされる。
<COLUMN>
すべての子要素を同一カラム内に保ち、フォームを水平に分割する。カラムは、<GROUP>の中に現れなければならない。<COLUMN>要素内の<GROUP>要素は、ネストされたグループ化を作成するのに使用することができる。デフォルトで、カラムは<GROUP>を均等に分割する。オプションのPercentWidth属性を使用して、カラム幅を変更することができる。
コントロールは、フォームにフィールドまたは他の情報をレンダリングするのに使用される。各<CONTROL>要素が、Type属性およびオプションのラベルを有する。
・ FieldControl
・ TFStructureControl
・ WorkItemLogControl
・ LinksControl
・ AttachmentsControl
Label属性は、コントロールのとなりに表示されるテキストを指定する。関連するLabelPosition属性は、ラベルがコントロールに対してどこに表示されるかを指定する。
このコントロールは、フォームにフィールドを表示するのに使用される。フィールドコントロールは、参照名によってフィールドを参照しなければならない。
このコントロールは、Area PathフィールドおよびIteration Pathフィールドをツリーで表示する。ツリーは、展開でき縮小できる階層ノードを表示する。
ワークアイテムのヒストリフィールドおよび会話フィールドをレンダリングする。ワークアイテムに対するヒストリカルリビジョンに関する詳細を、このコントロールを使用して展開し、縮小することができる。
このワークアイテムから他のワークアイテムへのリンクを表示する。ユーザは、このコントロールを使用して、リンクを開き、編集し、追加し、除去することができる。
ワークアイテムに関するファイルアタッチメントを表示する。ユーザは、このコントロールを使用して、ファイルアタッチメントを開き、追加し、除去することができる。
次のテーブルに、<FORM>セクションの許容可能な要素および属性のすべての詳細を示す。上で述べた要素ならびに他の要素が含まれる。
WITDのサンプルフォームを示す。
一般に、エンドユーザから可視のWITDのすべての要素をローカライズすることができ、その結果、これらが、ユーザのネイティブ言語で表示されるようになる。これには、様々な要素の状態の名前、理由の名前、遷移の名前、「label」属性の名前、および「name」属性の名前と、エンドユーザに示されることを意図されたワークアイテムタイプ記述およびフィールドヘルプテキストなどの情報が含まれ、これらのすべてがユニコード文字をサポートする。これに関する唯一の例外は、フィールドのフレンドリ名(friendly name)であり、これは、フィールド名のセクションで述べたように、ユニコード文字の小さいサブセットに制限されている。
<WORKITEMTYPE name=”bug”>
name属性の値をローカライズすることができる。
<DESCRIPTION> Work item descriptive text here</DESCRIPTION>
ワークアイテムタイプ記述をローカライズすることができる。
<FIELD refname=”System.Title” name=”Title” type=”String”>
フィールド参照名およびタイプは、ローカライズ可能ではない。フィールド「name」属性の値は、ローカライズすることができる。しかし、フィールドについてユーザが選択した名前が、所与のTFSのすべてのクライアントで使用されることを銘記されたい。また、ユーザが、ワークアイテムタイプクエリを作成する時にフィールド名を見ることを想起されたい。
<HELPTEXT>This is a work item for bugs</HELPTEXT>
フィールドのヘルプテキストは、ローカライズすることができる。これは、ワークアイテムタイプごとであり、ワークアイテムタイプはチームプロジェクトごとである。
<LISTITEM value=”My Value”>
どのストリング値でもローカライズすることができる。
<STATE value=”Active”/>
<STATE value=”Complete”/>
<TRANSITION from=”Active”to=”Complete”>
<REASON value=”No Plans to Fix”/>
状態名および理由名をローカライズすることができる。
<CONTROL FieldName=”Found In Build” Label=”Found In” LabelPosition=”Top”>
このセクションの項目は、V1の仕様から除去されたが、後のリリースについて検討される可能性がある。
ユーザがアイテムを複数選択できるリストフィールド。
UIに表示される各状態に使用されるアイコンを指定する。
Delete − 深い洞察力がある管理者のためにこれを文書化する必要がある可能性がある
Sort
Add to front
Add to back
Add after
・ Boolean
我々は、フォームにチェックボックスとして表示されるBooleanフィールドタイプをサポートすることができる。しかし、これは現在、ProductStudioでよく使われてはおらず、ワークアラウンドがあり(0および1の値を有する整数フィールド)、我々は、V1についてはこれを検討しない。
・ DateOnly
年月日を表す。特定の瞬間ではなく、したがって、特定のタイムゾーンに結び付けられていない。
・ Day
このタイプのフィールドは、有効な曜日をとる(例えば、Tuesday)。
・ Month
このタイプのフィールドは、有効な月をとる(例えば、February)。
・ Year
このタイプのフィールドは、有効な年をとる(例えば、2004)。
<MIN/>/<MAX/>ルール
Stringフィールドタイプ
ストリングフィールドタイプの最小の文字および最大の文字をセットする
Integer/Doubleフィールドタイプ
整数フィールドタイプまたは浮動小数点フィールドタイプの最小値および最大値をセットする
<GRAYOUT/>
フォームは、フィールドが読み取り専用であることを示すが、そのフィールドは、それでもOMを介して書き込み可能である。<READONLY>要素と異なって、すべてのCurrituckクライアントが、このルールを尊重する責任を負う。
Double Validationルール
小数点以下の桁数を示すなど、double値を検証するルール
Double Displayオプション
通貨、丸めなど、doubleをフォーマットするためのフィールドディスプレイコントロールに関するオプション
ダイナミックリスト
ユーザが、フィールドに値をタイプすることができ、そのフィールドの許容される値のリストにそれを自動的に追加させることができるリスト。
いくつかのフィールド値は、クエリ作成またはレポート作成に特に重要である。WITDは、ユーザが、フィールドに関する2つの特別な属性を指定することを可能にする。両方がオプションである。単一のフィールドに、両方の属性を含めることができる。
この属性を有するフィールドは、クエリ性能を改善するインデックスをビルドされる。この属性は、控え目に、ワークアイテムタイプのうちで重要なフィールドだけに使用されたい。インデクシングは、タイプString、Integer、またはDateTimeのフィールドだけに使用することができる。
ワークアイテムタイプルール − カスタマシナリオ
生産的。統合。拡張可能。
1 要約
2 概要および範囲
3 ユーザがフィールド値を書き込むことを要求する
4 フィールド値をオートポピュレート(autopopulate)する
5 フィールド値の編集を制限する
6 柔軟なピックリストの管理
7 厳密なピックリストの管理
8 フィールド値へのユーザの割り当て
9 2レベル依存ピックリスト
10 2レベル依存ピックリスト(状態および理由)
11 3レベル依存ピックリスト
12 状態モデルの拡張
13 Integerフィールド値を検証する
14 Stringフィールド値を検証する
15 DateTimeフィールド値を検証する
16 インデクシングを使用するクエリ性能の改善
17 レポートにカスタムフィールド値を含める
18 監査証跡を実施する
19 ユーザ/グループによるトランザクションを許可しない
20 終盤でコードレビューを要求する
21 リストシナリオを通知する
22 複製リンクを要求する
この仕様書では、ワークアイテムタイプを作成する時にカスタマが実装することを望む重要なシナリオを説明する。
この文書の目的は、ワークアイテムタイプビジネスロジックを作成する時の重要なカスタマシナリオを識別し、そのサポートを保証することである。この文書では、カスタマが達成を試みているものを指定し、可能なXMLルールコンストラクトを識別し、実装/実施されるべき所望のユーザインタフェースおよびOM/BRIE挙動を定義する。この文書は、ワークアイテムタイプ作成文書化に直面するカスタマの基礎としても働く。
ワークアイテムタイプ作成者は、ユーザが、ある時に、フィールドのセットの値を入力することを保証することを望む。言い換えると、識別されたフィールドを空のままにすることはできない。
ユーザは、ワークアイテムのタイトルを入力しなければならない。
ユーザインタフェースの全体的な目標は、ユーザが、すべての値に正しい値を有するかどうかを視覚的にすばやく判定することを簡単にすることである。これを達成するために、必要なフィールドが現在値を有していない時に、そのフィールドを何らかの形で強調表示しなければならない。これは、バックグラウンドカラー、フィールドラベルカラー、および/またはアスタリスクとすることができる。アクセシビリティ要件も、この設計で考慮に入れなければならない。
誰かが、まだ空である必要なフィールドを有するワークアイテムの保存を試みた時に、バックエンドは、意味のあるエラーを作らなければならない。OMは、代替ユーザインタフェースの開発者がどのフィールドが値を必要とするかをすばやく判定し、したがって、ユーザのために意味のあるエラーメッセージを作ることができる方法を提供しなければならない。
必要性は、加法的である。例えば、ワークアイテムタイプについて<REQUIRED/>ルールが定義されている場合に、そのフィールドは、状態、遷移、または理由にかかわりなく、必ず必要である。<REQUIRED/>ルールが所与の状態に関する場合に、そのフィールドは、ワークアイテムがその状態である時またはその状態に入る時に、遷移または理由にかかわりなく必要である。
3.5.1 「Title」フィールドは、必ず値を有する必要がある
必ず、ワークアイテムに関して説明を入力する必要がある。
いくつかのワークアイテムは、「Submitted」状態または「New」状態で生じる。そこから、これらのワークアイテムは別のアクティブ状態に移動する。この例では、そのアクティブ状態が「Investigating」になる。ワークアイテムが「Investigating」状態である時には、それは誰かに割り当てられなければならない。
ワークアイテムを閉じるためには(理由にかかわりなく)、そのワークアイテムが誰かによってレビューされていなければならない。
だれかが、複製であるという理由のためにワークアイテムを解決している場合には、Duplicate IDフィールドに入力された複製idが存在しなければならない。他のすべての状態または理由について、このフィールドを空のままにすることができる。
このワークアイテムは、ソースを識別するフィールドを有する。ソースがカスタマからである場合には、カスタマ優先順位フィールドが書き込まれていなければならない。
ワークアイテム入力を単純にするために、カスタマができる限り多くのフィールドにオートポピュレートすることを試みている。これをサポートする4つのルール、<DEFAULT>、<COPY>、<SERVERDEFAULT>、および<EMPTY>がある。
デフォルト優先順位に、P3をセットする。
デフォルトルールは、あるフィールドが空の場合にそのフィールドに値を置く。フィールドが既に値を有する場合には、デフォルトルールは無視されなければならない。コピールールは、フィールドの前の値に関わりなくフィールドに値を置く。デフォルトルールおよびコピールールの両方が、フィールドが読み取り専用または必要であるかどうかに関して何かを暗示してはならない。
− WHEN句の外のすべてのデフォルトルールを処理しなければならない
− WHEN句の外のすべてのコピールールを処理しなければならない
− WHEN、WHENNOT、WHENCHANGEDの順番で、WHEN句の中のすべてのデフォルトルールおよびその次にコピールールを処理する
− 必要に応じて3レベルまで繰り返す
− 制御をユーザに渡す
未解決の問題:実際にはこれはどのように働くのか?
OM/BRIEは、上で説明したようにGUIを駆動するためにルールを処理しなければならない。
加法的である、REQUIREDルールと異なって、デフォルトルールおよびコピールールは、スコープが洗練された時にオーバーライドされなければならない。したがって、ワークアイテムタイプのデフォルト/コピールールは、状態固有デフォルト/コピールールによってオーバーライドされ、状態固有デフォルト/コピールールは、遷移固有デフォルト/コピールールによってオーバーライドされ、遷移固有デフォルト/コピールールは、理由固有デフォルト/コピールールによってオーバーライドされる。
未解決の問題:これを達成できるか?
4.5.1 優先順位フィールドのデフォルトをP3値にする
私は、許容される優先順位値のセットを有するが、P3のユーザのためにデフォルトが書き込まれることを望む。
私は、ビジネス優先順位およびカスタマ報告深刻度を定義したワークアイテムタイプを有する。カスタマ報告深刻度がS1の場合に、デフォルトで、ビジネス優先順位をP1にしなければならない。
未解決の問題:<SERVERDEFAULT from=’field’ value=’P1’/>が必要である。これをカットできるか?
私は、ワークアイテムが発見された日付を追跡したい。これは、そのワークアイテムがシステムに入力された日付の前である場合がある。しかし、ほとんどの場合に、これは、そのワークアイテムが入力された日付であり、したがって、「Discovered On」フィールドのデフォルトを現在時刻にするが、必要な場合に、ユーザがこの値を変更できるようにする。
未解決の問題:このシナリオに必要な<COPY from=’clock’/>をカットできるか?
ユーザがワークアイテムを保存する時に、必ず「Last Saved On」フィールドの値を強制的にサーバクロック時刻にする。
ワークアイテムがまだ誰にも割り当てられていない場合に、Assigned状態である時に現在のユーザをデフォルトにする。
開発者が、再現できないワークアイテムを解決する時、そのワークアイテムに割り当てられた人の値をreviewed byフィールドに書き込む。
カスタマが、あるフィールドに対する変更を行うことを許可される人を制御することを望む。彼らは、<READONLY/>ルールを使用してこれを行うことができる。さらに、for属性およびnot属性の使用を使用して、これらのルールの適用可能性のスコープを個人のサブセットに制限することができる。
この例では、カスタマは、グループTriageMembersのメンバだけがTriageフィールドの値を変更することを許可されることを望む。
このフィールドは、灰色のバックグラウンドを有しなければならず、ユーザが、値を編集できてはならない。
<READONLY>フィールドへの書き込みのすべての試みが、OM/BRIEによってブロックされなければならない。これに関する例外は、バックエンドで動作する<SERVERDEFAULT>要素および<EMPTY>要素である。
<READONLY>は加法的である。これには、for制約およびnot制約が含まれる。
5.5.1 グローバルREADONLY
期待される結果フィールドは、常に、GUIとOMの両方から読み取り専用である。
期待される結果フィールドは、状態フィールド=’some state’の時に読み取り専用である。
期待される結果フィールドは、オリジナルの状態フィールド値=’from state’であり、新しい状態フィールド値=’to state’の時に、GUIとOMの両方から読み取り専用である。
期待される結果フィールドは、オリジナルの状態フィールド値=’from state’であり、新しい状態フィールド値=’to state’であり、理由フィールド値=’some reason’の時に、GUIとOMの両方から読み取り専用である。
期待される結果フィールドは、GUIではグレイアウトされるが、OMからは変更可能である。
期待される結果フィールドは、状態フィールド=’some state’の時に、GUIではグレイアウトされるが、OMからは変更可能である。
期待される結果フィールドは、オリジナルの状態フィールド値=’from state’であり、新しい状態フィールド値=’to state’の時に、GUIではグレイアウトされるが、OMからは変更可能である。
期待される結果フィールドは、オリジナルの状態フィールド値=’from state’であり、新しい状態フィールド値=’to state’であり、理由フィールド値=’some reason’の時に、GUIではグレイアウトされるが、OMからは変更可能である。
forを使用して5.5.1から5.5.4までを繰り返す。期待される挙動、フィールドは、グループに含まれるか具体的に指定されたユーザについて読み取り専用であるが、他のユーザについては読み取り専用でない。
notを使用して5.5.1から5.5.4までを繰り返す。期待される挙動、フィールドは、グループに含まれないか具体的に指定されていないユーザについて読み取り専用であるが、このグループのユーザについては読み取り専用でない。
forgroupコンストラクトおよびnotgroupコンストラクトを使用して5.5.1から5.5.8までを繰り返す。
カスタマが、ユーザが選択できる推奨される値のセットを伴うフィールドを有することを望む。しかし、彼らは、ユーザが彼ら自身の値を入力するのを制約することを望んでいない。
カスタマは、バグが見つかったビルドを追跡することを望む。彼らは、ナイトリビルドのリストを有するが、開発者がローカルビルド番号も入力できるようにすることを望む。
ユーザに、彼らが提案される値の1つを選択できるようにするドロップダウンを提示しなければならない。ユーザは、手で値を入力することもできる。フィールドについて不正である値は絶対にない(フィールドが<REQUIRED/>要素も有する場合を除く。この場合には、NULL値が不正である)。
6.3 OM/BRIEハンドリング
柔軟なピックリストに関する特定のOM/BRIEハンドリング実施はない。
提案される値ルールは、提案される値セットの和集合を用いて作成される。同等の値をOMによってリストから除去し、ユーザに複数だが等しいオプションが提示されないようにしなければならない。ワークアイテムタイプ作成者が理由ごとに特定のリストを望む場合には、彼らは、理由レベルでのみ、提案される値を指定することができる。
上のXMLサンプルを参照されたい。
カスタマが、所与のフィールドの正しい値のリストを厳密に管理することを望む。ユーザは、所与のリストから正しい値だけを選択することができる。
詳細については下のシナリオを参照されたい。
ユーザに、そこから選択すべき正しい値の最新のリストを提供するドロップダウンを提示しなければならない。値がフィールドに既に存在し、その値が禁止される値のリストに含まれるか、禁止される値のルールおよび既存の値を許可するルールの両方がない場合には、そのフィールドを強調表示して、ユーザが変更を行う必要があることを示さなければならない。値がフィールドに既に存在し、allowexistingvaluesルールがある場合には、何も強調表示してはならない。
バックエンドは、最新のルールのセットに基づいて、常にフィールドが正しい値を有することを実施しなければならない。例外は、フィールドが正しい前の値(編集の前)を有し AND 許容される値のルールがある場合に、バックエンドが、コミットを受け入れなければならず、フィールドの値を無変更のままにしなければならないことである。
許容される値リストルールは、許容される値の交わりを用いて作成され、これには、禁止される値が含まれる。ワークアイテムタイプ作成者が、特定の理由レベルルールを指定することを望む場合には、彼らは、理由レベルだけに値リストを置くことによってこれを行うことができる。
未解決の問題:禁止される値は和集合か交わりか?
7.5.1 デフォルトを有する正しい値のリストの管理
ワークアイテムタイプ作成者が、Emergency、Major、Minor、またはVeryMinorのいずれかの値を有する欠陥の深刻度を示すために深刻度フィールドを望む。デフォルト値は、「Minor」である。
その後、彼らは、VeryMinorが実際にはそれほど有用でないと判断する。かれらは、これを許容される値のリストから除去することを望み、編集される時に既存レコードからこれを除去することを望む。次のXMLに、この変更を示す。値が単純に除去されており、ワークアイテムが編集される時に、必ず、「VeryMinor」値を有する以前のワークアイテムが、変更される必要があることに留意されたい。
その後、その会社が、エンジニアリングからの大量のフィードバックの後に、既存の「VeryMinor」値を「Minor」に変更することが意味をなさないと判断する。これらの値を、前のままにしておくことが、よりよい。ワークアイテムタイプ作成者は、次の変更を行う。
複数のフィールドが同一のリストを必要とすることがありえる。例えば、found on operating systemフィールドとfixed on operating systemフィールドを有すると仮定する。その両方が、必要なオペレーティングシステムのリストを有する。次のXMLは、このリストを一ヵ所に保持し、管理するのに使用される。デフォルト値が、found on operating systemフィールドからであることに留意されたい。
我々がサポートしたいもう1つのリストシナリオは、カスタマが、Currituckの外部に保管されたデータを有するCurrituckリストを自動的に最新状態に保つ能力である。これは、グローバルリスト(上と同様)を作成することによって行われる。しかし、開発者が我々のOMを使用して、
・ リスト値を追加し(前に、後に、インデックスの前に挿入)、
・ リスト値を除去し、
・ リスト内の値の個数を入手し、
・ リストに対して反復し、
・ リストをソートする
ことを可能にするOMインタフェースが必要である。
ユーザが、ワークアイテムを割り当てることを望む。しかし、割り当ては、多くの意味を持つ可能性がある。例えば、時々、バグが、そのバグがサブミットされたエリアに基づいてあるユーザにデフォルトで暗黙のうちに割り当てられることが望まれる。もう1つの例は、バグを、レビューされるグループに割り当てることである(TriageTeamに割り当てるなど)。もう1つの場合に、作成者は、ユーザが、システムの全ユーザのサブシステムから、明示的な割り当てを行うことを望む。このセクションでは、これらの様々なシナリオの概要を示す。
XMLサンプルは、下でシナリオごとに概要を示す。
V1には、タイプ「user/group」のフィールドはなく、「string」だけがある。それでも、ワークアイテムタイプ作成者は、ユーザ割り当てを検証する3つの手段を有する。
<VALIDUSER/>
有効ユーザルールは、入力されたユーザidがシステムの正しいユーザであるかどうかの検証に使用される。そうでない場合には、そのフィールドを、無効な値を有するものとして強調表示しなければならない。グループを伴うVALIDUSERコンストラクトは、入力されたユーザがそのグループに含まれることを保証しなければならない。
<ALLOWEDVALUES>/<PROHIBITEDVALUES>挙動は、下でシナリオごとに説明する。
V1には、タイプ「user/group」のフィールドはなく、「string」だけがあるので、OM/BRIEは、適当なルール(上を参照されたい)を実装するだけでよい。
<VALIDUSER/>ルールは、加法的なので、フィールドが、スコープのすべての下位レベルで有効なユーザIdを要求するようにする。
8.5.1 現在のユーザをフィールドに割り当てる
新しいワークアイテムが作成される時に、そのワークアイテムを作成するユーザが、デフォルトでフィールドに割り当てられる。許容される値のリストがなく、このフィールドが<VALIDUSER/>ルールを有するので、TFSで定義されたすべてのユーザが、割当可能であり、このフィールドのピックリストから使用可能でなければならない。さらに、ユーザは、手でユーザIdをタイプすることができる。GUI強調表示が、ユーザが有効な選択を行うのを助ける。OM/BRIEは、有効なユーザIdが入力されることを保証する。
8.5.2 特定のグループからのユーザをフィールドに割り当てる
このプロジェクトでワークアイテムに割り当てられるユーザは、プロジェクトチームのメンバでなければならない。すべてのプロジェクトチームメンバが、(BISまたはWindows(登録商標)の)グループ「MyProjectMembers」の一部である。assigned toフィールドのデフォルトは、現在のユーザである。ドロップダウンは、MyProjectMembersのメンバであるすべてのサブグループのメンバを含むように拡張されたMyProjectMembersの全ユーザのリストでなければならない。例えば、MyProjectMembersが、3つのサブグループ、Developers、Testers、およびProgramManagersだけを有する場合に、この3つのサブグループは表示されないが、この3つのサブグループの全メンバのリストが表示される。
この場合に、ワークアイテムを、ユーザ、グループ、または特定の値に割り当てることができる。この例について、このプロジェクトに割り当てられたユーザ(bob、shirley、dave、brian、およびmax)のフラットリストであるグループ「MyProjectMembers」がある。サブグループ「Development、Test、Documentation、ProgramManagement」を有し、このレベルでユーザを有しないグループ「MyProjectGroups」もある。さらに、バグを、まったくグループではない「Triage」に割り当てることを望むことができる。
Triage、bob、Shirley、dave、brian、max、Development、Test、Documentation
未解決の問題:これらが値、ユーザ、またはグループであることの表示をGUIでユーザに与える必要はあるか?
このフィールドに有効なユーザでない値を含めることができるので、有効ユーザルールはない。
しばしば、会社は、バグが報告されているエリア、コンポーネント、またはアプリケーションに基づいて、入ってくるバグにデフォルトプロジェクトリーダーを割り当てることを望む。エリアパスを与えられて、これを達成できなければならない。
・ Currituckワークアイテムタイプ定義言語のバグを「brianwh」に自動的に割り当てる。
・ Currituckリンキングサブシステムのバグを「lingbao」に自動的に割り当てる。
・ それ以外の場合に、バグを「bryanmac」に割り当てる。
・ サブミットする側がプロジェクトチームのメンバ(事情がよりよく分かっていると仮定する)でない限り、サブミットする側がこの割当をオーバーライドすることを許可してはならない。
・ 入力が有効なユーザであることを保証する。
・ 入ってきたバグが未割り当てになることは絶対に許容してはならない。
ユーザは、2つのフィールドを有し、一方が他方に依存する。すなわち、一方のフィールドで許容される値が、第1のフィールドの値に依存する。この例では、2つのフィールド、PlatformおよびVersionを使用し、Platformは基本オペレーティングシステムであり、Versionはそのオペレーティングシステムのバージョンを表す。
次が、2レベル依存ピックリストシナリオの基本的なXMLである。追加のXMLまたは変更を、下でシナリオごとに示す。また、Platformの値がUnknownの場合にVersionフィールドをクリアするルールに留意されたい。
望まれる挙動を、下でシナリオごとに説明する。
OM/BRIEハンドリングは、主に、セクション3の必要なフィールドおよびセクション7の厳密なピックリストの管理と同一の正しい値を実施することである。
この例は、状態、遷移、または理由にスコープを制限されない。
9.5.1 新しいワークアイテム、デフォルトをとる
ユーザが、新しいワークアイテムを作成し、その後、保存する。期待される結果は、フィールドPlatformにデフォルト値Windows(登録商標)が割り当てられ、フィールドVersionにデフォルト値XPが割り当てられることである。
ユーザは、「Windows(登録商標)」というデフォルト値を受け入れる。次に、ユーザは、「Version」フィールドのドロップダウンを選択する。これには、値「95、98、W2K、XP」が含まれる。ユーザは、95を選択し、保存する。
ユーザが、新しいワークアイテムを作成する。「Windows(登録商標)」および「XP」というデフォルト値が、プラットフォームフィールドおよびバージョンフィールドに置かれる。次に、ユーザは、フィールド「Platform」のドロップダウンを選択する。ユーザは、値「Windows(登録商標)」、「Unix(登録商標)」、「Linux」、および「Unknown」を得る。ユーザは、「Unix(登録商標)」を選択する。この時に、フィールド「Version」が強調表示される。というのは、不正な値「XP」が含まれるからである。ユーザは、これを見、バージョンフィールドのドロップダウンを選択し、選択肢「SunOS,HP−UX,AIX,and Solaris」を見る。ユーザは、「Solaris」を選択する。バージョンフィールドの強調表示がなくなる。ユーザは、保存する。
ユーザは、プラットフォーム値が「Windows(登録商標)」であり、バージョンが「XP」である既存ワークアイテムを開く。ユーザは、プラットフォームフィールドのドロップダウンを選択し、「Unix(登録商標)」を選ぶ。「XP」という値を有するバージョンフィールドが、不正なので強調表示される。ユーザは、プラットフォームドロップダウンを選択し、これを「Windows(登録商標)」に変更し、バージョンフィールドが、もはや強調表示されなくなる。
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは、「Windows(登録商標)」であり、バージョンフィールドは、「XP」である。ユーザは、プラットフォームのドロップダウンを選択し、「Unknown」に変更する。バージョンフィールドは、GUIでは、クリアされた読み取り専用である。
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは、「Windows(登録商標)」であり、バージョンフィールドは、「XP」である。ユーザは、プラットフォームのドロップダウンを選択し、「Unknown」に変更する。バージョンフィールドは、クリアされる。ユーザは、プラットフォームが「Linux」であることを思い出す。ユーザは、プラットフォームフィールドについてこの選択を行う。バージョンフィールドのデフォルトは、値「RedHat」である。
ワークアイテムタイプのワークフローでは、ワークアイテムが通過する状態、遷移、および理由を定義する。これは、XMLの<WORKFLOW>セクションで定義される。しかし、ユーザが状態モデルを操作する場所である2つのコアフィールド、State(System.State)およびReason(System.Reason)がある。これらのフィールドは、デフォルトを有する2レベル依存ピックリストのように振る舞う。
望まれる挙動を、下でシナリオごとに説明する。この2つのフィールドの挙動は、2レベル依存ピックリストに似ているが、いくつかの相違があり、これらの相違を、下でシナリオごとに太字で強調する。
OM/BRIEハンドリングは、主に、セクション3の必要なフィールドおよびセクション7の厳密なピックリストの管理と同一の正しい値を実施することである。
理由は、遷移にスコープを制限され、遷移は、状態対にスコープを制限される。
10.5.1 新しいワークアイテム、保存する
ユーザは、新しいワークアイテムを作成する。Stateに「NEW」がセットされ、Reasonに「New」がセットされる。
ユーザは、新しいワークアイテムを作成する。Stateに「NEW」がセットされ、Reasonに「New」がセットされる。ユーザは、理由のドロップダウンを選択し、「Found By Customer」を選び、保存する。
ユーザは、新しいワークアイテムを作成する。Stateに「NEW」がセットされ、Reasonに「New」がセットされる。ユーザは、状態の変更を試みるが、できない。というのは、これが、新しいワークアイテムの唯一の正しい状態であるからである。
ユーザは、状態値が「NEW」であり、理由に「New」がセットされた既存ワークアイテムを開く。ユーザは、Stateのドロップダウンを選択し、このドロップダウンは、「NEW」、「ASSIGNED」、または「CLOSED」を提供する。ユーザは、「ASSIGNED」を選択し、理由フィールドが、デフォルトの「Triaged」になる。
ユーザは、状態値が「NEW」であり、理由に「New」がセットされた既存ワークアイテムを開く。ユーザは、Stateのドロップダウンを選択し、このドロップダウンは、「NEW」、「ASSIGNED」、または「CLOSED」を提供する。ユーザは、「ASSIGNED」を選択し、理由フィールドが、デフォルトの「Triaged」になる。次に、ユーザは、考えを変え、状態フィールドをもう一度選択し、「NEW」に変更する。理由フィールドが強調表示されて、もはや有効な値が含まれないことを示す。ユーザは、理由フィールドをリセットするか、変更を保存せずにそのワークアイテムを閉じることができる。
多くのカスタマは、Nレベルピックリストを望む。このシナリオでは、セクション9の2レベルピックリストに基づいて作られる3レベルピックリストの例の概要を示す。この例では、我々は、前の例からのPlatformフィールドおよびVersionフィールドを有するが、オペレーティングシステムが有する可能性のあるすべてのパッチを示す第3のレベル「Patch」を追加する。
このXMLサンプルでは、Patchフィールドを定義する。PlatformフィールドおよびVersionフィールドは、セクション9.1で説明した。
この例および上の3レベルピックリストに関して留意すべき2つのことがある。第1に、プラットフォームフィールドがUnknownの場合に、Versionフィールドと同様にPatchフィールドをクリアする。第2に、ユーザが、Platform=LinuxおよびVersion=Otherを選択した場合に、ユーザが、明示的に許可される値のリストではなく、自由形式テキストを入力できるようにする。
バックエンドは、単に、通常の必要な値および許容される値の実施を行う。
この例について、状態、遷移、および理由によってスコープを指定された異なるルールを有することは、意味をなさない。私は、これがあてはまるシナリオを想像することができないが、それがあると確信している。このケースでの我々の推奨は、フィールドの明瞭な分離のためである。したがって、フィールドCがフィールドBの値に依存し、フィールドBがフィールドAの値に依存し、フィールドCが理由にも依存する場合に、我々は、フィールドAおよびBをグローバル<FIELDS>セクションで定義するように薦める。特定の理由の下の<WORKFLOW>セクションでフィールドCの<WHEN>を定義されたい。
11.5.1 新しいワークアイテム、デフォルトをとる
ユーザが、新しいワークアイテムを作成し、その後、保存する。期待される結果は、フィールドPlatformにデフォルト値Windows(登録商標)が割り当てられ、フィールドVersionにデフォルト値XPが割り当てられ、フィールドPatchにデフォルト値「None」が割り当てられることである。
ユーザが、新しいワークアイテムを作成する。ユーザは、「Windows(登録商標)」および「XP」というデフォルト値を受け入れる。次に、ユーザは、「Patch」フィールドのドロップダウンを選択する。これには、値「None」および「SP1」が含まれる。ユーザは、「SP1」を選択し、保存する。
ユーザが、新しいワークアイテムを作成する。「Windows(登録商標)」、「XP」、および「None」というデフォルト値が、プラットフォームフィールド、バージョンフィールド、およびパッチフィールドに置かれる。次に、ユーザが、「Platform」のドロップダウンを選択する。ユーザは、値「Windows(登録商標)」、「Unix(登録商標)」、「Linux」、および「Unknown」を得る。ユーザは、「Unix(登録商標)」を選択する。この時に、フィールド「Version」が、不正な値「XP」含むので強調表示される。パッチフィールドは、「None」という正しい値を含むので、強調表示されない。ユーザは、バージョンフィールドのドロップダウンを選択し、選択肢「SunOS,HP−UX,AIX,and Solaris」を見る。ユーザは、「Solaris」を選択する。バージョンフィールドの強調表示がなくなる。次に、ユーザは、Patchドロップダウンを選択し、「None」または「.01」を得る。ユーザは、「.01」を選択し、保存する。
ユーザは、プラットフォーム値が「Windows(登録商標)」であり、バージョンが「XP」であり、パッチが「SP1」である既存ワークアイテムを開く。ユーザは、プラットフォームフィールドのドロップダウンを選択し、「Unix(登録商標)」を選ぶ。バージョンフィールドおよびパッチフィールドが、不正なので強調表示される。ユーザは、プラットフォームドロップダウンを選択し、これを「Windows(登録商標)」に変更し、バージョンフィールドおよびパッチフィールドが、もはや強調表示されなくなる。
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは「Windows(登録商標)」であり、バージョンフィールドは「XP」であり、パッチフィールドは「None」である。ユーザは、プラットフォームのドロップダウンを選択し、「Unknown」に変更する。バージョンフィールドおよびパッチフィールドがクリアされる。
ユーザは、既存ワークアイテムまたは新しいワークアイテムを開く。プラットフォームフィールドは、当初は「Windows(登録商標)」であり、バージョンフィールドは「XP」であり、パッチフィールドは「SP1」である。ユーザは、プラットフォームのドロップダウンを選択し、「Unknown」に変更する。バージョンフィールドは、クリアされる。ユーザは、プラットフォームが「Linux」であることを思い出す。ユーザは、プラットフォームフィールドについてこの選択を行う。バージョンフィールドのデフォルトは、値「RedHat」であり、パッチフィールドのデフォルトは、「None」である。
ユーザは、新しいワークアイテムを開く。プラットフォーム、バージョン、およびパッチのデフォルトは、「Windows(登録商標)」、「XP」、および「None」である。ユーザは、プラットフォームに「Linux」を選択する。バージョンフィールドが無効として強調表示される(XPを有する)。ユーザは、バージョンに「Other」を選択する。パッチフィールドは、「None」のままになる。ユーザは、「None」を選択し、このフィールドをクリアする。ユーザは、パッチフィールドに「BL5」を入力し、保存する。
ユーザは、状態フィールドに結び付けられた「Sub−State」フィールドを作成することによって、out−of−the−boxワークフローを拡張することを望む。Sub−stateは、ワークアイテムが所与の状態である間の状況を示し、State変化がある時に必ずクリアされなければならない。
状態が変化した時に、必ず「SubState」フィールド値をクリアする。状態ごとに、許容される値のドロップダウンリストが、ユーザがそれから選択するのに使用可能である。
<REQUIRED/>ルールがないので、ワークアイテムをSubState値なしで保存することができる。所与の状態である時に、値は、許容される値のリストのうちの1つまたは空でなければならない。
状態が何になろうとしているかにかかわりなく、状態が変化する時に、必ずクリア動作が行われる。
12.5.1 Sub−Stateの割り当て
ユーザは、既存ワークアイテムを開く。状態は、「ACTIVE」であり、サブ状態フィールドは、空である。ユーザは、サブ状態フィールドのドロップダウンを選択し、「Blocked」、「Investigating」、および「Fixing」という選択肢を得る。ユーザは、「Fixing」を選択し、ワークアイテムを保存する。
ユーザは、既存ワークアイテムを開く。状態は、「ACTIVE」であり、サブ状態フィールドは、「Fixing」である。ユーザは、状態を「ACTIVE」から「RESOLVED」に変更する。サブ状態フィールドがクリアされる。ユーザは、ワークアイテムを保存する。
ユーザは、既存ワークアイテムを開く。状態は、「ACTIVE」であり、サブ状態フィールドは、空である。ユーザは、サブ状態値「On Hold」をタイプする。フィールドが、無効として強調表示される。ユーザは、サブ状態フィールドのドロップダウンを選択し、「Blocked」を選択し、ワークアイテムを保存する。
カスタマは、フィールドに整数値を望むが、正しいエントリを制限することを望む。
次の例では、カスタマが、優先順位を1と5の間の整数値にすることを望む。
ユーザは、優先順位フィールドに手で値を入力する。これが最小/最大ルールを満足しない場合に、そのフィールドを強調表示して、その値が不正であることをユーザに示さなければならない。ユーザは、そのフィールド上で移動(hover)して、ヘルプテキスト(有用でなければならない)を得ることができる。ユーザが問題を訂正したならば、強調表示が除去される。
バックエンドは、値が最小/最大制約を満足しない場合にエラーにならなければならない。
ルールは、加法的であり、したがって、有効な範囲は、制約の交わりである。したがって、例えば、グローバル制約が<MIN value=’5’>であり、状態固有制約が<MAX value=’20’>であり、遷移固有制約が<MIN value=’8’/>であり、理由固有制約が<MAX value=’10’>である場合に、所与の状態のワークアイテムについて、特定の遷移中に、この理由を与えられれば、正しい値は8〜10の範囲内になる。
13.5.1 Minのみ
<MIN value=’−5’/>を検討されたい。正しい値は、−5以上である。
<MAX value=’100’を検討されたい。正しい値は、100以下である。
<MIN value=’1’/> <MAX value=’5’/>を検討されたい。正しい値は、両端を含めて1〜5である。
<MIN value=’5’/> <MAX value=’5’/>を検討されたい。このフィールドは唯一の正しい値を有し、その値は5である。この場合に、UIは、フィールドにまだ値がない場合に、フィールド値を5というデフォルトにしなければならない。
<MIN value=’10’/> <MAX value=’5’/>を検討されたい。正しい値はない。インポータは、この状態を把握し、ワークアイテムタイプのプロビジョニングに失敗しなければならない。
ある最小値ルールが、状態に関わりなくフィールドについて指定され、状態固有であるもう1つの最小値ルールが指定されていると考えられたい。次のケースおよび結果のそれぞれが、(フィールドレベル/状態レベル)最小値について処理されなければならない。
・ 10/5(より小さいmin)
○ 正しい値は10以上である。ルールは、加法的であり、より制限的であり、したがって、ここではグローバルルールが優先される。
・ 10/20(より大きいmin)
○ 状態固有である時を除いて、正しい値は10以上である。状態固有である時には、このフィールドは20以上でなければならない。
ある最大値ルールが、状態に関わりなくフィールドについて指定され、状態固有であるもう1つの最大値ルールが指定されていると考えられたい。次のケースおよび結果のそれぞれが、(フィールドレベル/状態レベル)最大値について処理されなければならない。
・ 10/5(より小さいmax)
○ 状態固有の時を除いて、正しい値は、10以下である。状態固有の時には、このフィールドは5以下でなければならない。
・ 10/20(より大きいmax)
○ 正しい値は、10以下である。ルールは、加法的であり、より制限的であり、したがって、ここではグローバルルールが優先される。
最小値ルールと最大値ルールの両方が、状態に関わりなくフィールドについて指定され、状態固有であるもう1つの最小値/最大値ルールが指定されていると考えられたい。次のケースおよび結果のそれぞれが、(最小−最大グローバルレベル/最小−最大状態レベル)について処理されなければならない。
・ 10−20/5−8(内側)
○ 正しい値は、10〜20であり、状態固有の正しい値は、5〜8である。
・ 10−20/5−25(外側)
○ 正しい値は、10〜20であり、状態固有の正しい値は、同一の10〜20である。
・ 10−20/5−15(下側スパン)
○ 正しい値は、10〜20であり、状態固有の正しい値は、10〜15である。
・ 10−20/15−25(上側スパン)
○ 正しい値は、10〜20であり、状態固有の正しい値は、15〜20である。
・ 10−20/10−30(同一のmin、より大きいmax)
○ 正しい値は、10〜20であり、状態固有の正しい値は、同一の10〜20である。
・ 10−20/10−15(同一のmin、より小さいmax)
○ 正しい値は、10〜20であり、状態固有の正しい値は、10〜15である。
・ 10−20/5−20(より小さいmin、同一のmax)
○ 正しい値は、10〜20であり、状態固有の正しい値は、5〜20である。
・ 10−20/15−20(より大きいmin、同一のmax)
○ 正しい値は、10〜20であり、状態固有の正しい値は、15〜20である。
次のシナリオは、無効であり、インポータは、これらを把握し、プロビジョニング中にエラーにならなければならない。
・ 10−20/1−5
・ 10−20/25−30
○ 両方が、グローバルには正しいが、状態固有の正しい値がない。
時々、<ALLOWEDVALUES>を使用して行われるように、ストリングフィールドの値の明示的なリストを指定するのではなく、ワークアイテムタイプ作成者が、ストリングエントリへのある規則を実施することを望む。これのよい例が、ビルドidまたはバージョンidである。これは、<MATCH>句を使用して行われる。
理想的には、ユーザインタフェースは、無効なストリング値が入力された場合に強調表示する。しかし、私は、これがP2であると考える。最高の優先順位は、ユーザがフィールド上で移動(hover)した場合にフィールドのヘルプテキストを表示することである。我々は、フィールドのフォーマット要件がヘルプテキストで表示されることを推奨する。
バックエンドは、フィールドの値が<MATCH>ストリングに従うことを検証しなければならない。無効であるフィールドおよびマッチストリングを含むフィールド(ユーザがヘルプテキストをミスタイプした場合)の両方について、エラーをユーザに報告しなければならない。
<DEFAULT>ルールと同様に、<MATCH>は、互いにオーバーライドしなければならず、加法的ではない。
有効な組合せと無効な組合せの両方および複数のマッチストリングをテストしなければならない。
カスタマは、ユーザが日付または日時を入力することを望むが、入力された値が正しいことを保証することを望む。これは、<VALIDDATE>コンストラクトを使用して行われる。
カスタマが作成を試みる可能性があるサンプルのワークアイテムタイプ定義を説明する。
<VALIDDATE mustbe=’after now’/>
日付フィールドを検証する。Mustbe値は、「after now」または「not after now」のいずれかとすることができる。「after now」は、現在時刻の後である。「not after now」は、フィールド値が現在時刻またはそれ以前であることを要求する。DateTimeフィールドタイプに使用される。
望まれるUIハンドリングを、下でシナリオごとに説明する。
望まれるOM/BRIEハンドリングを、下でシナリオごとに説明する。
<VALIDDATE>ルールは、加法的である。「after now」ルールと「not after now」ルールの両方を有することは、不正である。このケースは、プロビジョニング時に把握されなければならない。
15.5.1 現在時刻をデフォルトとし、ユーザが後の時刻にオーバーライドできるようにする
ユーザは、タスクが完了のためにスケジューリングされた時に、フィールドが時刻を保持することを望む。ユーザは、正しいフォーマットの考え方をユーザに与えるために現在時刻をデフォルトにすることを望むが、ユーザがその値をオーバーライドできるようにすることを望む。ユーザは、入力される時刻が現在または将来であることを保証することを望む。最後に、タスクが完了した場合に、ユーザは、ヒストリック監査のためにその値を読み取り専用にすることを望む。
ユーザは、バグがクローズされた日付を保持するフィールドを有することを望む。ユーザは、ユーザがバグを保存する時にこれが書き込まれることを望み、ユーザがこのフィールドを直接に変更できることを望まない。ユーザは、CLOSED状態でない限りこのフィールドが空のままになり、CLOSED状態ではこのフィールドがREQUIREDになることを望む。ユーザは、OMを介するすべての変更が、このフィールドに将来の日付を絶対に置かないことを保証することも望む。次のXMLは、ワークアイテムタイプ作成者がこの問題にどのようにアプローチするかである。
ワークアイテムタイプ作成者は、新しいフィールドCustomerIDを追加しており、彼は、このフィールドがクエリに激しく使用されることを知っている。彼は、これに関するクエリ性能が非常によいことを保証することを望む。
エンドユーザUI変更は不要である。ワークアイテムタイプエディタは、ユーザが、フィールドがインデックス付きであるか否かを調べることを可能にする。
16.3 OM/BRIEハンドリング
フィールドは、インデクシングされる。
適用可能ではない。
我々は、これが性能を改善することを検証しなければならない。例えば、10000個のレコードを作成する。クリアキャッシュおよびロードされたキャッシュを用いてクエリ性能をテストする。ワークアイテムタイプエディタを使用して、インデクシングされる主フィールドを変更する。クエリを再実行する。期待される挙動は、クリアキャッシュに関する性能を大きく改善する。キャッシングされたデータに関して、性能改善はわずかであるか、ない。
ワークアイテムタイプ作成者は、新しいフィールドCustomerIDを追加しており、彼は、このフィールドがレポートに激しく使用されることを知っている。彼は、カスタマidデータがデータウェアハウスで使用可能であることを保証することを望む。
エンドユーザインタフェース変更は不要である。Rosettaレポートライタは、このフィールドがウェアハウスに送られたならば、このフィールドをレポートでの使用に使用可能にしなければならない。ワークアイテムタイプエディタは、作成者が、フィールドがレポート可能であるか否かを調べることを可能にしなければならない。
このフィールドの値を有するすべてのワークアイテムを、適当に定義された間隔でウェアハウスに送らなければならない。
適用可能ではない。
カスタムフィールドを有する新しいワークアイテムタイプをプロビジョニングする。いくつかのワークアイテムを作成する。Rosettaに移り、そのカスタムフィールドを使用するレポートを作成する。レポートを実行して、それが動作することを検証する。
Currituckを使用して、ユーザは、ワークアイテムタイプに関する彼らの状態を定義することができる。状態名に対する制約がないことに留意することが重要である。我々は、ワークアイテムのリビジョンごとに変更されたもののフル監査証跡に似た、ワークアイテムタイプの監査のいくつかのコアレベルを提供し、Created On値、Created By値、Last Modified On値、およびLast Modified By値を追跡する。
これらのルールは、ワークアイテムがActiveであり、Resolved OnフィールドおよびResolved Byフィールドが空である時を示す。これらのフィールドは、UIでは読み取り専用に見え、値を有しない。
このシナリオは、より複雑であり、複数のルール、<EMPTY/>、<FROZEN/>、<SERVERDEFAULT>、および<REQUIRED/>の調整を示す。これらのルールは、ユーザがカスタム状態を監査することを可能にするために、共同して働かなければならない。
適用可能ではない。
上を参照されたい。
カスタマは、遷移にセキュリティを適用し、一部のユーザおよびグループがある遷移を行うことを許可され、それ以外のものが同一のことを行うことを拒絶されることを望む。
V1について、特別なユーザインタフェースハンドリングはない。V1bar以降に進むと、我々は、ユーザがその遷移を行うアクセス権を有しないことを我々が知っている場合に状態フィールドのドロップダウンリストから状態値を除去する。
バックエンドは、ワークアイテムタイプの保存を許可する前に、ユーザが状態遷移を行うアクセス権を有することを保証しなければならない。ユーザがアクセスを拒絶される場合に、バックエンドは、UIを介してレポートし、エラーにならなければならない。例えば、「You do not have permission to transition the work item from Resolved to Complete state」(ワークアイテムをResolved状態からComplete状態に遷移させるアクセス権がありません)。
適用可能ではない。これらのコンストラクトは、遷移だけについて有効である。
19.5.1 AllTestersのメンバ
ユーザは、遷移を実行することを許可される。
ユーザは、遷移を実行することを許可されない。
ユーザは、遷移を実行することを許可されない。拒絶が優先する。
ユーザは、遷移を実行することを許可されない。任意のALLOW/DENYコンストラクトが、暗黙の「このワークアイテムへのアクセスを有する誰もが、遷移を許可される」を制限する。
特定のユーザを、これらのルールについて指定することができるが、遷移ごとに1つの<ALLOW>または<DENY>だけを設けることができる。
未解決の問題:このステートメントを検証せよ。
ワークアイテムタイプ作成者は、開発プロジェクトが終盤である時に、すべてのバグが、割り当てられたユーザ以外の誰かによってコードレビューされなければならないという会社ポリシを実施することを試みている。彼らは、このプロセスを誰もが回避しないことを保証することも望む。
フィールド値を現在のユーザと比較するWHEN句:<WHEN field="fieldname" value=currentuser>
フィールドが特定の値でない時に遷移を停止する句:<ALLOWWHEN field="fieldname" value="somevalue">
<ALLOWWHEN>ルールをバイパスする方法
このすべてから、私は、我々がこのシナリオを再訪し、これを最もよくサポートする方法を調べる必要があると考える。
下で説明する。
下で説明する。
適用可能ではない。
20.5.1 プロジェクトが終盤に入る
プロジェクトが終盤に入った時に、ワークアイテムタイプ作成者は、コードレビューを実行せずにResolvedに遷移することを効果的に停止させるルール<ALLOWWHEN>を追加する。
Bobは、割り当てられたバグを修正する。Bobは、彼らが終盤にいることの電子メールを読む暇がなく、したがって、誰にもコードレビューを要求しなかった。Bobは、Stateを選択し、その値を「Active」から「Resolved」に変更する。通常通り、終盤の前に、Reviewedフィールドには「notdone」がセットされ、Review Notesは空である。この両方のフィールドが、読み取り専用である。
Samは、バグのところに行き、linksタブを調べる。Samは、Bobが行った変更セットへのリンクを見る。Samは、そのリンクをダブルクリックして、Hatterasに行き、各ソースファイルを選択し、「diff with predecessor」を行う。レビューの後に、Samは、バグを立ち上げる。
Bobは、バグを立ち上げ、ActiveからResolvedに遷移する。これは、今回はうまくいく。
もう1つの場合に、バグが、レビューなしで持ち込まれる必要がある場合があり、ある人がこのプロセスをバイパスする方法が必要である。この場合に、<ALLOW>ルールは、<ALLOWWHEN>ルールに優先する。TriageLeadは、コードレビューされたか否かに関わりなく、バグを解決することができる。
ここでの基本的なシナリオは、カスタマが、所与のワークアイテムの通知リストを維持することを望むというものである。その通知リストに含まれるすべてのメンバが、ワークアイテムが編集された時に必ず電子メールを送られる。
適用可能ではない。
適用可能ではない。
適用可能ではない。
ユーザは、ワークアイテム変化イベントをリスン(listen)するイベントハンドラを記述する。イベントが到着し、「NotifyList」フィールドに値がある場合に、このハンドラは、電子メールを構成し、通知リスト内の全ユーザに送信する。
カスタマは、次のルールを実施することを望む。バグが解決され、理由が「Duplicate」である場合に、少なくとも1つの複製リンクが確立されていることを必要とする。
1)そのフィールドをテストする方法、<ALLOWWHEN greaterthan=’0’を使用した
もちろん、これは、lessthan、equals、notequalsなどのすべてを暗示する。
下を参照されたい。
バックエンドは、リンクタイプごとにコアフィールドを維持し、作成されたタイプのリンクの個数のカウントを記録しなければならない。
適用可能ではない。
ユーザは、複製リンクを確立せずに、ワークアイテムを、理由DuplicateとしてResolvedに遷移させることを試みる。提供されるエラー「You are unable to transition to Resolved for reason Duplicate, field DuplicateLinkCount must be greater than 0」(理由DuplicateでResolvedに遷移することはできません。フィールドDuplicateLinkCountが0より大きくなければなりません)。
104 WITSクライアント
106 WITSクライアント
110 ワークアイテムIF
112 セキュリティIF
114 クライアントWIRエンジン
116 WIRキャッシュ
118 ネットワーク
120 WITSサーバ
122 WIRクライアント/サーバIF
124 サーバWIRエンジン
128 WITS情報
130 WIR情報
1101 出力デバイス
1102 入力デバイス
1103 プロセッサ
1104 メモリ
1105 相互接続機構
1106 ストレージ
1202 ストレージシステムメモリ
Claims (14)
- サーバと少なくとも1つのクライアントコンピュータとを含むワークアイテムトラッキングシステムの1つまたは複数のワークアイテムに影響するクライアントコンピュータアクションを統制するコンピュータ実装方法であって、
前記システムは、論理階層に編成された複数のワークアイテムを備え、第1のワークアイテムは、前記階層の第1のレベルに対応し、第2のワークアイテムは、前記第1のレベルに優先する前記階層の第2のレベルに対応し、
前記方法は、
(A)前記コンピュータのプロセッサが、前記ワークアイテムトラッキングシステムの第1のワークアイテムに影響する、第1のクライアントコンピュータによる第1のクライアントコンピュータアクションに応答して、前記第1のクライアントコンピュータおよび/または前記第1のワークアイテムに対応する1つまたは複数のワークアイテムルールを判定する動作であって、前記第1のワークアイテムに対応する第1のワークアイテムルールを判定することと、前記第2のワークアイテムに対応する第2のワークアイテムルールを判定することとを含む動作と、
(B)前記コンピュータのプロセッサが、前記1つまたは複数の判定されたワークアイテムルールを解釈する動作であって、前記第1および第2のワークアイテムルールを解釈することと、前記第1のレベルに優先する前記階層の前記第2のレベルに少なくとも部分的に基づいて、前記第1のワークアイテムルールの前記解釈を前記第2のワークアイテムルールの前記解釈によってオーバーライドすることとを含む動作と、
(C)前記コンピュータのプロセッサが、前記1つまたは複数の判定されたワークアイテムルールの前記解釈に基づいて前記第1のクライアントコンピュータアクションに応答する動作と
を含み、
前記ワークアイテムトラッキングシステムは、少なくとも第1のネットワーク要素および1つまたは複数の通信媒体によって前記第1のネットワーク要素に接続された第2のネットワーク要素に渡って分散され、前記第1のネットワーク要素は、第1のモジュールを備え、前記第2のネットワーク要素は、第2のモジュールを備え、前記方法は、
(D)前記第1のモジュールが前記第1のワークアイテムに影響する前記クライアントコンピュータアクションを指定する前記クライアントコンピュータからの入力を受け取る動作
をさらに含み、前記動作(A)〜(C)は、前記第1のモジュールによって実行され、前記方法は、
(E)前記第2のモジュールが前記1つまたは複数の判定されたワークアイテムルールを解釈する動作
をさらに含むことを特徴とする方法。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、前記第1のクライアントコンピュータまたは前記第1のクライアントコンピュータが属する前記クライアントコンピュータのグループに対応し、
前記動作(B)は、前記少なくとも1つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項1に記載の方法。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、ワークアイテムの内容に対応し、
前記動作(B)は、前記少なくとも1つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項1に記載の方法。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、ワークアイテムの1つまたは複数のプロパティに対応し、
前記動作(B)は、前記少なくとも1つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項1に記載の方法。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、プロダクトの少なくとも1つの態様に対応し、
前記動作(B)は、前記少なくとも1つの判定されたワークアイテムルールを解釈することを含むことを特徴とする請求項1に記載の方法。 - (D)前記クライアントコンピュータが1つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェースを提供する動作
をさらに含むことを特徴とする請求項1に記載の方法。 - サーバと少なくとも1つのクライアントコンピュータとを含むワークアイテムトラッキングシステムの1つまたは複数のワークアイテムに影響するクライアントコンピュータアクションを統制するシステムであって、
前記システムは、論理階層に編成された複数のワークアイテムを備え、第1のワークアイテムは、前記階層の第1のレベルに対応し、第2のワークアイテムは、前記第1のレベルに優先する前記階層の第2のレベルに対応し、
前記ワークアイテムトラッキングシステムの第1のワークアイテムに影響する、第1のクライアントコンピュータによる第1のクライアントコンピュータアクションに応答して、前記第1のクライアントコンピュータおよび/または前記第1のワークアイテムに対応する1つまたは複数のワークアイテムルールを判定し、前記1つまたは複数の判定されたワークアイテムルールを解釈し、前記解釈に基づいて前記第1のクライアントコンピュータアクションに応答する、第1のワークアイテムルールエンジンであって、
前記第1のワークアイテムに対応する第1のワークアイテムルールを判定し、前記第2のワークアイテムに対応する第2のワークアイテムルールを判定するように動作し、
前記第1および第2のワークアイテムルールを解釈し、前記第1のレベルに優先する前記階層の前記第2のレベルに少なくとも部分的に基づいて、前記第2のワークアイテムルールの前記解釈による前記第1のワークアイテムルールの前記解釈のオーバーライドを制御するように動作する、第1のワークアイテムルールエンジン
を備え、
前記第1のワークアイテムルールエンジンは、第1のネットワーク要素に常駐し、前記第1のワークアイテムルールエンジンは、前記第1のクライアントコンピュータアクションを指定する前記クライアントコンピュータからの入力を受け取るように動作し、
1つまたは複数の通信媒体によって前記第1のネットワーク要素に接続された第2のネットワーク要素に常駐する第2のワークアイテムルールエンジンであって、前記第1のモジュールによって適用されるのと異なって前記1つまたは複数の判定されたワークアイテムルールを解釈するように動作する第2のワークアイテムルールエンジンをさらに備えることを特徴とするシステム。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、前記第1のクライアントコンピュータまたは前記第1のクライアントコンピュータが属する前記クライアントコンピュータのグループに対応し、
前記第1のワークアイテムルールエンジンは、前記少なくとも1つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項7に記載のシステム。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、ワークアイテムの内容に対応し、
前記第1のワークアイテムルールエンジンは、前記少なくとも1つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項7に記載のシステム。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、ワークアイテムの1つまたは複数のプロパティに対応し、
前記第1のワークアイテムルールエンジンは、前記少なくとも1つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項7に記載のシステム。 - 前記1つまたは複数の判定されたワークアイテムルールのうちの少なくとも1つは、プロダクトの少なくとも1つの態様に対応し、
前記第1のワークアイテムルールエンジンは、前記少なくとも1つの判定されたワークアイテムルールを解釈するように動作することを特徴とする請求項7に記載のシステム。 - 前記クライアントコンピュータが1つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェース
をさらに備えることを特徴とする請求項7に記載のシステム。 - コンピュータ読み取り可能な記録媒体に保管され、コンピュータによって実行された結果として、サーバと少なくとも1つのクライアントコンピュータとを含むワークアイテムトラッキングシステムの1つまたは複数のワークアイテムに影響するクライアントコンピュータアクションを統制するプロセスを実行するように前記コンピュータを制御するプログラムであって、
前記システムは、論理階層に編成された複数のワークアイテムを備え、第1のワークアイテムは、前記階層の第1のレベルに対応し、第2のワークアイテムは、前記第1のレベルに優先する前記階層の第2のレベルに対応し、
前記プロセスは、
(A)前記コンピュータのプロセッサが、前記ワークアイテムトラッキングシステムの第1のワークアイテムに影響する、第1のクライアントコンピュータによる第1のクライアントコンピュータアクションに応答して、前記第1のクライアントコンピュータおよび/または前記第1のワークアイテムに対応する1つまたは複数のワークアイテムルールを判定する動作であって、前記第1のワークアイテムに対応する第1のワークアイテムルールを判定することと、前記第2のワークアイテムに対応する第2のワークアイテムルールを判定することとを含む動作と、
(B)前記コンピュータのプロセッサが、前記1つまたは複数の判定されたワークアイテムルールを解釈する動作であって、前記第1および第2のワークアイテムルールを解釈することと、前記第1のレベルに優先する前記階層の前記第2のレベルに少なくとも部分的に基づいて、前記第1のワークアイテムルールの前記解釈を前記第2のワークアイテムルールの前記解釈によってオーバーライドすることとを含む動作と、
(C)前記コンピュータのプロセッサが、前記1つまたは複数の判定されたワークアイテムルールの前記解釈に基づいて前記第1のクライアントコンピュータアクションに応答する動作と
を含み、
前記ワークアイテムトラッキングシステムは、少なくとも第1のネットワーク要素および1つまたは複数の通信媒体によって前記第1のネットワーク要素に接続された第2のネットワーク要素に渡って分散され、前記第1のネットワーク要素は、第1のモジュールを備え、前記第2のネットワーク要素は、第2のモジュールを備え、前記プロセスは、
(D)前記第1のモジュールが前記第1のワークアイテムに影響する前記クライアントコンピュータアクションを指定する前記クライアントコンピュータからの入力を受け取る動作
をさらに含み、前記動作(A)〜(C)は、前記第1のモジュールによって実行され、前記プロセスは、
(E)前記第2のモジュールが前記1つまたは複数の判定されたワークアイテムルールを解釈する動作
をさらに含むことを特徴とするプログラム。 - 前記プロセスは、
(D)前記クライアントコンピュータが1つまたは複数のワークアイテムルールを定義することを可能にするユーザインタフェースを提供する動作
をさらに含むことを特徴とする請求項13に記載のプログラム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/090,692 US8554599B2 (en) | 2005-03-25 | 2005-03-25 | Work item rules for a work item tracking system |
US11/090,692 | 2005-03-25 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2006277745A JP2006277745A (ja) | 2006-10-12 |
JP2006277745A5 JP2006277745A5 (ja) | 2009-04-09 |
JP5238138B2 true JP5238138B2 (ja) | 2013-07-17 |
Family
ID=36579789
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006086542A Expired - Fee Related JP5238138B2 (ja) | 2005-03-25 | 2006-03-27 | ワークアイテムトラッキングシステム用のワークアイテムルール |
Country Status (5)
Country | Link |
---|---|
US (1) | US8554599B2 (ja) |
EP (1) | EP1705607A1 (ja) |
JP (1) | JP5238138B2 (ja) |
KR (1) | KR101238573B1 (ja) |
CN (1) | CN1838165A (ja) |
Families Citing this family (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8554599B2 (en) | 2005-03-25 | 2013-10-08 | Microsoft Corporation | Work item rules for a work item tracking system |
US20070055921A1 (en) * | 2005-08-30 | 2007-03-08 | Challenor Timothy W | Document editing system |
JP2008217501A (ja) * | 2007-03-06 | 2008-09-18 | Mitsubishi Electric Corp | 情報処理装置及び情報処理方法及びプログラム |
US8082274B2 (en) * | 2007-06-28 | 2011-12-20 | Microsoft Corporation | Scheduling application allowing freeform data entry |
FR2930829A1 (fr) * | 2008-04-30 | 2009-11-06 | Airbus France Sas | Procede et dispositif d'aide a la conception de textes pour pilote, membre d'equipage ou conducteur |
JP5172585B2 (ja) * | 2008-10-07 | 2013-03-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | オブジェクト・モデルに対するアクセスを制御するシステム、方法、およびプログラム |
EP2416267A1 (en) * | 2010-08-05 | 2012-02-08 | F. Hoffmann-La Roche AG | Method of aggregating task data objects and for providing an aggregated view |
US8438185B2 (en) * | 2010-11-17 | 2013-05-07 | Hitachi, Ltd. | File storage apparatus and access control method |
US8713056B1 (en) * | 2011-03-30 | 2014-04-29 | Open Text S.A. | System, method and computer program product for efficient caching of hierarchical items |
EP2506171A1 (en) * | 2011-04-01 | 2012-10-03 | Waters Technologies Corporation | Graphical user interfaces for scientific data information sytems |
US20130080201A1 (en) * | 2011-09-23 | 2013-03-28 | Dustin Miller | System and method for tracking task data |
US10042603B2 (en) | 2012-09-20 | 2018-08-07 | Samsung Electronics Co., Ltd. | Context aware service provision method and apparatus of user device |
KR102070196B1 (ko) | 2012-09-20 | 2020-01-30 | 삼성전자 주식회사 | 사용자 디바이스에서 상황 인식 서비스 제공 방법 및 장치 |
US9679264B2 (en) * | 2012-11-06 | 2017-06-13 | Oracle International Corporation | Role discovery using privilege cluster analysis |
US20150051957A1 (en) * | 2013-08-15 | 2015-02-19 | Oracle International Corporation | Measuring customer experience value |
JP6333005B2 (ja) * | 2014-03-17 | 2018-05-30 | キヤノン株式会社 | 画像形成装置及びその制御方法とプログラム |
CN105446985B (zh) * | 2014-06-30 | 2018-12-14 | 北京金山安全软件有限公司 | 一种缓存文件夹识别方法及装置 |
CN105068876B (zh) * | 2015-07-01 | 2017-12-08 | 北京博睿宏远数据科技股份有限公司 | 基于分布式部署真机采集手机app性能数据的方法 |
JP6766600B2 (ja) * | 2016-03-17 | 2020-10-14 | 株式会社リコー | 情報処理装置とそのプログラム及び会議支援システム |
US10395220B2 (en) | 2016-04-20 | 2019-08-27 | International Business Machines Corporation | Auto-generation of actions of a collaborative meeting |
US20190207946A1 (en) * | 2016-12-20 | 2019-07-04 | Google Inc. | Conditional provision of access by interactive assistant modules |
JP7031468B2 (ja) * | 2018-04-20 | 2022-03-08 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置、情報処理システム、及びプログラム |
CN108959562B (zh) * | 2018-07-04 | 2020-06-30 | 北京京东尚科信息技术有限公司 | 应用在区块链上的海量规则数据处理方法和系统 |
EP3937030B1 (en) | 2018-08-07 | 2024-07-10 | Google LLC | Assembling and evaluating automated assistant responses for privacy concerns |
KR102200980B1 (ko) * | 2019-03-04 | 2021-01-11 | 주식회사 휴비즈아이시티 | 멀티 유저 에디팅 기능을 지원하는 가상 환경 구현 시스템 및 방법 |
CN110134739A (zh) * | 2019-05-23 | 2019-08-16 | 苏州浪潮智能科技有限公司 | 一种混合写流程处理方法、系统、设备及计算机存储介质 |
CN110363538A (zh) * | 2019-06-12 | 2019-10-22 | 深圳市源润信息科技有限公司 | 产品溯源方法、智能终端及云端装置 |
CN112347160B (zh) * | 2020-11-13 | 2024-05-10 | 广州太信信息科技有限公司 | 一种基于呼叫中心系统的工单管理方法、系统及存储介质 |
Family Cites Families (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4809170A (en) * | 1987-04-22 | 1989-02-28 | Apollo Computer, Inc. | Computer device for aiding in the development of software system |
EP0501613A3 (en) * | 1991-02-28 | 1993-09-01 | Hewlett-Packard Company | Heterogeneous software configuration management apparatus |
US5455903A (en) * | 1991-05-31 | 1995-10-03 | Edify Corp. | Object oriented customer information exchange system and method |
JP3381931B2 (ja) | 1991-06-14 | 2003-03-04 | 株式会社日立製作所 | 設計変更作業管理方法 |
US5321610A (en) * | 1991-09-23 | 1994-06-14 | The Cobre Group, Inc. | Integrated product for implementing application software and process of developing integrated product for implementing application software |
GB2263988B (en) * | 1992-02-04 | 1996-05-22 | Digital Equipment Corp | Work flow management system and method |
US5574898A (en) * | 1993-01-08 | 1996-11-12 | Atria Software, Inc. | Dynamic software version auditor which monitors a process to provide a list of objects that are accessed |
US5999911A (en) * | 1995-06-02 | 1999-12-07 | Mentor Graphics Corporation | Method and system for managing workflow |
US6157934A (en) * | 1995-10-24 | 2000-12-05 | Ultimus, L.L.C. | Method and apparatus for using distributed spreadsheets in a client/server architecture for workflow automation |
US5765140A (en) * | 1995-11-17 | 1998-06-09 | Mci Corporation | Dynamic project management system |
JPH1013403A (ja) | 1996-06-21 | 1998-01-16 | Nec Corp | データ管理システム |
US6006193A (en) * | 1996-12-18 | 1999-12-21 | Gibson; Kenneth U. | Computer executable workflow control system |
US6308164B1 (en) * | 1997-04-28 | 2001-10-23 | Jeff Nummelin | Distributed project management system and method |
US6334124B1 (en) * | 1997-10-06 | 2001-12-25 | Ventro Corporation | Techniques for improving index searches in a client-server environment |
US6430538B1 (en) | 1998-04-30 | 2002-08-06 | Enterworks | Workflow management system, method and medium with personal subflows |
JP2000137435A (ja) | 1998-10-29 | 2000-05-16 | Mitsubishi Materials Corp | チームデータリスト管理装置及びチームデータリスト保管装置及びチームデータリスト処理システム、並びに、それらの記録媒体 |
US6937993B1 (en) * | 1998-09-16 | 2005-08-30 | Mci, Inc. | System and method for processing and tracking telecommunications service orders |
US6275863B1 (en) * | 1999-01-25 | 2001-08-14 | International Business Machines Corp. | System and method for programming and executing long running transactions |
EP1155373A1 (en) | 1999-02-17 | 2001-11-21 | BRITISH TELECOMMUNICATIONS public limited company | Creating hypermedia content for a web site |
US6636242B2 (en) * | 1999-08-31 | 2003-10-21 | Accenture Llp | View configurer in a presentation services patterns environment |
US7054823B1 (en) * | 1999-09-10 | 2006-05-30 | Schering Corporation | Clinical trial management system |
US7035808B1 (en) * | 1999-10-20 | 2006-04-25 | Avaya Technology Corp. | Arrangement for resource and work-item selection |
US20020055870A1 (en) * | 2000-06-08 | 2002-05-09 | Thomas Roland R. | System for human capital management |
CA2422322A1 (en) * | 2000-10-03 | 2002-04-11 | Michael Setteducati | Workflow management software overview |
US7076728B2 (en) * | 2000-12-22 | 2006-07-11 | International Business Machines Corporation | Method and apparatus for end-to-end content publishing system using XML with an object dependency graph |
US20020152244A1 (en) * | 2000-12-22 | 2002-10-17 | International Business Machines Corporation | Method and apparatus to dynamically create a customized user interface based on a document type definition |
US20020120493A1 (en) * | 2001-02-23 | 2002-08-29 | Mormile Robert A. | Flexographic platemaker project management and customer interface system |
JP2002288405A (ja) | 2001-03-27 | 2002-10-04 | Ricoh Co Ltd | プロジェクト管理方法、プロジェクト管理サーバ、受付サーバ及びプログラム |
US20030018705A1 (en) * | 2001-03-31 | 2003-01-23 | Mingte Chen | Media-independent communication server |
US7503480B2 (en) * | 2001-07-10 | 2009-03-17 | American Express Travel Related Services Company, Inc. | Method and system for tracking user performance |
US7337124B2 (en) * | 2001-08-29 | 2008-02-26 | International Business Machines Corporation | Method and system for a quality software management process |
US20030097273A1 (en) * | 2001-11-14 | 2003-05-22 | Carpenter Edward D. | System and method for conducting and managing an office move |
US7313798B2 (en) * | 2001-11-15 | 2007-12-25 | Siebel Systems, Inc. | Aggregate drivers for a configurable media-independent server |
US7051036B2 (en) * | 2001-12-03 | 2006-05-23 | Kraft Foods Holdings, Inc. | Computer-implemented system and method for project development |
US7937281B2 (en) * | 2001-12-07 | 2011-05-03 | Accenture Global Services Limited | Accelerated process improvement framework |
US8935297B2 (en) * | 2001-12-10 | 2015-01-13 | Patrick J. Coyne | Method and system for the management of professional services project information |
US6862488B2 (en) * | 2002-07-05 | 2005-03-01 | Validation Commerce, Llc | Automated validation processing and workflow management |
US20040117294A1 (en) * | 2002-07-10 | 2004-06-17 | Plantfind.Com, Inc. | System and methods for facilitating commerce in component-based industries |
JP2004110102A (ja) | 2002-09-13 | 2004-04-08 | Hitachi Ltd | プロジェクト管理方法および工程定義装置 |
WO2004102454A2 (en) | 2003-05-07 | 2004-11-25 | Sap Aktiengesellschaft | An end user oriented workflow approach including structured processing of ad hoc workflows with a collaborative process engine |
JP2004355326A (ja) * | 2003-05-29 | 2004-12-16 | Incs Inc | ソフトウェア開発支援プログラム、当該プログラムを記録した記録媒体及びソフトウェア開発支援システム |
US7644013B2 (en) * | 2003-12-04 | 2010-01-05 | American Express Travel Related Services Company, Inc. | System and method for resource optimization |
US8554599B2 (en) | 2005-03-25 | 2013-10-08 | Microsoft Corporation | Work item rules for a work item tracking system |
US8126760B2 (en) * | 2005-03-25 | 2012-02-28 | Microsoft Corporation | Work item tracking system for projects |
-
2005
- 2005-03-25 US US11/090,692 patent/US8554599B2/en not_active Expired - Fee Related
-
2006
- 2006-02-03 KR KR1020060010682A patent/KR101238573B1/ko active IP Right Grant
- 2006-03-13 CN CNA200610067312XA patent/CN1838165A/zh active Pending
- 2006-03-27 EP EP06006304A patent/EP1705607A1/en not_active Ceased
- 2006-03-27 JP JP2006086542A patent/JP5238138B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US8554599B2 (en) | 2013-10-08 |
KR101238573B1 (ko) | 2013-03-04 |
EP1705607A1 (en) | 2006-09-27 |
KR20060103096A (ko) | 2006-09-28 |
JP2006277745A (ja) | 2006-10-12 |
CN1838165A (zh) | 2006-09-27 |
US20060218030A1 (en) | 2006-09-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5238138B2 (ja) | ワークアイテムトラッキングシステム用のワークアイテムルール | |
US7730446B2 (en) | Software business process model | |
US7577934B2 (en) | Framework for modeling and providing runtime behavior for business software applications | |
US7673282B2 (en) | Enterprise information unification | |
US8682827B2 (en) | Smart containers | |
US7062502B1 (en) | Automated generation of dynamic data entry user interface for relational database management systems | |
CA2504082C (en) | Method and apparatus for generating user interfaces based upon automation with full flexibility | |
US7085752B2 (en) | Customization of metadata describing objects in a computing environment | |
US20160217423A1 (en) | Systems and methods for automatically generating application software | |
US20100005074A1 (en) | System and method for accessing data | |
US20050289524A1 (en) | Systems and methods for software based on business concepts | |
US20030233631A1 (en) | Web services development method | |
CA2673422C (en) | Software for facet classification and information management | |
US20100312592A1 (en) | Confirming enforcement of business rules specified in a data access tier of a multi-tier application | |
US20220188448A1 (en) | System and method for implementing mandatory access control on queries of a self-describing data system | |
King et al. | NHibernate in Action | |
US11971909B2 (en) | Data processing system with manipulation of logical dataset groups | |
Pialorsi | Microsoft SharePoint 2013 Developer Reference | |
CN115222345A (zh) | 一种审核作业方法及装置 | |
US20240256576A1 (en) | Data processing system with manipulation of logical dataset groups | |
US20230222421A1 (en) | System and method for dynamic objects and uses for same, including dynamic case model instances in a case management system | |
US20240146769A1 (en) | Systems and methods for managing privileges in a data processing system | |
Kumar | Documentum 6.5 Content Management Foundations | |
Levinson et al. | Pro Visual Studio 2005 Team System | |
Chang | Generation of policy-rich websites from declarative models |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090220 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090220 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120120 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20120419 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20120424 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120518 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120810 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121112 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130301 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130401 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 5238138 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160405 Year of fee payment: 3 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |