CodeZine(コードジン)

特集ページ一覧

フィールドの規則を使ってTFSの作業項目を高度に作りこむ

Visual Studio Team System 徹底活用(4)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2009/10/02 14:00

目次

利用できるフィールドの規則

 さて、では作業項目定義のフィールドの規則の中身を確認していきましょう。具体的な個別の項目を確認する前にまず、ほとんどのフィールドの規則に持たせることができる共通の属性を確認し、その後に個別の項目を確認していくことにします。

フィールドの規則の共通属性とは

 例えば、次の構文を見てください。

[構文]REQUIRED規則
<REQUIRED [for="適用グループ"] [not="除外グループ"] />

 これは、フィールドが必須入力であることを示す規則をxml構文で示したものです。ここにfor属性およびnot属性が省略可能属性として定義されています。このfor属性とnot属性はほとんどのフィールドの規則に適用することができる属性で、フィールドの規則が適用されるグループ(for属性)と規則が適用されないグループ(not属性)を指定するために用意されています。例えば、プロジェクトマネージャが更新権限を持っていて、それ以外のユーザーは確認のみというような項目は割と見受けられると思います。これは、プロジェクトマネージャのグループがManagerだったとすると次のリスト4のように定義することができます。

[リスト4]規則適用グループの制限
<FIELD name="計画値" refname="Jp.CodeZine.WIT04.Actual" type="Integer">
  <READONLY not="[Project]\Manager" />
</FIELD>

 この例では、チームプロジェクトに定義されているManagerグループを規則の除外グループとして設定しています。ここで「[Project]」というキーワードは作業項目が属しているチームプロジェクトを示すキーワードです。他にTFS全体に定義されていることを示す「[GLOBAL]」というキーワードもあります。また、for属性もnot属性もそれぞれ1グループのみ指定可能であるため、規則を適用するのか除外するのか、どのようなグループに対してそれを行うのかはよく検討しておく必要があります。また、チームプロジェクトのグループ名を利用する場合は、そのグループが定義済みでないと設定がうまく反映されなくなるため、合わせて注意が必要です。

チームプロジェクトのグループ定義

 作業項目定義を検討する場合、TFSのプロセステンプレートの検討の一環として検討することもあると思います。プロセステンプレートはチームプロジェクトのひな型になる定義情報ですので、作業項目定義に必要なグループ名をあらかじめ登録しておくことも可能です。この場合は、チームプロジェクトのグループ情報を定義しているファイルが、プロセステンプレートのルートフォルダ内にある「Groups and Permissions」フォルダ内の「GroupsandPermissions.xml」ファイルとして用意されているため、このファイルを編集することで、必要なグループをあらかじめ定義しておくことが可能です。この方法については本稿の範疇を超えるため解説しませんが、興味がある場合は、同ファイルおよびMSDNライブラリの「GSSスキーマ」をご覧ください。

 ここからはいよいよフィールドの規則として利用可能な一覧と簡単な用途について確認していきます。

REQUIRED規則

 フィールドが必須入力であることを示す規則です。この規則のxml構文は次のようになります。角カッコで囲んだ属性は省略可能であることを表します(以下、すべて同様)。

[構文]REQUIRED規則
<REQUIRED [for="適用グループ"] [not="除外グループ"] />

 この規則を適用されたフィールドが未入力の場合、作業項目を保存することができません。作業項目の運用を考えた場合に必ず入力しておいてほしい項目に適用しておくといいでしょう。この規則を常に適用する、ある状態の時のみ適用するなど、この規則は先に示した適用場所のどの場所で利用しても効果を発揮できます。

READONLY規則

 フィールドが読み取り専用であることを示す規則です。この規則のxml構文は次のようになります。

[構文]READONLY規則
<READONLY [for="適用グループ"] [not="除外グループ"] />

 この規則が適用されているフィールドは編集することができなくなります。一見すると編集できないフィールドの存在意義には疑問が残ります。しかし、前述のfor属性、not属性と組み合わせて使うとあるグループだけ適用する、除外するということができるため、マネージャグループは編集可、それ以外は編集不可という設定が可能です。また、状態定義のフィールド規則として適用すれば、ある状態の時だけ編集できないようにするといったことも可能です。例えば、計画段階では予定値の入力を許可するが、一度その作業が開始した後(状態が遷移した後)は編集不可にするといった利用方法になるでしょう。

EMPTY規則

 フィールドの値がクリアされることを示す規則です。この規則のxml構文は次のようになります。

[構文]EMPTY規則
<EMPTY [for="適用グループ"] [not="除外グループ"] />

 この規則は主に状態遷移定義のフィールド規則で使用される規則です。フィールド定義や状態定義のフィールド規則として適用してしまうとREADONLY規則とほとんど同様の効果をもたらしてしまいます。READONLYと異なるのは、状態遷移定義の中でこの規則を利用した場合、対象フィールドの値がクリアされる点です。作業項目には通常、状態ごとにその状態にした利用者、およびその日時を記録するフィールドが用意されています。このフィールドを対象の状態になるときに一度クリアする(状態遷移のフィールド規則として適用する)という用途が大多数になります。for属性、not属性と組み合わせることでこれ以外の用途も考えていくことは可能ですが、適用される範囲、運用方法がややこしくなるため、あまりお奨めはしません。

FROZEN規則

 作業項目が保存された後、フィールドの値を変更不可にすることを示す規則です。この規則のxml構文は次のようになります。

[構文]FROZEN規則
<FROZEN [for="適用グループ"] [not="除外グループ"] />

 この規則を利用した場合、一度フィールドの値を入力して保存した後は以降の変更が不可になります。例えば、作業項目を新規作成して、計画値を入力して保存します。その後、その値を変更できないようにしたい場合に適用しておきます。この規則では例えばnot属性を利用して、マネージャグループであればいつでも変更できるようにしておくということも可能です。また、作業項目に「再計画」という状態を用意しておいて、その状態に遷移するときにフィールドに対してEMPTY規則を適用しておくと、再度変更ができる状態に戻すことも可能です。FROZEN規則を利用する場合は、このように再編集可能にするルートを検討しておくことも重要な要素となります。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:Visual Studio Team System 徹底活用

著者プロフィール

  • 山田 祥寛(ヤマダ ヨシヒロ)

    静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XM...

  • WINGSプロジェクト りばてぃ(リバティ)

    <WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5