CN1838165A

CN1838165A - 工作项跟踪***的工作项规则

Info

Publication number: CN1838165A
Application number: CNA200610067312XA
Authority: CN
Inventors: A·I·贝尔; A·D·高希; M·A·菲利普; T·塔留斯
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-03-25
Filing date: 2006-03-13
Publication date: 2006-09-27
Also published as: EP1705607A1; JP5238138B2; KR101238573B1; US20060218030A1; KR20060103096A; JP2006277745A; US8554599B2

Abstract

提供工作项跟踪***的工作项规则。工作项规则可通过多个软件实体访问、使用并由其诠释。此外，可配置工作项规则，使之能通过用户来创建和修改，例如，以通过用户界面向用户曝露的方式。工作项规则可指定可标识抽象的标识符和/或名称，并可指定或指示条件以及当该条件被满足的情况下要采取的行动。响应于影响第一工作项规则的第一用户动作，可确定对应于第一用户和/或第一工作项的一个或多个工作项规则。随即可诠释一个或多个工作项规则，并可基于该诠释来响应该用户动作。

Description

工作项跟踪***的工作项规则

背景技术

在如今的工商界内，特别是软件开发环境中，常常使用工作项跟踪***。工作项跟踪***通常使用户能够定义一个或多个表示工作单元的工作项，并通过更新这些表示工作单元的工作项来跟踪工作单元的进度。工作单元可以是各种类型中的任何类型，包括但不限于：要由一个或多个人执行的任务；诸如故障修理(即，软件缺陷的修正)或软件应用程序的改进/添加等软件相关的工作项；项目；另一类型的工作项；或以上的任意组合。如本文中所使用，“工作项”是表示和定义工作单元的软件抽象(例如，对象、类、记录、数组、其它类型的抽象、或以上的适当的组合)。“工作项跟踪***”或“WITS”是通过允许工作项的手动的(由用户)以及可能自动的(由***响应于***上的其它事件)创建和修改来实现对工作单元的跟踪的***。

对一些工作项跟踪***进行硬性编码以向不同的用户提供不同的访问特权和/或使不同的用户能够对工作项执行不同的动作。例如，可允许第一软件开发者(例如，来自第一开发团队)访问和修改第一工作项，可允许第二软件开发者(例如，来自第二开发团队)访问但不得修改(例如，只读)第一工作项，而可完全拒绝第三软件开发者(例如，来自第三开发团队)访问第一工作项目。这些访问和修改“规则”不是可个别标识的、离散的软件实体，相反，把它们的定义和功能嵌入在控制对工作项目的访问和操纵的代码内(即，对它们进行硬性编码)。因此，它们不是不费力就可使用的(即，可重复使用的)，并且易被其它实体(即，程序和应用程序)作出其它诠释。

此外，这些规则是不向用户开放(曝露)的，从而它们不会受到用户的创建或改变。必须由程序员来改变代码。随着时间过去，公司的雇员、公司结构、业务目标、产品及公司的其它方面将会改变。响应于此类改变，可能要求改变工作项目的访问和修改规则(例如，添加、删除和/或修改一个或多个规则)。但是，如上所述，必须由程序员进行这一改变。因此，管理员(或其它想要进行改变的人)不能自己进行改变，而是必须向程序员解释所需的修改。此外，管理员不能容易地看到(除了以代码形式以外)程序员对代码所进行的实际改变，而是只能体验这些改变的结果。如果改变没有产生预期的效果，则管理员必须回到程序员那里并解释该问题，并且再重复该过程。要求管理员和程序员之间的互动来实现对访问和/或修改规则的改变的这一过程对公司资源的利用是效率低下的。

发明内容

本文中所描述的是在工作项跟踪***中使用的工作项规则。如本文中所使用，“工作项规则”或“WIR”是可标识的、离散的软件抽象(例如，对象、类、记录、数组、其它类型的抽象、或以上的适当的组合)，它定义了至少在某种程度上调控将会影响工作项的动作的规则。工作项可被多个软件实体访问、使用并由其诠释。此外，可把工作项规则配置成由用户(即，不仅是程序员)来创建和修改，例如，以通过用户界面(例如，XML编辑器或GUI)向用户曝露的方式。因此，可使用户能够创建和修改控制对工作项的访问和/或修改的商务规则抽象。

工作项规则可指定可标识抽象的标识符和/或名称，并可指定或指示条件以及在满足该条件的情况下要采取的行动。这一条件可对应于以下任何一个：一个或一组用户；工作项的内容(例如，字段、工作流程、转移、状态等)；工作项的一个或多个属性(例如，类型或其它元数据)；公司产品或其方面，涉及工作项的其它信息；或以上的任何适当的组合。

在一些实施例中，提供了使经授权的用户(例如，管理员)能够创建和/或修改工作项规则的用户界面(例如，XML编辑器或GUI)。

在本发明的一些实施例中，工作项跟踪***可用逻辑分层结构(例如，用树状排列)来组织工作项规则。工作项的逻辑分层结构的组织可对应于诸如公司产品或公司结构等另一实体的组织结构。在分层结构内的工作项之间可定义关系。例如，分层结构的第二级上的工作项可能与分层结构的第一级上的一个或多个工作项有父关系。因此，为第二级上的工作项定义的工作项规则可覆盖为第一级上的工作项中的一个定义的工作项规则。在一些实施例中，不管逻辑分层结构内的位置，导致否定确定的工作项规则将总是覆盖掉导致肯定确定的另一工作项规则。

在本发明的一些实施例中，响应于影响第一工作项规则的第一用户动作，可确定对应于第一用户和/或第一工作项的一个或多个工作项规则。随即可诠释这一个或多个工作项规则，并可基于该诠释来响应该用户动作。

在本发明的一些实施例中，可用多层方式来强制执行工作项规则。例如，可把工作项跟踪***分布在多个层上，其中至少包括客户机工作项规则引擎和服务器工作项规则引擎。客户机工作项规则引擎可提供使用户能够访问和/或修改工作项的用户界面。响应于用户访问或修改工作项，客户机工作项规则引擎可诠释一个或多个对应的工作项规则，其后服务器工作项规则引擎可能以不同的方式(例如，由于它可能有更为近期的数据任其使用这一事实)诠释相同或相近的一个或多个工作项规则。

如将从以下讨论变得清楚，工作项规则扩展了已知的工作项跟踪***的灵活性，因为在没有程序员协助的情况下，可相对容易地修改工作项规则以适应商务实体的改变商务需求。此外，下述的用于实现工作项规则的***和方法实现了安全性的细粒集成并维护工作项内容的完整性。

在本发明的一个实施例中，调控影响工作项跟踪***的一个或多个工作项的用户动作。响应于影响工作项跟踪***的第一工作项的第一用户动作，确定对应于第一用户和/或第一工作项的一个或多个工作项规则。诠释一个或多个被确定的工作项规则，并且基于对工作项规则的诠释来响应第一用户动作。

在此实施例的一个方面，一个或多个被确定的工作项规则中至少有一个对应于第一用户或该第一用户所属的用户组，并且诠释包括诠释至少一个被确定的工作项规则。

在此实施例的另一个方面，一个或多个被确定的工作项规则中至少有一个对应于工作项的内容，并且诠释包括诠释至少一个被确定的工作项规则。

在此实施例的另一个方面，一个或多个被确定的工作项规则中至少有一个对应于工作项的一个或多个属性，并且诠释包括诠释至少一个被确定的工作项规则。

在此实施例的另一个方面，一个或多个被确定的工作项规则中至少有一个对应于产品的至少一个方面，并且诠释包括诠释至少一个被确定的工作项规则。

在此实施例的又一个方面，提供了使用户能够定义一个或多个工作项规则的用户界面。

在此实施例的另一个方面，工作项跟踪***包括按逻辑分层结构组织的多个工作项规则、包括一个或多个工作项的多个工作项。第一工作项对应于分层结构的第一级，而第二工作项对应于分层结构中优先于第一级的第二级。确定还包括确定对应于第一工作项的第一工作项规则并确定对应于第二工作项的第二工作项规则，而诠释包括诠释第一和第二工作项规则，并至少部分地基于分层结构中优先于第一级的第二级，用对第二工作项规则的诠释覆盖掉对第一工作项规则的诠释。

在此实施例的另一个方面，至少在第一网络元素和由一个或多个通信介质连接到第一网络元素的第二网络元素上分布工作项跟踪***。第一网络元素包括第一模块，而第二网络元素包括第二模块。第一模块从用户接收指定影响第一工作项的用户动作的输入。确定、诠释和响应由第一模块执行。第二模块诠释一个或多个被确定的工作项规则。

在本发明的另一个实施例中，提供了一种计算机程序产品。该产品包括计算机可读介质以及存储在该计算机可读介质上的定义了指令的计算机可读信号，当计算机执行这些指令时，它们命令计算机执行在前面数段中所描述的本发明的实施例的方法和/或在前面数段中描述的该实施例的一个或多个方面。这些计算机可读信号可根据标记语言来定义其中一个或多个指令。

在本发明的另一个实施例中，提供了一种用于调控影响工作项跟踪***的一个或多个工作项的用户动作的***。该***包括第一工作项规则引擎，它响应于影响工作项跟踪***的第一工作项的第一用户动作，确定对应于第一用户和/或第一工作项的一个或多个工作项规则，诠释这一个或多个被确定的工作项规则，并基于该诠释来响应该用户动作。

在此实施例的一个方面，一个或多个被确定的工作项规则中至少有一个对应于第一用户或该第一用户所属的用户组。可操作第一工作项规则引擎来诠释至少一个被确定的工作项规则。

在此实施例的另一个方面，一个或多个被确定的工作项规则中至少有一个对应于工作项的内容，并且可操作第一工作项规则引擎来诠释至少一个被确定的工作项规则。

在此实施例的另一个方面，一个或多个被确定的工作项规则中至少有一个对应于工作项的一个或多个属性，且可操作第一工作项规则引擎来诠释至少一个被确定的工作项规则。

在此实施例的又一个方面，一个或多个被确定的工作项规则中至少有一个对应于产品的至少一个方面，且可操作第一工作项规则引擎来诠释至少一个被确定的工作项规则。

在此实施例的另一个方面，提供了使用户能够定义一个或多个工作项规则的用户界面。

在此实施例的另一个方面，工作项跟踪***包括按逻辑分层结构组织的多个工作项规则、包括一个或多个工作项的多个工作项。第一工作项对应于分层结构的第一级，而第二工作项对应于分层结构中优先于第一级的第二级。可操作第一工作项规则引擎来于确定对应于第一工作项的第一工作项规则，并确定对应于第二工作项的第二工作项规则。可操作第一工作项规则引擎来诠释第一和第二工作项规则，并至少部分地基于对分层结构中优先于第一级的第二级而控制用对第二工作项规则的诠释来覆盖对第一工作项规则的诠释。

在此实施例的另一个方面，第一工作项规则引擎驻留在第一网络元素上，且可操作第一工作项规则引擎以从用户接收指定第一用户动作的输入。该***还包括第二工作项规则引擎，它驻留在由一个或多个通信介质连接到第一网络元素的第二网络元素上，可操作第二工作项规则引擎以和第一模块应用于一个或多个被确定的工作项规则不同的方式诠释一个或多个被确定的工作项规则。

当结合附图考虑以下本发明的具体说明(包括本发明的诸方面和实施例)时，本发明的其它优点、新颖特征和目的，以及本发明的诸方面和实施例将变得显而易见，其中附图仅仅是示意性的而并不旨在按比例绘制。在附图中，以单个标号表示不同的图中所示出的每个完全相同或几乎完全相同的组件。为清楚起见，并没有在每个图中都标记每一个组件，而在无须说明即可允许本领域普通技术人员理解本发明之处，也没有示出本发明的每个实施例或方面的每一个组件。

附图说明

图1是根据本发明的一些实施例的框图，示出一种为工作项跟踪***实现工作项规则的***示例；

图2根据本发明的一些实施例示出工作项类型定义的示例；

图3根据本发明的一些实施例示出工作项类型定义的字段部分的示例；

图4根据本发明的一些实施例示出工作项类型定义的工作流程部分的示例；

图5是根据本发明的一些实施例的转移规则的示例；

图6是根据本发明的一些实施例的屏幕摄影，示出可向用户提供以使用户能够选择产品树的节点的用户界面显示示例屏幕摄影；

图7是根据本发明的一些实施例的屏幕摄影，示出使用户能够指定一个或多个基于安全的工作项规则的用户界面显示示例屏幕摄影；

图8是根据本发明的一些实施例的屏幕摄影，示出使用户能够指定一个或多个基于安全的工作项规则的用户界面显示示例屏幕摄影；

图9是根据本发明的一些实施例的屏幕摄影，示出用于创建和/或修改工作项的用户界面显示示例屏幕摄影；

图10是根据本发明的一些实施例的流程图，示出用于在工作项跟踪***中实现工作项规则的方法示例；

图11是示出可在其上实现本发明的一些实施例的计算机***示例的框图；以及

图12是示出可作为计算机***的一部分使用来实现本发明的一些实施例的存储***示例的框图。

具体实施方式

可根据可从Microsoft公司获得的微软团队***(Microsoft Team System)技术和/或微软团队基础(Microsoft Team Foundation)技术来实现本发明的一些实施例，这些技术在此申请提交日在以下几处描述：http：//lab.msdn.microsoft.com/teamsystem/和 http：//blogs.msdn.com/team_foundation/，特此结合其全部内容作为参考。此外，可根据由可从Microsoft公司获得的MicrosoftVisual Studio(MVS)的数个版本提供的工作项跟踪***和工作项规则技术来实现本发明的一些实施例，其部分内容在附录I-III更加详细地描述。题为Design Document；Business Rules Description and Use(设计文档；商务规则的描述和使用)的附录I描述了商务规则的一个实施例以及可如何使用这些商务规则。题为Work Item Type Definition Language(工作项类型定义语言)的附录II描述了工作项类型定义语言的一个实施例。题为Work Item Type Rules-Customer Scenarios(工作项类型规则-顾客情形)的附录III描述了可使用工作项类型规则的情形的示例。特此结合附录I-III的所有内容作为参考。应当认识到，微软团队***和团队基础技术、MVS技术以及附录I-III中所描述的技术纯粹是可被用来实现本发明的实施例的技术的示例，而并不试图限制本发明的范围。例如，可使用以上技术的变体等其它技术，并且旨在使其落入本发明的范围之内。

将可从下述示例更充分地理解本发明的这些及其它实施例的功能和优点。旨在使以下示例便于更好地理解，并说明了本发明的益处，但并没有例示本发明的完整范围。

如本文中所使用，无论是在书面描述还是在所附的权利要求书中，应理解术语“包含”、“包括”、“带有”、“具有”、“含有”、“涉及”等是开放式的，即意味着包括而非限制。只有过渡语“由……组成”和“本质上由……组成”才应分别是封闭或半封闭的过渡语，如专利审查过程的美国专利局手册(第八版，修订2，2004年5月)第2111.03节中就权利要求书所阐述。

示例

图1是示出为工作项跟踪***(WITS)实现工作项规则(WIR)的***100的示例的框图。***100纯粹是为工作项跟踪***实现工作项规则的***的示例性实施例，而并不试图限制本发明的范围。例如***100的变体这样的***的许多其它实现中的任何实现都是可能的，并且旨在使其落入本发明的范围之内。例如，示出图100中所示主要涉及WIR的一些元素为或多或少地集成在WITS元素之内。但是，WIR元素实际上可以是从WITS元素脱离和离散的元素。

***100可包括：一个或多个WITS客户机(例如，WITS客户机102、104和106)；一个或多个WITS服务器(例如，WITS服务器120)；一个或多个数据源(例如，数据源126)，其中每一个数据源可以是例如数据库(例如，面向对象型数据库、关系型数据库、文件***、另一种类型的数据库或以上任意的组合)等各种类型的数据源中任何类型的数据源；网络118，其它网络元素，或以上的任意组合。

如本文中所使用，“网络”是指由一段或数段传输介质相互连接的两个或多个网络元素的一个组，可在这些传输介质上交换元素之间的通信。每个段可以是多种类型的传输介质中任何类型的传输介质，包括用金属和/或光纤制成的一条或多条电线/缆或光缆、空气(例如，使用载波上的无线传输)或是这些传输介质的任意组合。如本文中所使用，“多个”是指两个或以上。应当认识到，网络可以简单到是由单线、总线、无线连接或其它类型的段连接的两个网络元素。此外，应当认识到，当在本文的附图中所示出的网络为连接到该图中一元素时，考虑该被连接的元素本身也是该网络的一部分。

每个WITS客户机102、104和106可以是诸如用户设备等多种类型的设备中任何类型的设备。用户设备包括，但不限于：工作站；个人计算机(例如，PC)；膝上计算机，笔记本计算机；电话(例如，陆线或移动)；寻呼机；Blackberry^TM牌的设备，PCS设备，个人数字助理(PDA)，双向无线电(例如，“步话机”)，其它类型的用户设备，以及以上的任何适当的组合。

WITS客户机(例如，WITS客户机106)可包括以下任何部分：工作项类型界面(WIT IF)108；工作项界面100；安全界面112；客户机工作项规则(SIR)引擎114和WIR高速缓存116。

WIT界面108可以是使用户能够创建和/或修改工作项类型定义的用户界面，例如，如附录II中所描述。如本文中所使用，“用户界面”是一应用程序或应用程序的一个部分(即，计算机可读指令集)，它使用户能够在应用程序执行期间与该应用程序交互。用户界面可包括代码，该代码定义在应用程序执行期间该应用程序如何向用户输出信息，例如，通过计算机屏幕或其它装置视觉地输出，通过扬声器或其它装置可听地输出，以及通过游戏控制器或其它装置手动地输出。此类用户界面还可包括代码，该代码定义在应用程序执行期间用户可如何输入信息，例如，使用话筒可听地输入，或使用键盘、鼠标、游戏控制器、轨迹球、触摸屏或其它装置手动地输入。

用户界面可定义如何向用户视觉地提供(即，显示)信息，并定义用户能如何导航信息的视觉呈现(即，显示)，并在视觉呈现的环境中输入信息。在应用程序执行期间，用户界面可控制信息的视觉呈现，并且使用户能够导航该视觉呈现并在该视觉呈现的环境中输入信息。用户界面类型的范围从命令驱动的界面(其中用户输入命令)、菜单驱动的界面(其中用户从菜单选择信息)及其组合到GUI(与命令驱动和菜单驱动的视觉用户界面相比，它通常更好地利用计算机的图形能力，更灵活、直观和容易导航，并且具有更有吸引力的“外观和感觉”(look-and-feel))。如本文中所使用，分别把由用户界面或GUI提供的信息的视觉呈现称为“用户界面显示”或“GUI显示”。

WIT界面108可使用户能够手动地创作XML文件，或可提供更加复杂的用户界面(例如，GUI)以使用户能够定义工作项类型。

暂时离开图1，图2示出按可扩展标记语言(XML)格式的工作项类型定义200的示例。定义200纯粹是工作项类型定义的示例性实施例，而并不试图限制本发明的范围。例如定义200的变体这样的定义的许多其它实现中的任何实现都是可能的，并且旨在使其落入本发明的范围之内。例如，尽管定义200是以XML形式编写的，但是可使用其它各种合适的格式中的任何格式。

定义200可定义诸如故障、特征、要求或任务等各种类型的工作项目中任何类型的工作项目，并可包括以下的任何一个：名称字段202；描述部分206；字段部分210；工作流程部分212；表单部分214；其它部分和字段；或以上的任何适当的组合。

可配置名称字段202以致使被指定的值在一团队项目(在以下更加详细地描述)内是唯一的。示例性名称可包括：bug(故障)、feature(特征)、requirement(要求)、task(任务)及其它名称。

描述字段206可指定在运行时当需要工作项目类型的概览时可使用的帮助文本。例如，在图2中，描述字段206指定“bug work item types are used to track defectswithin a code”(使用故障工作项目类型来跟踪代码内的缺陷)。

表单部分214可指定将如何显示和由终端用户操纵相关字段。

字段部分210指定工作项类型的相关字段集。在一些实施例中，每个工作项类型都可包含工作项跟踪***正确地操作所需的核心字段集。可为特定工作项类型自定义其它字段。在一些实施例中，除了核心的必需字段以外，必须首先在字段部分210中声明在工作项类型定义中的其它地方(例如，在表单部分214或工作流程部分212中)被引用的每个字段。字段可具有以下信息：名称、引用名称、类型、帮助文本、以及动作或约束集。对于此工作项类型的所有实例(例如，工作项)，明确地列出的非核心字段可以暗示是空的，并且是只读的。

在一些实施例中，可把字段规则的范围界定到一个特定用户或一组用户。可添加属性“for”和“not”来支持这一范围界定。可在标记上使用这些属性以使它们专属于特定组或专属于除特定组以外的所有人。指定“禁止”的这种字段规则的优先权可高于指定“准许”的规则。(如将在以下更加详细地讨论，并如附录II中所说明，工作项类型定义内的许多规则可指定一个或多个用户、一组用户、一个域的用户、所有用户等等。)

图3示出工作项类型定义的字段部分300的示例，它定义范围被界定到用户组的字段规则。图3的字段部分300指定名为“title”(标题)(302)的字段是向除[Project]\Testers的成员以外的所有人提供访问的只读字段。如果用“for”代替字段304中的“not”，则该规则将指定Title字段是可供相同成员访问、但不可供其它任何人访问的只读字段。

图4是工作项类型定义的工作流程部分400的示例。工作流程部分可描述有效状态、合法转移以及这些转移的合法原因。原因可标识用户为何从一个状态改为另一个状态。在一些实施例中，有一个且仅有一个转移可定义从无(即，“”)到名称状态的转移，由此标识了新工作项的初始状态。此外，每个转移可在默认原因字段420内定义一个且仅一个默认原因。工作项的最小工作流程可包括仅一个状态，一个转移和一个默认原因。

工作流程部分400可包括定义一个或多个可允许状态404和406的状态部分402、以及定义工作项类型的一个或多个可允许的转移的转移部分408。在转移部分408内，可以定义诸如转移410和416等一个或多个转移。转移410定义了从无到“active”(活动)的初始转移，其中原因部分412仅包括指示默认原因是当该值为new(新建)时的默认原因414。转移416指定从“Active”到“Complete”(完成)的转移。转移416包括在原因部分418内的原因420和422。原因420是“deferred”(被推迟的)默认原因，而原因422指定原因“no plans to fix”(没有修理的计划)。

在一些实施例中，必须指定两个状态之间所有合法的转移，且如果没有指定任何转移，则默认不允许执行此转移。此外，在工作流程的转移部分可任选地使用两个属性“for”和“not”来推敲允许哪个用户执行转移。“禁止”的优先权可高于“允许”。如果没有指定这些属性中的任何一个，则可允许任何人都进行这一转移(特别是能够修改工作项的任何人)。

图5是转移规则500的示例。这一转移规则限制除new testers(新测试员)(例如，刚刚加入团队的测试员)以外的所有项目测试员从“resolved”(解决)到“complete”的转移。转移规则还可指定单个用户身份。

在附录II中更加详细地描述包括字段部分、字段规则、工作流程部分、转移和转移规则在内的工作项类型定义的其它示例。

工作项跟踪***的诸方面能以逻辑分层结构(例如，以树状排列)来组织。逻辑分层结构的组织可对应于诸如公司产品或公司结构等另一实体的组织结构。逻辑分层结构可包括多个等级，其中最高等级是分层结构的根(例如，树干)。分层结构的根可在次最高等级处有一个或多个子节点，且次最高等级处的这些子节点中的每一个都可在下一个次最高等级处有一个或多个子节点。

回到图1，可以配置可使用户能够如图2-5所示地输入工作项类型定义的WIT界面108，以致它使用户能够为逻辑分层结构的特定节点(例如，根节点、或较低等级的任何节点)定义工作项类型。因此，从特定工作项类型创建(即，实例化)的工作项可具有与工作项类型本身相同的范围，且该范围对应于为其定义该类型的节点。即，可把工作项类型定义及它们所包括的规则的范围界定到工作项跟踪***的逻辑分层结构的一个特定节点。下面更详细地描述的图6示出这种逻辑分层结构(特别是，产品树602)的一个例子。

安全界面112可以提供用户界面，该界面使用户能够指定一个或多个基于安全的工作项规则，并且可以使用户能把这些规则的范围界定到逻辑分层结构(例如，产品树)产品树中的一个节点。可独立于任何特定工作项类型地定义这些规则。应该认识到，WIT界面108还允许定义与安全相关的规则，但是是在工作项类型的范围内定义的。图6是示出可向用户提供以使用户能够选择产品树的节点的用户界面显示600的示例的屏幕摄影。在一些工作项跟踪***中，产品树可在第一(即，最高)级处有一根节点，它可对应于整个产品和/或MVS“解决方案”。该产品树的第二级的每个节点可对应于该产品和/或解决方案内的一个项目，而项目节点的每个子节点可对应于其父项目的子组件(例如，产品特征或产品的其它方面)。

树部分602可表示产品树的第二级处的一个项目，它以题为“Project ModelHierarchy”(项目模型分层结构)的项目节点604为首，并有两个子节点606(“node1”(节点1))和节点608(“node 2”)。节点606包括两个子节点610(“Node1_Child1”(节点1_子1))和节点612(“Node1_Child2”(节点1_子2))。配置显示600使用户能够导航树部分602(可能还有该树的其余部分)并选择其中一个节点，例如，节点606。为了定义基于安全的工作项规则，在选择分层结构602的一个节点(例如，节点606)以后，可配置permissions(允许)键614使用户能够表示该用户的意向而定义一个或多个基于安全的规则。响应于用户选择了permissions按钮614，可显示图7的显示700。

图7是示出使用户能够指定一个或多个基于安全的工作项规则的用户界面显示700的示例的屏幕摄影。显示700可包括以下任何部分：用户和组选择窗口702；用户和组添加面板704；允许窗口707；其它组件；及其任何适当的组合。

选择窗口702可使用户能够选择要为其定义基于安全的工作项规则的一个用户和/或一组用户。例如，在显示700中，已选择了用户“REDMOND\amitgh”。

可配置添加面板704，使用户能够搜索和选择要向选择窗口702中添加的一个和/或一组用户，以致可为基于安全的规则而选择他们。在一些实施例中，可使面板704能够搜索用户和组的一个或多个源，诸如Windows User or groups(Windows用户或组)和/或Team Foundation Server Group or users(团队基础服务器组或用户)。

允许窗口706使用户能够为在窗口702中选择的用户或组指定一个或多个基于安全的工作项规则。例如，可使用户能够指定是允许还是禁止用户或组的特定动作。例如，如窗口706中所示，可使用户能够指定允许或禁止一用户或组(尤其)：edit work items in the currently selected node(编辑当前所选择的节点中的工作项)；和/或view work items in the currently selected node(查看当前所选择的节点中的工作项)等等。还可配置允许窗口706，使用户能够定义不一定涉及工作项规则的允许，诸如允许用户编辑所选择的节点(708)本身。

图8是示出使用户能够指定一个或多个基于安全的工作项规则的用户界面显示700’的示例的屏幕摄影。显示700’可包括以下任何部分：用户和组选择窗口702；用户和组添加面板704；允许窗口707；其它组件；以及以上的任何适当的组合。除了用户在显示700’的窗口806中指定了更多的允许以外，显示700’基本与显示700相同。特别地，用户指定了不允许(即，拒绝)在窗口702中所选择的用户(“REDMOND\amitgh”)编辑此节点中的工作项(809)，但允许其查看此节点中的工作项(811)。

尽管已经参考了独立于工作项类型来定义基于安全的工作项规则而描述了显示600，但是它或类似的显示可起到入口点的作用，用户可为其选择一个节点为之定义一个或多个工作项类型。即，显示600或类似的显示可起到导航工具的作用，使用此工具可指定产品树上节点，为其界定一个或多个工作项类型规则的范围。

由此，如上所述，可配置WIT界面108使用户能够定义一个或多个工作项规则，这些规则的范围被界定到特殊工作项类型，可把它们的范围界定到诸如产品树等逻辑分层结构的特定节点。同样，可配置安全界面112，使用户能够独立于任何特定工作项类型来定义基于安全的(即，专属于一个或一组用户的)一个或多个工作项规则，可把它们的范围界定到诸如产品树等逻辑分层结构的特定节点。可响应于影响工作项的用户动作(例如，访问和/或修改工作项)而强制执行这两种类型的规则。现在将要描述的工作项界面110可使用户能够采取影响工作项的用户动作。

图9是示出用于创建和/或修改工作项的用户界面显示900的示例的屏幕摄影。显示900纯粹是用于访问和/或修改工作项规则的用户界面显示的示例，而并不试图限制本发明的范围。可使用诸如显示900的变体等各种其它显示中的任何显示，并且旨在使它们落入本发明的范围之内。

显示900可示出正在创建的“bug”(故障)的工作项类型的示例。该工作项可具有如文件夹选项卡902所示的名称“new bug”(新故障)。此外，可分别如分配字段904、优先权字段906、状态字段908和原因字段910所指示地把该工作项分配给用户“amitgh”，具有优先权“2”，并因其为“new”(新的)而处于“active”(活动的)状态。用户可在描述窗口914输入描述“test edit”(测试编辑)，并指示保存该工作项。但是，因为用户尚未在标题字段912中输入标题，所以可在出错消息窗口916中向用户显示出错消息(例如“Save field.The value for field‘title’must NOT be emptied.”(保存字段。‘标题’字段的值不可为空。))。响应于用户在未在字段912中输入值的情况下试图保存工作项“new bug”而显示这一出错消息可能是客户机WIR引擎114(如将在以下更加详细描述)强制执行一个或多个工作项规则的结果。例如，工作项类型规则可指定对于用户“amitgh”、此用户所属的组或所有用户的标题字段912需要一个值，如以上参考图2-5所描述。

回到图1，可配置客户机WIR引擎114以响应于影响工作项的用户动作而强制执行工作项规则(包括工作项类型规则和/或基于安全的规则)。例如，可配置引擎114来确定对应于受影响的工作项的一个或多个工作项规则，诠释一个或多个被确定的工作项规则，并基于该诠释来响应该用户动作。

确定对应于受影响的工作项的一个或多个工作项规则包括标识对应于以下各项的所有工作项规则：访问和/或修改该工作项的用户；逻辑分层结构(例如，产品树)中该工作项所对应的节点；以及该工作项的工作项类型。可把这些规则存储在WIR高速缓存116中，它可高速缓存与***100相关联的所有工作项规则。WIR高速缓存116的源可以是数据源126的WIR消息130。可把通过工作项界面(例如，界面108)、安全界面(例如，112)或通过***100的WITS客户机上的其它手段定义的工作项规则存储在诸如数据源126(例如，如WIR信息130)等一个或多个集中的位置中。可把这些WIR规则高速缓存在一个或多个如此的WITS客户机上。

诠释被确定的一个或多个工作项规则可包括以某种方式组合被确定的规则。例如，参考显示600的树部分602，可定义基于安全的规则和工作项类型规则，并因此而将其范围界定在树部分602的各个等级处，包括节点604、606、608、610和/或612处。将用户身份、节点和工作项类型用作输入的客户机WIR引擎114可基于这些输入(可能还有其它信息)来对所有被确定的规则评估，并基于这一评估来确定是允许该用户动作还是禁止该用户动作的至少某个部分。

能以各种方式中的任何方式来执行对规则的评估或诠释。例如，在一些实施例中，为逻辑分层结构的给定节点(例如，树节点)定义的规则的优先权高于为该逻辑分层结构中较低的节点定义的冲突的规则。在一些实施例中，对于适用于特定用户动作的多个规则，仅须将一个规则诠释为否定的(例如，禁止的动作)即可禁止该用户动作，而不管有多少个规则被诠释为肯定的(例如，允许的动作)或是被诠释为肯定的规则在逻辑分层结构中高于被诠释为否定的规则这样的事实。

例如，参考产品树部分602考虑以下情形：

1.用户1是A组的成员；

2.第一基于安全的规则指定允许A组的用户编辑项目节点604的工作项；

3.第二安全规则指定不允许(即，禁止)用户1编辑节点606的工作项；

4.在项目节点604的节点606下，用户1试图保存对“bug”类型的第一工作项的优先权字段的值的修改。

对于这一情形，假定第一和第二基于安全的规则是由客户机WIR引擎114所确定的。如果因为第一安全规则在节点树中的位置而给予其高于第二基于安全的规则的优先权，则第一和第二基于安全的规则之间的冲突将通过第一安全规则覆盖掉第二安全规则来解决。由此，将允许用户1修改每第一安全规则的优先权字段的值。或者，如果配置引擎114，使无论任何禁止在节点树内的位置如何都覆盖掉准许，则将应用第二基于安全的规则。由此，将不允许用户1修改优先权字段，因为不允许该用户编辑每第二基于安全的规则的节点606的工作项。

考虑第二情形，其中不存在第二基于安全的规则，但是工作项类型规则指定对于节点606中“bug”类型的工作项，不允许A组的用户编辑优先权字段。如果由于第一基于安全的规则在产品树中的位置而给予其优先权，则达到和第一情形中相同的结果，且允许用户1编辑优先权字段。反过来，如果任何禁止覆盖掉所有访问的准许，则工作项类型规则将指示不允许用户1编辑优先权字段，因为用户1是A组的成员。

响应于将一个或多个规则诠释为禁止用户动作，可禁止该用户动作，并可向用户显示一消息，例如，该消息诸如类似于以上参考显示900所描述的消息窗口916中的消息。此外，可配置客户机WIR引擎114以通过例如向用户显示帮助消息、提供所允许的字段值的列表等来协助用户执行所允许的用户动作。

如果引擎114对一个或多个被确定的规则的诠释是允许用户动作，则引擎114可将此事务传达给WIR客户机/服务器接口122。接口122可起到服务器WIR引擎124和不同WITS客户机(例如，WITS客户机102、104和106)处的一个或多个客户机WIR引擎之间的接口的作用(例如，协调通信)。接口122可将从客户机引擎114接收的事务转换为适合服务器WIR引擎124的形式，并将经转换的事务发送给引擎124。

可配置WIR引擎124来验证对存储在数据源126中的WIR信息130所进行的所有内容写，并可执行第二确定和对应于受影响的工作项的工作项规则的诠释。响应于接收到事务，引擎124可使用WIR信息130来确定对应于该工作项的一个或多个工作项规则(例如，基于安全的规则和/或工作项类型规则)，这些工作项规则可用表格形式来存储，一个或多个表格的每一行表示一特定规则。规则还可用其它形式来存储(例如，作为面向对象数据库中的对象)。

可配置引擎124以从被确定的规则构造视图(例如，SQL视图)，并基于所构造的视图来诠释这些规则。例如，可配置服务器WIR 124来串接从被确定的规则生成的多个SQL语句，并通过执行所串接的SQL语句来诠释一个或多个被确定的规则。

如果服务器WIR引擎124确定不允许用户动作，则它可回滚该事务，并将禁止和回滚传达给发起该事务的客户机WIR引擎。

在客户机WIR引擎114和服务器WIR引擎124两者处确定和诠释工作项规则可提供一种冗余来确保不允许受限制的用户动作。这可帮助维护***的完整性，特别是通过防止将违反工作项跟踪***的核心要求的用户动作来起到这一作用。此外，WIR信息130可能比客户机WIR引擎所使用的WIR高速缓存(例如，工作高速缓存116)中的信息更为近期，因为WITS服务器可能已从其它WITS客户机接收到工作项规则更新，而尚未把这些更新传播到发生该用户动作的WITS客户机。由此，服务器WIR引擎124执行的确定和诠释所反映的***100的状态可能比客户机WIR引擎作出的确定所反映的更为近期。

可使用各种技术中的任何一种来实现***100及其组件，这些技术包括软件(例如，C、C#、C++、Java或其组合)、硬件(例如，一个或多个专用集成电路)、固件(例如，电可变编程存储器)或其任何组合。***100的一个或多个组件可驻留在单个设备(例如，计算机)上，或者一个或多个组件可驻留在分离的、离散的设备上。此外，可在多个设备上分布每个组件，并且可交互设备中的一个或多个设备。

此外，在包括***100的一个或多个组件的一个或多个设备中的每一个设备上，每一个组件可驻留在该***的一个或多个位置中。例如，这些***的组件的不同部分可驻留在设备上的存储器(例如，RAM、ROM、磁盘等等)的不同区域中。这一个或多个设备中每一个都可包括除了其它组件之外的多个已知组件等，诸如一个或多个处理器、存储器***、磁盘存储***、一个或多个网络接口、以及一个或多个总线或将各组件相互连接的其它内部通信链路。可使用诸如以下参考图11和12所描述的计算机***来实现***100及其组件。

图10是示出在工作项目跟踪***中实现工作项规则的方法1000的示例的流程图。方法1000纯粹是为工作项跟踪***实现工作项规则的方法的示例性实施例，而并不试图限制本发明的范围。诸如方法1000的变体等这一方法许多其它实现中的任何实现都是可能的，并且旨在使其落入本发明的范围之内。可使用***100及其各个部分来实现方法1000及其动作，如以上参考图1所描述。

在动作1002，可创建一个或多个工作项，包括一个或多个基于安全的规则和/或一个或多个工作项类型规则。可由如以上参考图1的***100所描述的WIT界面和/或安全界面执行动作1002。

在动作1004，可接收到影响第一工作项的第一用户动作的指示。例如，客户机WIR引擎(例如，引擎114)可从例如以上参考图1所描述的工作项界面(例如，界面110)接收第一用户动作的指示。

在动作1006，可确定对应于第一工作项的一个或多个工作项规则，并且可在动作1008诠释一个或多个工作项规则。可如以上参考***100所描述地执行动作1006和1008。如参考***100所描述，动作1006和1008可由客户机WIR引擎(例如，引擎114)和服务器WIR引擎(例如，引擎124)一同执行。在一些实施例中，这些客户机和服务器引擎以略有不同的方式执行这些动作。如上所述，服务器可使用来自更为近期的数据源的数据，并可使用与客户机引擎不同的技术(例如，微软SQL技术)来确定和诠释工作项规则。此外，作为与纯粹禁止动作相对，客户机WIR引擎可通过，例如，列出被允许的值和/或用户可执行的动作来协助用户执行被允许的用户动作。反之，服务器WIR引擎对诠释的响应可以仅仅是禁止该动作和/或回滚封装该用户动作的事务。

在动作1010，可基于该诠释来响应第一用户动作。例如，如以上参考图1所描述，用户动作可以是：被禁止的，因客户机WIR引擎把它诠释为被禁止的；被禁止的，因客户机WIR引擎把它诠释为被允许的、但服务器WIR引擎把它诠释为被禁止的；或者被允许的，因客户机和服务器WIR引擎把它诠释为被允许的。

方法1000可包括其它动作。此外，作为方法1000的一部分执行的动作的顺序并不局限于图10中所示的顺序，因为可按其它顺序执行这些动作和/或可串行或至少部分地并行执行其中一个或多个动作。

可通过在一个或多个计算机可读介质(例如，非易失性记录介质、集成电路存储器元件或其组合等)上有形地具体化的计算机可读信号来定义在其中动作的方法1000、以及此方法和这些动作单独或组合的各个实施例和变体。计算机可读介质可以是可由计算机访问的任何可用介质。作为示例，而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括，但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术，CD-ROM、数字多功能盘(DVD)或其它光存储，磁带盒、磁带、磁盘存储或其它磁存储设备，其它类型的易失性和非易失性存储器，或可用来存储所需信息并可由计算机访问的任何其它介质，以及以上的任何适当的组合。

通信介质通常具体化为诸如载波或其它传输机制等已调制数据信号中的计算机可读指令、数据结构、程序模块或其它数据，并包括任何信息传递介质。术语“已调制数据信号”是指以在信号中将信息编码的方式设置或改变其一个或多个特性的信号。作为示例，而非限制，通信介质包括诸如有线网络或直接连线连接等有线介质，诸如声学、RF、红外及其它无线介质等无线介质，其它类型的通信介质，以及以上的任何适当的组合。

在一个或多个计算机可读介质上被具体化的计算机可读信号可定义指令，例如，作为一个或多个程序的一个部分，作为计算机执行这些指令的结果，它们命令计算机执行本文中所描述的一个或多个功能(例如，方法1000或其任何动作)和/或各个实施例、变体及其组合。此类指令可用多种编程语言中的任何一种来编写，例如，Java、J#、Visual Basic、C、C#或C++、Fortran、Pascal、Eiffel、Basic、COBOL等，或其各种组合中的任何组合。

其上具体化了这些指令的计算机可读介质可驻留在本文中所描述的***100、1100和1200中任何一个的一个或多个组件上，可分布在一个或多个此类组件上，并可在其间转移。

计算机可读介质可以是便携式的，从而可把存储在其上的指令加载到任何计算机***资源上以实现本文中所讨论的本发明的诸方面。此外，应当认识到，上述存储在计算机可读介质上的指令并不局限于作为在主计算机上运行的应用程序的一部分而具体化的指令。相反，可把这些指令具体化为任何类型的计算机代码(例如，软件或微码)，可以使用所述代码对处理器进行编程而实现以上所讨论的本发明的诸方面。

应当认识到，一般可把例如参考图1、11和12所描述的执行本文中所描述的功能的计算机***等计算机***的任何单个组件或多个组件的集合视为控制这些功能的一个或多个控制器。能用许多方式来实现一个或多个控制器，诸如用专用硬件和/或固件、使用用微码或软件编程来执行上述功能的处理器，或前述的任何适当的组合。

可在一个或多个计算机***上实现根据本发明的各实施例。例如，这些计算机***可以是通用计算机，诸如基于Intel PENTIUM类型处理器、MotorolaPowerPC、Sun UltraS PARC、Hewlett-Packard PA-RISC处理器、可从Advanced MicroDevice(AMD)得到的各种处理器中的任何一种、或任何其它类型的处理器等的计算机。应当认识到，可使用一个或多个任意类型的计算机***来实现本发明的各

实施例。

配置根据本发明的一个实施例的通用计算机***来执行上述一个或多个功能。应当认识到，该***可执行其它功能，并且本发明并不局限于具有任何一个或一组特定功能。

例如，可实现本发明的各个方面作为在诸如图11中所示的通用计算机***1100中执行的专用软件。计算机***1100可包括连接到诸如磁盘驱动器、存储器或其它用于存储数据的设备等一个或多个存储器设备1104的处理器1103。通常用存储器1104在计算机***1100的操作期间存储程序和数据。可由互连机制1105耦合计算机***1100的组件，该机制可包括一个或多个总线(例如，在集成在同一机器内的组件之间)和/或网络(例如，在驻留在若干单独的离散机器上的组件之间)。互连机制1105使***1100的***组件之间能交换通信(例如，数据、指令)。计算机***1100还包括例如键盘、鼠标、轨迹球、话筒、触摸屏等一个或多个输入设备1102，以及例如打印设备、显示屏、扬声器等一个或多个输出设备1101。此外，计算机***1100可包含将计算机***1100连接到通信网络的一个或多个接口(未示出)(除互连机制1105以外，或作为其替换方案)。

在图12中更加详细地示出的存储***1106通常包括计算机可读并可写的非易失性记录介质1201，其中存储了定义要由处理器执行的程序的信号或存储在介质1201上或之中要由程序处理的信息。例如，该介质可以是盘或闪存。通常，在操作中，处理器使数据从非易失性存储介质1201中读出到允许由处理器以比访问介质1201更快的速度访问的另一存储器1202中。此存储器1202通常是诸如动态随机存取存储器(DRAM)或静态存储器(SRAM)等易失性的随机存取存储器。它可位于存储***1106中(如图所示)或可位于存储器***1104中(未示出)。处理器1103一般操纵在集成电路存储器1104、1202内的数据，然后在处理完成以后将数据复制到介质1201中。有各种用于管理介质1201和集成电路存储器元件1104、1202之间的数据移动的公知技术，并且本发明不限于此。本发明不局限于特定的存储器***1104或存储***1106。

该计算机***可包括，例如，专用集成电路(ASIC)等专门编程的专用硬件。可用软件、硬件或固件、或其任意组合来实现本发明的诸方面。此外，可作为上述计算机***的部件或作为独立组件来实现这些方法、动作、***、***元素及其组件。

尽管是通过可在其上实施本发明的各个方面的一类计算机***的例子来示出计算机***1100，但是应当认识到，本发明的诸方面不局限于在如图11中所示的计算机***上实现。可在具有不同于图11中所示的体系结构或组件的一个或多个计算机上实施本发明的各个方面。

计算机***1100可以是能使用高级计算机编程语言编程的通用计算机***。还可使用专门编程的、专用的硬件来实现计算机***1100。在计算机***1100中，处理器1103通常是诸如可从Intel公司得到的公知的Pentium类处理器等可大批量得到的处理器。还有许多其它处理器都是可用的。此类处理器通常执行一操作***，它可以是，例如，可从Microsoft公司得到的Windows95、Windows98、WindowsNT、Windows2000(WindowsME)或WindowsXP操作***，可从AppleComputer得到的MAC OS***X，可从Sun Microsystems得到的Solaris操作***，可从各种源得到的Linux以及可从各种源得到的UNIX等操作***。可使用各种其它操作***中的任何操作***。

处理器和操作***一起定义了为其用高级编程语言编写应用程序的计算机平台。应当理解，本发明并不局限于特定计算机***平台、处理器、操作***或网络。同样，本领域技术人员应当明白，本发明并不局限于特定编程语言或计算机***，也可使用其它适当的编程语言及其它适当的计算机***。

可在耦合到通信网络的一个或多个计算机***(未示出)上分布计算机***的一个或多个部分。这些计算机***也可以是通用计算机***。例如，可在配置成向一个或多个客户计算机提供服务的(例如，服务器)或作为分布式***的一个部分执行总的任务的一个或多个计算机***中间分布本发明的各个方面。例如，可在包括分布在执行根据本发明的各个实施例的各种功能的一个或多个服务器***中间的组件的客户机-服务器***上实施本发明的各个方面。这些组件可以是可执行的、中间的(例如，IL)或诠释的(例如，Java)代码，它们使用通信协议(例如，TCP/IP)通过通信网络(例如，因特网)通信。

应当认识到，本发明并不局限于在任何一个或一组特定***上执行，并且本发明并不局限于任何特定的分布式体系结构、网络、或通信协议。

可使用诸如SmallTalk、Java、J#(J-Sharp)、C++、Ada或C#(C-Sharp)等面向对象的编程语言对本发明的各个实施例进行编程。也可使用其它面向对象的编程语言。或者可使用功能的、脚本的和/或逻辑的编程语言。可在非编程环境(例如，以HTML、XML或其它格式创建的文档，当在浏览器程序的窗口中查看这些文档时，它们呈现图形用户界面(GUI)的方面或执行其它功能)中实现本发明的各个方面。可作为编程的或非编程的元素，或其任何组合来实现本发明的各个方面。此外，可使用可从Microsoft公司获得的Microsoft.NET技术实现本发明的各个实施例。

在现在已描述了本发明的一些示例性实施例以后，本领域技术人员应当明白，上述内容纯粹是示例性而不是限制性的，它们仅是作为示例而给出的。许多修改和其它示例性实施例是在本领域普通技术人员范围之内的，并且设想它们落入本发明的范围之内。特别地，尽管本文中所给出的许多示例涉及方法动作或***元件的特定组合，但是应当理解，那些动作和那些元件能以其它方式组合来实现相同的目的。并不旨在将仅结合一个实施例讨论的元素和特征排除在其它实施例中的类似角色之外。此外，对于所附权利要求书中所述的一个或多个装置加功能的限制，并不旨在将这些装置局限于本文中所揭示的用于执行所述功能的装置，而是旨在将目前已知或有待开发的、用于执行所述功能的任何等效装置都包含在范围之内。

在所附权利要求书中使用诸如“第一”、“第二”、“第三”等序数项来修饰权项元素本身并不意味着任何优先级、优先权、或是一个权项元素排在另一个之前、或者执行方法的动作的时间顺序，而是纯粹用作标记以将具有特定名称的一个权项元素与另一具有相同名称(除了序数项的使用不同以外)的元素区别开来，以区别各权项元素。

设计文档

商务规则的描述和使用

概述…………………………………………………………………………23

设计目标和理由……………………………………………………………23

设计…………………………………………………………………………23

规则的评估……………………………………………………………24

个体规则………………………………………………………………26

项………………………………………………………………………30

字段……………………………………………………………………30

树节点…………………………………………………………………31

常量和常量集…………………………………………………………32

规避安全和限定强制…………………………………………………32

仅供管理的子树……………………………………………………………33

客户机方规则评估引擎的实现和局限………………………………33

性能项………………………………………………………………………36

可编程性……………………………………………………………………37

所存储的用于操纵和使用规则的过程………………………………37

所存储的用于操纵规则的过程………………………………………39

所存储的用于操纵产品树的过程……………………………………40

所存储的用于操纵产品字段的过程…………………………………40

创建产品规则的SQL示例 ……………………………………………41

规则的示例……………………………………………………………44

准许非短期域用户列出对所有项目的读许可………………45

将节点类型限制到列表中的一项……………………………………45

区域类型节点可将子区域或组件类型节点作为子节点……………46

‘Redmond\pstest’的成员不能在根节点在节点12的产品树的分支

中创建不是‘Folder’(文件夹)类型的节点………………………47

标题是对每个人的强制字段…………………………………………48

任何人都可读其所打开的任何项目…………………………………48

War是动态列表 ………………………………………………………49

当状态不是封闭时必须清空封闭的日期……………………………50

“Redmond\markradp”分布列表中的所有域用户可在任何地方做任

何事……………………………………………………………………50

概述

规则是团队基础服务器(Team Foundation Server)的工作项跟踪的运行时配置的主要来源。它们扩展由字段提供的灵活性来描述和强制执行在项目或服务器的生命期上的未知和改变着的管理员的商务需要。对这些需要使用单个机制，它覆盖了服务器的内容的安全和完整性。它们提供可在该体系结构中的所有层之间共享的商务规则的定义，这些层是：客户机层、中间层和数据层。这些规则是声明性的(而非规定性的)，因此每一层都可根据其特定的环境来进行适当的诠释。BRIE开始是Product Studio(产品工作室)应用程序的一部分，现已发展成为团队基础服务器的工作项跟踪的一部分。

设计目标和理由

目标是提供能够实现以下功能的丰富的原语集：

1)描述工作项跟踪***中所需的商务规则

2)调控产品树以便能委托对每个产品特征的管理，且同时防止在较低级处反置或规避较高级的决策

3)基于产品树和域组/用户提供安全设置

4)足够开放以便能以自然的方式添加将来的要求

5)不会慢到不可接受的程度

设计

安全和商务规则的强制执行是在中间层和数据层之间共享的协作成果。在决定性方面它们每一个相互依赖，没有一个能通过其自身而完全达到效果。

谁做了什么的简要概览如下：

1)中间层使用W2000的集成认证来标识域账号。

2)中间层使用此信息来决定使用哪些数据层原语来进行数据读。

3)对于数据修改(***/更新)，中间层

a)使用数据层原语来为域用户寻找内部ID

b)在其所修改的每一行中存储此内部ID

c)调用数据层原语来授权它刚刚进行的修改

d)如果有任何事情出错则回滚事务

3)数据层负责通过为每个域用户创建与合并个人化的、反映安全环境的SQL视图来提供“授权”原语。该安全环境由以下各项组成：

a)从有效目录导入并高速缓存在数据库内的域账号信息

b)当前的规则(覆盖了“安全”、项目内容和管理数据内容)

4)作为低优先级的背景任务(来为如客户机请求和更新等有用的任务保留CPU的大部分)，数据层

a)从有效目录验证和更新其用户和组成员信息的高速缓存

b)为个体的域用户更新SQL视图以合并安全环境中的改变

规则的评估

在伪码中，对一个项目的产品规则评估是

1.标识适用于该安全当事人(执行此任务的人)的所有规则

2.标识适用于该安全主体(产品树中悬挂了该项的节点)的所有规则

3.使用该项的内容来评估这些规则。

如果禁止该操作的任意规则的评估为真，或没有任何准许该操作的规则的评估为真，则拒绝该操作。

一个拒绝的原因将优先于任何个数的准许的原因。这对准许/禁止***是标准的。

重要的是要注意，对项目的任何改变应引起为所有字段进行规则的重新评估。确定其它哪些字段受到了该改变的影响的最简单的方法是为所有其它字段重新生成所允许的和建议的值的列表。这可在“即时”的基础上进行。

在SQL服务器内是通过标识对应于安全当事人的所有规则(或者是显式地，或者是因为该安全当事人直接或间接的成员资格)来评估的。把每个适用的规则都诠释为SQL表达式，然后把该表达式一起捆绑到SQL视图中。当安全当事人实际执行操作时，使用他们的“个人视图”来检测该操作是否被禁止或不被准许。在该情形下，回滚卷绕该操作的事务回滚。要使此生效，中间层必须遵守严格的指导方针。

中间层对象是受信计算基的一部分。但是，存在许多调试触发器，它们试图对中间层如何操作强加一些假定。这些假定包括：

A)中间层将通过在所有行中记录相同的改变者ID和该改变的改变日期来将数据库修改分组。改变日期是在进行第一次改变以前所取的SQL服务器的UTC***时钟时间。改变者ID是该改变所代表的域账号的不变ID。为0的改变者ID是应用程序发起的改变。UTC是“协调的世界时间”。这在大多数情况下是GMT时区的同义词，但UTC没有任何“夏令时间”。

B)读是通过为特定域账号定制的SQL视图完成的。中间层基于域账号的名称选择视图。如果该视图不存在，则中间层执行的SQL批处理将生成句法错误。在此情形中，中间层出错路径将会调用所存储的过程来重新构建丢失了的个人视图，然后重试SQL选择。

C)改变是按可串行化事务内的特定顺序进行的。中间层生成SQL批处理来执行从开始到提交的任何事情。如果通过所存储的过程回滚事务，则SQL批处理必须返回而不进行任何其它数据库修改。由SQL服务器提出的错误可能并不意味着终止该SQL批处理。要求的顺序(由调试建立触发器尽可能地强加于表格)是

1)开始一可串行化的事务

2)为安全当事人重新构建相关的个人视图

3)进行各种类型的项修改(即，包括从属链接请求、废除、接受和拒绝加上复制生成和清除加上添加和从相关组移除)

4)授权项修改

5)进行字段属性修改

6)进行字段用法修改

7)授权字段修改(属性和用法)

8)进行树修改

9)授权树修改

10)添加新的规则常量

11)进行规则组修改

12)进行规则修改

13)<按需添加其它元数据修改>

14)授权规则修改

15)应用项修改

16)应用字段修改

17)应用树修改以重新构建展开的树表

18)应用规则修改

a.用原来的展开的集合表标记个人视图以便重新构建

b.重新构建展开的集合表

c.用新的展开的集合表标记个人视图以便重新构建

d.移除失效的个人读视图，以使中间层在一使用时就将它们重新构建。

个体规则

产品规则并不指定其对象。可把同一产品规则应用于许多对象，例如，项或管理数据，并且由以下各部分组成

1)条件。条件是逻辑的If-Then(也称为隐含)表达式。

2)范围

3)用法标志集

条件是评估真或假的逻辑的If-Then(也称为隐含)表达式的编码。子表达式的每一个都涉及一个“产品字段”、一个“规则常量”和一个运算符。当该常量是一个串时，对对象中的“产品字段”的值进行评估。运算符是由标志的组合确定的。规则可通过将反置(Reverse)标记设为开(on)来反置“If”和“Then”部分。这允许将规则中更有表达力的Then部分作为它是If部分那样来使用。然后规则变为“Then-If”(反置隐含)。使用条件的“Then”部分来驱动字段下拉列表的对象总体。为了能对字段下拉列表具有影响，规则必须在条件中有“Then”部分。

可使用运算符在字段值和以下各项之间进行比较

1)从数字ID到串的映射关系提取的简单串。

2)常量集扩展所导致的常量。

3)特殊常量，该常量假设取决于评估该规则的环境的一个值。

可用的运算符是

1.字段值和常量之间的串相等。这是无运算符标志设置的运算符，除非该常量是特殊的。

2.串模式匹配，其中模式是来自常量扩展的串。该值必须仅匹配模式中之一个以评估为真。只有为“In”标志设置的运算符支持模式匹配。

3.每当遇到特殊常量时即转义到特殊情形处理。

4.当设置fThenConstLargeText标志时，使用TreeProperties(树属性)表中PropID等于ThenConstID的行的大文本值。

注：TreeProperties表具有(TreeId，Propid，Name，Value)条目组，它表示任何特定TreeID(节点)的某个属性。通过将项目(由TreeId表示)的呈现表单作为值存储在TreeProperties表中而通过项目来界定呈现表单的范围。字段“Value”(值)是ntext字段(因此能够存储大文本)。使用以上(4)中所描述的运算符将来自TreeProperties表的PropID与“Work Item Form ID”(工作项表单ID)字段相关联。为指示ThenConstID中的值是应从TreeProperties表中拾取的大文本值，在规则中应当设置fThenConstLargeText标志。

常量集扩展如下进行。2个标志组定义当扩展集合时要取哪些节点：

●叶组：

○fThenLeaf-命令取叶常量

○fThenInterior-命令取内部常量(也称为集合名称)

●深度组：

○fThenOneLevel-命令取正被扩展的常量的直接子节点

○fThenTwoPlus-命令取间接子节点

对于要包括在经扩展的集合中的常量，每个组中必须设置至少一个标志。

当前的数据库实现仅支持上述标记的以下组合：

●常量组的直接成员。(fThenLeaf＝1，fThenInterior＝1，fThenOneLevel＝1，fThenTwoPlus＝0)。这被称为Member(成员)运算符。

●除了嵌套组的名称以外的常量组的每一个直接和间接成员(即，从组的扩展出发的叶节点或外部节点但不包括根节点)的串。(fThenLeaf＝1，tThenInterior＝0，fThenOneLevel＝1，fThenTwoPlus＝1)。这被称为in运算符。

●包括任何嵌套组的名称在内的常量组的直接和间接成员(即，从扩展出发的内部节点和外部节点但不包括根节点)。(fThenLeaf＝1，fThenInterior＝1，fThenOneLevel＝1，fThenTwoPlus＝1)。这被称为“InWith Set Names”运算符。

可对每个运算符求反。把整数和日期时间字段转换为串以便评估。整数被格式化为十进制数。日期时间被格式化为ISO 8601(XML中所使用的格式，即，不含空格的yyyy-mm-ddThh:mm:ss:mmm)。规则中不会使用许多特异的整数和日期时间，而将它们作为串常量存储自然地容纳了整数组，例如1，2，5。对于组运算，规则中的常量是常量集的名称。组可无限深度地包含其它组作为嵌套成员。不把嵌套组的名称计为组成员，除非已经明确地添加该组的名称作为该组的成员。把组和模式匹配运算限制于“Then”子表达式。“If”运算符是被作为特殊情形处理的，或者是值(以可预测的方式被转换为串)和常量ID的串之间的直接的串相等。

由“Not a Field”字段和“Not a Constant”(也称为“未知域账号”常量)之间的子表达式来定义总是真的退化子表达式。当评估常量在组内(WITHIN)的评估和常量在组外(WITHOUT)的评估之间的组成员时，就引起了差别。当评估组内包括常量时，该组就隐含地将空值和该字段的现有值包括在目标对象中。当评估常量被排除在组外时，没有任何隐含成员被添加到组中。

考虑“Then”表达式的运算符标志的另一种方式是将其作为树的根节点的那个规则的常量。其“成员”是根的子节点。树中的任何外部(也称为叶)节点是在(“In”)该组中。树中的任何节点(外部或内部的)是在具有组名称的组中(“in the set with set names”)。对应于根节点的串总是在外部，除非把它作为子叶节点明确地包括在其本身之中。这将把这一对应于根节点的串添加到所有运算符的结果中，或当没有任何运算符时。

规则并不基于起源来区别字段。字段的值是由终端用户还是由服务器设置是无关紧要的。仅当目标包含所有被引用的字段时规则才是适用的。如果在评估规则的时候不能确定字段的值(例如，该值是后来由服务器设置的，并且正在客户机上评估规则)，则视为该字段对目标对象不可用。

范围限制规则适用的表面的维度。所有范围都必须适用于规则适用的目标。一个维度是所涉及的域用户。其它维度是目标项的离散方面。可把规则的范围界定到特定域用户，或者域组的所有成员，或者被高速缓存在库存数据库中的电子邮件分发列表。也可使用特定的域用户组。

还把规则的范围界定为适用于使用“根树ID”和“树ID”的项目或子项目内的项目。“树ID”可以是树中的单个节点，或是根节点在特定节点处的子树。当把规则限制于单个节点时，“flow down”(流下)标志为0。当“flowdown”标志为非零时，则规则的表现就象它被树中的后代节点继承那样。大多数规则将此标志置为on(开)。当“flow around”标志为on时，规则适用于项目或子项目中除了“树ID”的节点或子树以外由“根树ID”所指示的任何地方。

规则具有用于字段范围界定的槽。每个槽有字段ID和要比较的目标项中的字段的前一值和当前值两者或其中之一。作为特殊情况，可对字段的前一值使用空值，作为从不具有任何值的字段的转移的目标。

用法标志指示规则何时应准许或禁止操作。把所有操作分配到“项读”、“项写”和“管理修改”这些宽泛的分类。不把向相关项组添加或从其移除项视为对所添加的项或组中其它项的写。附加或链接文件、或者改变项中任何字段的值是项写的一部分。把创建新项视为项写。为移动一个项，安全当事人需要旧位置和新位置的写许可。当条件为真时禁止修改动作的许可的规则提供一种声明性方法来定义对象的限定。(限定是拒绝不能证明结果为“好”的对象的修改)。

在这些同在客户机和服务器处评估的强制性规则以外，还有仅在客户机上评估的其它规则。设置了“suggestion”(建议)标志的规则定义目标中供用户选择的“较佳”值。设置了“default”(默认)标志的规则定义供用户预选的值。从规则的ThenConstID提取值(或值列表)。suggestion和default所对应的字段是“ThenFieldID”。对应用(如果假定Then表达式为真则评估为真)的所有规则的建议或默认值进行组合以提供要在客户机处建议或预选的值的单个列表。将使用类似功能以便帮助文本规则计算环境敏感的帮助文本。

当在产品规则条件中使用时，给予以下常量“特殊”的诠释。

○“Empty Value”(空值)

○“Was Empty Value”(曾为空值)

○“Same As Old Value”(和原值相同)

○“Name Of Security Principal”(安全当事人的名称)

○“Old Value Plus 1”(原值加一)

○“Value from a different field”(来自不同字段的值)

○“Server’s data/time stamp”(服务器的日期/时间戳)

○“Client’s data/time stamp”(客户机的日期/时间戳)

○“Old value from a different field”(来自不同字段的原值)

大多数名称是自明的，但有一些东西是任意的，以适应不够一般因而无法确保一般支持的特定顾客的特殊情况，例如，在字段具有需要许可的域账号名称的值时，使用“Name of Security Principal”来准许/禁止许可。

规则本身是规则的目标。改变产品规则的用法标志需要该规则范围中的所有树节点的管理许可。某些规则是不可编辑的，并且是以“黑盒(in-the-box)”方式提供的，并且在运行时不能修改。

对于一个版本，当为空或长度为0时，把嵌入在Are表中的字段视为空。当值长度为0或空时，或当该版本没有呈现出任何行时，长文本帮助程序表中的字段为空。

产品工作室应用程序还维护管理员可直接使用的或包括在较大组中的许多个组。这些包括：

域账号-如通过AD的代理(Elead组件)曝露的已知当前有效的所有电子邮件别名

域用户-已知为用户的域账户的子集

域组-已知为组或分发列表的域账户的子集

项

关键概念是“项”。这是大多数规则的目标。项是Are表中的一个行，该表所有“单值”字段(即，核心、公共和自定义)都有一个列。此行是项的最新版本。还有Were表，它具有和Are表相同的布局再加上“Revised Date”(修改日期)列。当更新项时，Are表中该行的原内容随项Are表行的新内容的UTC修改时间一起***到Were表中。通过将Are表和Were表放在一起，就有了该项的“单值”字段的所有版本的完整历史。大多数查询将仅涉及项Are表。除了这些表以外，还有许多“扩展”表。不是“单值”字段的任何项字段的值都进入这些表中之一。有对应于词、文件、相关项和关键词的扩展表(其中一次可把字段设为不止一个值)。扩展表中的每一行在特定时间跨度上是“有效”的。如果扩展在此刻“有效”，则此时间跨度可达到很远的将来。如此，每个扩展表都具有所有项的最新和被替换的版本。规则涉及项的最新和先前的版本。

字段

项由个体的字段组成。每个字段有“友好名称”、整数ID和字段存储类型。“存储类型”有硬编码的调色板。每个字段都必须是这些类型之一，但许多不同的字段可具有相同的类型。

存储类型有：

日期时间。把这些嵌入在Are表中。例子是“Opened Date”(打开日期)或“Closed Date”(关闭日期)。

整数。把这些嵌入在Are表中。例子是“Beta ID”

双精度。把这些嵌入在Are表中。例子是可取值25.25的“Percentagecompleted”(完成百分比)

关键词。把这些嵌入在Are表中。例子是“Status”(状态)或“Assignedto”(分配给)。对于一次只能选择一个值的radio框功能使用这些。

词。这些是长段文本。把这些存储在帮助程序表中。例子是“Description”(描述)或“Repro Steps”。

多值关键词。把这些存储在帮助程序表中。例子是“Processor”(处理器)或“OS”。对于于一次能够选择多个值的检查框功能使用这些。当前在Currituck中不使用这些。

文件。把这些存储在帮助程序表中。例子是“Attachment”(附件)或“Linked File”(链接文件)。

存储在Are表中的字段和存储在帮助程序表中的字段之间的区别是，对于后者，项的每个版本可以有多个值。但是，所有字段的所有值对该项的所有版本都是可用的，因此表示层可使简单的字段表现为具有多个值，例如，所显示的描述是来自串接在一起的每个项版本的浅描述的值的并置(concatenation)。

每种存储类型都具有其自身的细微差别(带有改变的强制量)。所有关键词(对于radio框和检查框功能而言)字段都具有255的最大长度。字段不能改变类型，但是可在类型内进行一些小调整，例如，以后可增加关键词的最大长度。文件可具有路径和显示名称。可不在每一个对象中都使用一字段，库存管理员可引入新的字段。同一字段可在许多对象中出现。

树节点

产品树是单边图。这意味着它是由节点组成的。每个节点都有一条返回其父节点的链路。节点由整数ID标识。除了根节点以外(它起到它自己的父节点的作用)，其它节点不链接到它们自身。每个节点具有类型和名称。节点名称在表内不是唯一的，但是在兄弟节点之间保持唯一。每个项目“位于”一个树节点中。可把树节点标记为被删除或仅供管理。被删除的节点不能含有项，并且在其下的任何节点都不能含有项。当树节点是仅供管理，或处于仅供管理的节点之下时，除了写许可外还需要管理许可才能创建或改变该树位置中的项。

树节点可以是规则的目标。特别地，使用规则来控制树节点的“类型”属性。管理员可定义产品规则来为父节点类型控制子节点的类型。“黑盒”类型的产品节点和它们之间的关系也是由节点等级类型之间的隐含排序确定的。每个节点类型都可称为其自身中带有独特字段类型的字段，并可与其它字段一样被标记为使用或废弃。节点类型的相对“大小”(即，作为节点类型T的后代，哪些节点类型是可接受的)被编码在分配给节点类型字段的数中。

常量和常量集

常量永远不是规则的客体。它们存在只是为将串与规则内部使用的整数id相关联。但是，它们的确给出了使将来版本的产品库存成为多语的挂钩。

集合可以是规则的客体。特别地，改变被产品规则引用的集合的成员实际上修改了规则。改变集合需要管理许可才能改变直接或间接引用该集合的所有规则。集合可被无限嵌套。特殊常量不能是常量集的成员。

使用许多集合来高速缓存来自有效目录的域信息。有一种集合，其成员是所有域账号的名称的常量，另一种集合是域用户名称的常量集。其它集合将域用户分成“非短期”(全职雇员)和“短期”(其它任何人)。如果常量是域组或发放列表的名称，则其成员资格在“尽力服务”基础上与有效目录同步。至少，将使成员资格同步过夜。

通过在计算所得的字段“Changed Set”(经修改的集合)是受保护的常量的情况下准许或拒绝管理许可而要求管理许可来改变常量的串或其直接或间接的成员。“Changed Set”字段在产品规则以外不可使用。使用此机制来限制将重要的“黑盒”集合的成员改变为仅可被具有管理许可的某人改变的其它集合的成员的能力。具有预定许可的“黑盒”集合是

●“管理员”-准许对根节点及以下的管理

●“用户”-准许对根节点及以下的读/写

●“客人”-准许对根节点及以下的读

规避安全和限定强制

存在对能够“规避”写的正规授权(安全和限定两者)的需求。这在Currituck中所表现的形式迄今未知。一种方法可以是允许把用户添加到或从“Write All”(写所有)组中移除。对此组的成员的写操作没有强制任何安全。这将补充现有的“Read All”(读所有)组(对其成员没有强制任何读安全)。

仅供管理的子树

通过在子树的根节点上设置标记，可将产品树的一部分放在“admin only”(仅供管理)模式。当处于仅供管理模式时，此子树内的写操作除了写许可以外，还需要对整个“仅供管理”子树的管理许可。

客户机方规则评估引擎的实现和局限

目标是要创建能在许多环境中、并可供不同类型的对象(项、情况等)使用的引擎。BRIE接口是基于回叫的，因此为了取得实际数据，BRIE回叫其调用者。这允许BRIE调用者使用灵活的方法来检索数据：可在当BRIE遇到需要来自该字段的值的规则时按需要来实现，或者在调用者不能或不想检索字段的值的情况下可选择跳过规则处理。

BRIE由当前管理高速缓存状态参数化。所有规则和伴随的管理数据是从管理高速缓存检索的。在高速缓存改变以后，BRIE必须被重新初始化。

把主要功能集中在取安全当事人访问令牌(当事人所在组的集合+适用于该当事人的规则集合)、要检查对其访问的对象、被请求的访问掩码(读、写、管理)的单个入口点(“AccessCheck”)。输出是访问是否已被准许的标志以及可任选的有效访问掩码。

AccessCheck还可输出以下信息：

●字段属性-指示为字段提供哪些种类的规则的标志集。BRIE将字段属性细分为以下类别：

○Forbidden(禁止的)-如果字段值与此类别中任何规则匹配，则拒绝访问

○Required(必要的)-如果字段值与此类别中的所有规则都不匹配，则拒绝访问

○Allowed(允许的)-如果字段值与此类别中的一个规则匹配，则准许访问(尽管其它规则可能禁止它)

○Suggested(建议的)-起到建议作用的规则标记掩码

○Not suggested(不建议的)-起到否定建议作用的规则标记掩码

●值列表/格式-对应于上述字段属性类别的任选常量/格式列表AccessCheck算法如下进行：

●从当事人请求访问的对象(项、树节点等)找出树位置。

●找出对应于主体的类型id

●如果所请求的访问包括写访问，则检查原/新树位置看其是否具有仅供管理标志。

●对于个人访问令牌，枚举适用于该安全当事人的所有规则

●对于每个规则，如果以下任何条件未被满足，则跳过该规则

○如果该规则中没有任何访问权利位于所请求的访问掩码中。

○如果在正被检查的对象类型中没有使用该规则中提及的那些字段。

○如果该规则的分层结构位置不适用，则跳过该规则。

○从这些对象读取该规则中所适用的字段。如果该规则中所提及的任何字段丢失，则跳过该规则。

○评估该规则。如果规则拒绝访问，且调用者既不想有效的访问掩码也不想计算字段属性，则立即返回。否则，将规则访问掩码添加到全局准许或全局拒绝的访问掩码。

○对于一些规则专门化，强制该规则的then部分的字段为所请求的值(如，“强制值为空”，“强制值被冻结”，“强制值为只读”)

○在已评估所有规则以后，对照所请求的访问掩码检查全局允许/拒绝掩码。

如下进行对特定规则的评估：

●如果请求了字段属性，则向规则评估算法传递该规则期望的结果。期望的结果是从访问标志推导的。基于期望的结果和规则表达式标志(fUnless、fThenNot)，该算法为该规则选取目标类别(forbidden、required、allowed、suggested、not suggested)。

●评估规则。计算If部分。如果If部分为真，则计算Then部分。“If部分”是2个表达式：“If1”and(与)“If2”的合成。丢失任一子表达式被视为该子表达式成功。如果两个子表达式的值都评估为真，则说评估“If部分”为真。

结果是If＝＞Then。以下表达式算法是可用的：

○模式匹配

○集合成员资格

○相等

○特殊表达式(放置如CodeDefect特殊常量等的挖口的可扩展位置)

●这些算法为它们所遇到的类型的规则设置标志。标志的示例有：

○检查值是否为空的规则

○检查值和以前是否相同的规则

○检查列表成员资格的规则

○检查模式匹配的规则

○检查列表成员资格并且也取空值和原值的规则

○检查模式匹配并取原值的规则

○取域用户的规则

○取域组的规则

○在字段上设置默认值的规则

○将值复制到字段的规则

●如果规则评估得到非期望的结果，则将字段状态标志与刚刚计算的规则标志求或。

●如果请求，则创建值/格式列表

在对所有规则评估以后，计算特殊的“外部”类别。外部类别旨在包含供UI消耗的值/格式+属性。如果外部类别不为空或者是允许和建议的类别的并集，则它等于所要求的类别。然后从外部字段属性类别减去禁止的和不建议的类别。

BRIE还具有无条件规则的概念。无条件规则是If部分被清零且Then部分具有特殊的“安全当事人“常量或也被清零的规则。BRIE可对对象进行无条件访问检查。无条件访问检查还可以与正规访问检查并行地进行。可以使用无条件访问检查被来计算对对象的许可而无需考虑它们内容的改变。使用此机制来支持安全异常(assigned to(分配给……)和opened by(由……打开))。BRIE揭露出一种方法，该方法可以断定对特定对象类型和特定访问掩码进行无条件访问检查需要哪些字段。BRIE调用者负责提供对规则评估的那些字段。

BRIE提供少数几个帮助程序方法以便于规则评估过程。

●构建访问令牌。AccessCheck方法要求BRIE调用者标识使用访问令牌的安全当事人。BRIE构建访问令牌，且BRIE调用者负责在检查访问时将该令牌传回。需要访问令牌的主要原因是消除冗余计算的需要。访问令牌包含安全当事人所属的一组常量集、以及适用于该安全当事人的规则集。

●为查询构建程序(FieldInfoAllowedValues)计算建议值。使用一种非常简单的算法来实现这一目的。处理具有涉及感兴趣的字段的所有规则。当fIfNot为0时取来自If部分的所有值。当fThenNot^fUnless^Deny Write为假时，取来自Then部分的所有值。还计算树节点类型。被特殊处理的字段有：树字段、节点名称、节点类型、人名

●默认值：给定“项”的状态，brie能够计算该项上的字段的默认值。

●计算所得字段的无效。给定字段id，BRIE能够断定那些计算所得字段因为修改的原因而受影响。

●计算所得字段的计算。BRIE能够计算以下计算所得字段的值：

○树类型字段

○节点名称

○节点类型

○树路径

○人名

BRIE还不能够计算一些只读字段(依存关系相关的字段、回归)。一旦保存了项，即由中间层返回那些计算所得的字段。

性能项

最大的问题是在家务管理中标识隐含的组成员资格以及在产品树中哪些节点在其它哪些节点之下。这混合了同步诸域组和分发列表的成员资格信息以及所有域账号相对于有效目录的持续存在的成本。次要考虑的是为个体的域用户生成SQL视图和标识它们何时失效(因为它们不再反映规则和组成员资格)的成本。携带大量视图的成本很低，但使用这些视图来检测何时应回滚数据库修改、或者通过个人视图来过滤用户选择(对于读而言)有一定的成本。

某种当前规则编码的解释

1.实现Assigned to异常(可走开)的规则

当(Assigned To是*特殊常量*-10020)时，对子树\(TF服务器)内的\(TF服务器)下的经认证账号准许写。

此规则的编码是：

((dbo.StringInString(I.[Person Name]，W.[Assigned to])＝1

anddbo.EmailIsVerified(W.[Assigned To]，W.[Changed Date])＝1

andW.AreaID is not null

and

W.AreaID＝I.AreaID))

这将以下规则编码：如果进行修改的人(由I.Person Name]表示)和向其分配了故障的组是相同的或是其成员，与[Assigned to]字段的值是有效值，与该项的树位置是有效的，与当前没有修改该项的树位置，则允许写。

对后端中用于管理更新的最优锁定的解释

使用管理表(规则等)的时间戳列来进行最优锁定。我们不是持有锁，而是在操作集的开始处存储DB的时间戳。

我们将事务的隔离级设为“read committed”(读已被提交)，这意味着在我们从行中读出一些数据以后，其它某个事务可能进入并修改了该数据(“不可重复读问题”)。为避免出现此问题，我们进行如下最优锁定。

当我们想要决定我们正在更新的行从我们开始执行此操作起是否已被更新时，我们查看该行的时间戳列的值是否高于我们所存储的值。

如果为是，则该行在我们最近一次读它以来已被更新(被其它某个事务)，而我们应当重新进行我们的修改。如果为否，则我们可对该行进行我们的修改。例如，见所存储的RebuildPersonsViews过程。

可编程性

所存储的用于操纵和使用规则的过程

/*--------------------------------------------------------------

//名称：AuthorizeItemChanges

//

//检查在特定日期被修改的项未违反任何项内容规则。如果任何项违反了

//任何规则，则该事务被回滚。预期在可串行化的事务中运行此过程，从

//而结果不会受到在同一UTC时钟时间添加或修改项的其它事务的影响。

//------------------------------------------------------------*/

/*--------------------------------------------------------------

//名称：AuthorizeRuleChanges

//

//检查在特定时刻被安全当事人修改的所有规则没有违反任何规则。改变

//改变被规则引用的常量集的成员作为对该规则的改变。集合表上的触发

//器通过更新受RuleSet改变影响的那些规则的ChangerID和ChangedDate

//来实现此过程。不能更新或删除对应于常量ID的串，因而不会引起对

//规则的类似的修改。

//------------------------------------------------------------*/

/*--------------------------------------------------------------

//名称：AuthorizeTreeChanges

//

//被规则引用的常量集的成员作为对该规则的改变。集合表上的触发器通

//过更新受RuleSet改变影响的那些规则的ChangerID和ChangedDate来

//实现此过程。不能更新或删除对应于常量ID的串，因而不会引起对规

//则的类似的修改。

//------------------------------------------------------------*/

/*--------------------------------------------------------------

//名称：AuthorizeFieldChanges

//检查在特定时刻被安全当事人修改的所有规则没有违反任何规则。还对

//产品表单的修改进行此检查。

//------------------------------------------------------------*/

所存储的用于操纵规则的过程

/*-----------------------------------------------------------------------------------------------

//名称：AddConstant

//

//用来将常量引入到库存中的所存储的过程。如果常量是域账号，则将使

//它与有效目录同步，即，将从有效目录取其集合成员资格。

//---------------------------------------------------------------------------------------------*/

//名称：ChangeRuleSet

//

//向集合/列表添加现有的常量。

//

//一旦违背了安全或其它完整性，就回滚事务。如果回滚了事务，则出现

//SQL出错266。

//名称：LookupRule

//

//添加/寻找具有特定条件集的规则。规则的个数被保持在最少，因此仅当

//没有所需条件的现有规则时才添加新的规则。

//名称：ChangeRule

//

//改变现有规则的标志。不进行任何冗余的数据库更新。可通过使用null

//作为输入自变量值来保持不改变任何许可标志。

//如果规则的所有标志为0，则不删除它，而是变成不相关的。

//SQL出错266。

//名称：ApplyRuleChanges

//

//在已授权所有修改以后，且已应用树改变以后、但在施加规则改变以前

//调用。此过程根据安全当事人在给定时间对集合所进行的修改向和从

//ExplodedSets(暂态成员集)添加和移除行。

所存储的用于操纵产品树的过程

//名称：ChangeTree

//

//改变现有节点或向产品树添加新节点。不进行任何冗余的数据库更新或

//***。可通过使用null作为输入自变量值来保持不改变任何列。如果将

//null的TreeID作为输入传递则添加新节点。

//SQL出错266。

//名称：ApplyTreeeChanges

//

//基于对产品树的改变而对树路径表进行增量改变。对产品树的改变的公

//共情况是用于涉及整个子树的小调整。

所存储的用于操纵产品字段的过程

//名称：ChangeField

//

//改变现有字段或添加新的自定义字段。

//一旦出现安全或其它完整性的破坏，事务即被回滚。如果事务被回滚，

//则举起SQL出错266。

//名称：ApplyFieldChanges

//

//当将“short and narrow”(短的和窄的)字段投入使用时改变Are表和

//Were表。这些是可在产品工作室UI的结果区中显示的字段。如果需要，

//则重新构建过滤掉所有未被使用的数据库列的这些表的视图。这些视图

//是用于保护项读的个人视图的基础。

创建产品规则的SQL示例

print′Try to use personal read view for □arente\amitgh′

exec dbo.AddConstant

@changeDate=@now

,@string=′REDMOND\amitgh′

,@constID=@constID output

exec dbo.RebuildOnePersonsViews @personID=@constID

select count(*)from dbo.[xxAOR_redmond\amitgh]

使用后门添加dev团队作为自动导入的域账号

exec dbo.AddConstant

@changeDate=@now

,@string=′REDMOND\markradp′

,@constID=@constID output

exec dbo.SyncWithAD_UserOrGroup

@changeDate=@now

,@constID=@constID

,@fGroup=1

,@fImport=1

,@fTwoTier=1

exec dbo.LookupRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID output

,@personID=@constID

exec dbo.ChangeRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID

,@fGrantRead=1

,@fGrantWrite=1

,@fGrantAdmin=1

通过将Mohammed Iqubal添加到集合中来给予他两层的访问

exec dbo.AddConstant

@changeDate=@now

,@string=′REDMOND\moiqubal′

,@constID=@constID output

exec dbo.ChangeRuleSet

@changerID=0

,@changeDate=@now

,@constID=@constID

,@parentID=-4-Users with two tier access

使用后门添加PS测试团队作为自动导入的域账号

exec dbo.AddConstant

@changeDate=@now

,@string=′REDMOND\pstest′

,@constID=@constID output

exec dbo.SyncWithAD_UserOrGroup

@changeDate=@now

,@constID=@constID

,@fGroup=1

,@fImport=1

,@fTwoTier=0

只有用户amitgh能够改变SourceID

exec dbo.AddConstant

@changeDate=@now

,@string=′REDMOND\amitgh′

,@constID=@constID output

exec dbo.LookupRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID output

,@fUnless=1

,@ifFldID=36

,@fIfNot=1

,@ifConstID=-101

,@thenFldID=-1

,@thenConstID=@constID

exec dbo.ChangeRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID

,@fDenyWrite=1

print′Amy Sadler,a user,needs two tier read access′

exec dbo.AddConstant

@changeDate=@now

,@string=′REDMOND\amys′

,@constID=@constID output

exec dbo.ChangeRuleSet

@constID=@constID

,@parentID=-4

,@changeDate=@now

,@changerID=0

print′Amy Sadler can manage dependant links′

exec dbo.LookupRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID output

,@personID=@constID

,@thenFldID=15

,@fThenNot=1

,@thenConstID=PS_DB_CONST_SameAsOldValue_ID

exec dbo.ChangeRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID

,@fGrantAdmin=1

print′Amy can add nodes one size smaller than Feature′

exec dbo.AddConstant

@changeDate=@now

,@string=′Feature′

,@constID=@typeID output

exec dbo.LookupRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID output

,@personID=@constID

,@fUnless=1

,@thenFldID=-11

,@fThenOneLevel=1

,@fThenLeaf=1

,@fThenInterior=1

,@thenConstID=@typeID

exec dbo.ChangeRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID

,@fGrantAdmin=1

print′BetaID suggestion list can be added to by noone′

exec dbo.AddConstant

@changeDate=@now

,@string=′Beta ID List′

,@constID=@constID output

→＞Associate the list with the field

exec dbo.LookupRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID output

,@thenFldID=37

,@thenConstID=@constID

exec dbo.ChangeRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID

,@fSuggestion=1

→＞Identify who cannot change the list

exec dbo.LookupRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID output

,@thenFldID=-13

,@thenConstID=@constID

exec dbo.ChangeRule

@changerID=0

,@changeDate=@now

,@ruleID=@ruleID

,@fDenyAdmin=1

规则的示例

以下规则示例描述一商务情形以及产品规则将如何解决该情形。列出了如在“Decoded Rules”(经解码的规则)视图中所出现的规则和其所依靠的常量集中的所有串。要查看所有具有(虚饰的)英文诠释的规则则执行

从dbo.DecodedRules选择ForDisplay

为查看命名集合“Okay Status”中的串(但不是嵌套集合的名称)则执行

从dbo.ExplodeSet(‘Okay Status’)选择*

为查看那些是命名集合“Okay Status”的直接成员的串(包括嵌套集合的名称)则执行

从dbo.ListSet(‘Okay Status’)选择*

域组或分发列表的名称(例如，‘redmond\markradp’)起到集合名称的作用。同样使用展开集合UDF来查看它们的成员。

为找到串的常量ID则执行

从dbo.Constants选择String＝‘redmond\tomtal’的ConstID

注意：用作ID的数字不是固定的。不同的库存可对完全不同的串、字段或树节点使用相同的数字。

准许非短期域用户列出对所有项目的读许可

(可编辑)Grant Read FOR No Dash Domain Users TO Everywhere WHENAlways(总是准许非短期域用户对任何地方的读)

fGrantRead fDenyRead

---------- ---------

0

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

1 0 -20 0

IfFldID fIfNot IfConstID

----------- ------ -----------

0 0 0

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- -----------

0 0 0 1 0

fGrantRead fDenyRead

---------- ----------

0

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

1 0 -20 0

IfFldID fIfNot IfConstID

--------- ------ ---------

0 0 0

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- -----------

0 0 0 1 0

将节点类型限制到列表中的一项

Deny Admin FOR Domain Accounts TO Everywhere Unless Node Type IDNOT is Product＝＞Node Type ID in Child Node Types(禁止域账号对任何地方的管理，除非节点类型ID NOT是产品＝＞按子节点类型的节点类型ID)

fGrantAdmin fDenyAdmin

----------- ----------

1

fGrantRead fDenyRead

---------- ---------

0

fGrantWrite fSuggestion fDenyWrite

------------ ---------- ----------

0 0 0

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

0 0 -1 1

IfFldID fIfNot IfConstID

----------- ------ -----------

-11 1 -41

ThenFldID fThenNot fThenLike fThenIn ThenConstID

--------- ------- ------- ------ ---------

-11 0 0 1 -40

String

-----------------------------------------------------------------

Folder

SubComponent

Component

SubArea

Area

区域类型节点可将子区域或组件类型节点作为子节点

Deny Admin FOR Domain Accounts TO Everywhere UNLESS Parent NodeType ID is Area＝＞Node Type ID in Area(禁止域账号对任何地方的管理，除非父节点类型ID是区域＝＞区域中的节点类型ID)

fGrantAdmin fDenyAdmin

----------- ----------

1

fGrantRead fDenyRead

---------- ---------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

0 0 0

fEditable TreeID PersonID fUnless

--------- ------------ -------- -------

0 0 -1 1

IfFldID fIfNot IfConstID

----------- ------ ----------

-10 0 -42

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- -----------

-11 0 0 1 -42

String

----------------------------------------------------------------

Component

SubArea

‘Redmond\pstest’的成员不能在根节点在节点12的产品树的分支中创建不是‘Folder’(文件夹)类型的节点

Deny Admin TO REDMOND\pstest FOR X(a Folder and under)UNLESSNode Type ID is Folder(禁止REDMOND\pstest对X(文件夹及以下)的管理，除非节点类型ID是文件夹)

fGrantAdmin fDenyAdmin

----------- ----------

1

fGrantRead fDenyRead

---------- ---------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

0 0 0

fEditable TreeID PersonID fUnless

---------- ----------- ----------- --------

0 12 199 1

IfFldID fIfNot IfConstID

----------- ------ ----------

-10 0 -42

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- -----------

-11 0 0 1 -42

String

------------------------------------------------------------------

Component

SubArea

标题是对每个人的强制字段

Deny Write FOR Domain Accounts TO Everywhere WHEN Title in Emptyvalue(当标题为空值时禁止域账号对任何地方的写)

fGrantAdmin fDenyAdmin

----------- ----------

0

fGrantRead fDenyRead

---------- ---------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

0 0 1

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

0 0 -1 0

IfFldID fIfNot IfConstID

----------- ------ -----------

0 0 0

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- ------------ ------- -----------

22 0 0 1 -100

任何人都可读其所打开的任何项目

(可编辑)Grant Read FOR Domain Accounts TO Everywhere WHENOpened By in Name of domain account doing this(当由……打开是正在执行读的域账户名称时，准许域账号对任何地方的读)

fGrantAdmin fDenyAdmin

----------- ----------

0

fGrantRead fDenyRead

---------- ---------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

0 0 0

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

1 0 -1 0

IfFldID fIfNot IfConstID

----------- ----- -------------

0 0 0

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- -----------

33 0 0 1 -102

War是动态列表

(可编辑)Suggestion FOR Domain Accounts TO Everywhere(Unused)WHEN WAR NOT in Okay WAR(当WAR不是好的WAR时，对域账号到任何地方(未被使用)的建议)

fGrantAdmin fDenyAdmin

----------- ----------

0

fGrantRead fDenyRead

---------- ---------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

0 1 0

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

1 0 -1 0

IfFldID fIfNot IfConstID

----------- ------ -----------

0 0 0

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- ------------

65 1 0 1 177

String

----------------------------------------------------------------

Done

Approved

Investigate

Consider

Must Fix

Tracking

Needed

Not Needed

Needs Updating

Pending

Remove

当状态不是封闭时必须清空封闭的日期

Deny Write FOR Domain Accounts TO Everywhere UNLESS Status NOT isClosed＝＞Closed Date in Empty value(禁止域账户对任何地方的写，除非状态NOT是封闭的＝＞封闭日期是空值)

fGrantAdmin fDenyAdmin

----------- ----------

0

fGrantRead fDenyRead

--------- --------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

0 0 1

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

0 0 -1 1

IfFldID fIfNot IfConstID

----------- ------ -----------

23 1 5

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- -------- -----------

46 0 0 1 -100

“Redmond\markradp”分布列表中的所有域用户可在任何地方做任何事

(可编辑)Grant Read Grant Write Grant Admin FOR REDMOND\markradpTO Everywhere WHEN Always(总是许可REDMOND\markradp对任何地方的读、写和管理)

fGrantAdmin fDenyAdmin

----------- ----------

0

fGrantRead fDenyRead

----------- ---------

0

fGrantWrite fSuggestion fDenyWrite

----------- ----------- ----------

1 0 0

fEditable TreeID PersonID fUnless

--------- ----------- ----------- -------

1 0 1 0

IfFldID fIfNot IfConstID

----------- ------ ----------

0 0 0

ThenFldID fThenNot fThenLike fThenIn ThenConstID

----------- -------- --------- ------- -----------

0 0 0 0 0

工作项类型定义语言

概述……………………………………………………………………………………………55

范围……………………………………………………………………………………………55

相关文档………………………………………………………………………………………55

情形……………………………………………………………………………………………55

工作项类型概览………………………………………………………………………………56

高级WITD结构…………………………………………………………………………………57

字段……………………………………………………………………………………………58

<FIELD>定义 ……………………………………………………………………………58

字段名称…………………………………………………………………………58

字段引用名称……………………………………………………………………59

字段类型…………………………………………………………………………61

字段报告…………………………………………………………………………62

字段帮助文本……………………………………………………………………………63

字段规则…………………………………………………………………………………63

字段约束…………………………………………………………………………64

字段列表…………………………………………………………………………………66

字段列表项………………………………………………………………………66

全局列表…………………………………………………………………………66

字段列表类型……………………………………………………………………67

列表项扩展………………………………………………………………………68

示例…………………………………………………………………………68

在合成中使用列表类型…………………………………………………………70

字段默认值………………………………………………………………………71

字段条件…………………………………………………………………………72

<WHEN*>、<DEFAULT>和<COPY>规则的预期行为………………………………73

条件字段规则属性………………………………………………………………………74

引用用户和组……………………………………………………………………………75

工作流程………………………………………………………………………………………75

概览………………………………………………………………………………………75

转移安全…………………………………………………………………………………76

由状态、转移或原因界定字段规则的范围……………………………………………77

状态转移动作(状态转移自动化)………………………………………………………78

标识适当的状态转移……………………………………………………………78

使转移自动化…………………………………………………………………………78

转移动作细节…………………………………………………………………………79

自动转移出错检查和WIT作者建议 …………………………………………………79

规则评估顺序…………………………………………………………………………………80

特殊规则限制…………………………………………………………………………………81

无意义的规则…………………………………………………………………………81

引起麻烦的规则………………………………………………………………………82

表单……………………………………………………………………………………………82

<Layout>、<Group>和<Column> ……………………………………………………82

控件……………………………………………………………………………………83

TFStructureControl…………………………………………………………………83

所有元素………………………………………………………………………………84

示例……………………………………………………………………………………87

WITD本地化和全局化…………………………………………………………………………89

V1删剪列表……………………………………………………………………………………90

字段类型………………………………………………………………………………91

字段规则………………………………………………………………………………91

字段索引………………………………………………………………………………92

概述

此文档定义工作项类型定义(WITD)语言。

将通过手工授权XML文件或使用工作项类型编辑器来定义工作项类型。

范围

此文档定义工作项类型定义语言。它并不定义如何使用此语言。用法见工作项类型规则和顾客情形规范。

相关文档

工作项类型

●工作项类型的细节。

工作项类型规则和顾客情形

●使用工作项类型定义语言的以顾客为中心的情形。

公文包项目管理

●管理工作项类型的细节。

Whidbey故障

●供驻厂使用(狗食(dogfooding))的工作项类型定义。

情形

预期WITD语言支持以下情形。

新团队项目

顾客想要创建新团队项目(TP)。他们通过团队项目创建向导来实现此目的。作为创建TP的一部分，他们选择“方法”(例如，MSF Agile)。每个“方法”标识工作项类型集。当完成时，TP将把由该方法所定义的工作项类型集包含在数据库中，且用户将能够创建那些类型的新的工作项实例。

第三方工作项类型

合作者想要用Visual Studio Team System工具来帮助他们的顾客在SEI-CMM过程中达到较高的等级。或者***集成者决定要用Visual Studio Team System工具来将他们所推广的开发方法自动化。合作者用WITD语言设计工作项类型集。合作者/***集成者通过web、或在CD上等将这些WITD XML文件投放给他们的顾客。

购买这些方法的顾客将这些工作项类型打包成Team Foundation服务器上的团队项目的一个部分。

在Team Foundation服务器之间移动工作项类型

Adventure Works的部门A已经使用了Visual Studio Team System一段时间。他们有数个使用自定义工作项类型的团队项目。他们还创建了用来跟踪项目问题的新的工作项类型。在另一个部门，即部门B中，他们建立起新的Team Foundation服务器。部门B听说了部门A中发生了好事情，并决定也使用Issue(问题)工作项类型。部门A中的团队项目管理员将Issue导出为XML文件。部门B里的TP管理员将Issue工作项类型导入到她的团队项目中。

工作项类型概览

以下是WITD语言的关键设计目标：

●可扩展以容纳将来的功能

●简单-基本语言应当能被简单地理解和产生

●人类可读-用户应当能够输入简单的WITD并让它们生效，而无须求助于特定的设计工具。

工作项类型是由以下高级项目组成的：

名称；它在团队项目中必须是唯一的。例子包括bug(故障)、feature(特征)、requirement(要求)、task(任务)。

描述；它是帮助文本，当需要项目中的工作项类型的概览时可在运行时使用它。

字段列表；它定义了工作项类型的相关字段集。字段定义对Team Foundation服务器是全局的。每个工作项类型包含Team Foundation工作项跟踪所需的核心字段集。

工作流程；它定义有效状态和合法转移、以及谁被允许执行这些转移的集合。

字段规则集；它定义当工作项遍历其状态转移图时对字段和字段值的约束。

表单；它定义如何显示和如何由终端用户操纵相关字段。

可任选地，全局列表集；可为多个字段重复使用的值(例如，可用于found on OS(在OS上找到)、fixed on OS(在OS上修复)、supported on OS(OS上支持)的操作***)的命名列表

把工作项类型的范围界定到团队项目。不存在任何全局工作项类型。

高级WITD结构

以下是工作项类型定义(WITD)的高级结构。

<DESCRIPTION>Bug work item types are used to track defects with the code.

</DESCRIPTION>

</GLOBALLISTS>

</FIELDS>

</WORKFLOW>

<FORM>

</FORM>

</WORKITEMTYPE>

</WITD>

<WITD>标号封装了工作项类型定义。以后的版本可能会改变XML模式。更新将是后向兼容的。

工作项类型名称在给定团队项目中必须是唯一的。此名称将在运行时使用。例如，用户选择bug(故障)、task(任务)、risk(风险)或issue(问题)。

描述是在运行时当需要项目中的工作项类型的概览时可使用的帮助文本。例如，想要理解risk和issue之间的不同。

此文档的其余部分详细覆盖<GLOBALLISTS>、<FIELDS>、<WORKFLOW>部分。当前在工作项类型表单XML中覆盖<FORM>部分。

字段

在XML的<FIELDS>部分中定义给定工作项类型的相关字段。除了核心字段以外，必须首先在<FIELDS>部分中声明在定义(诸如在 <FORM>和 <WORKFLOW>中)部分中的其它地方被引用的每个字段。

字段含有以下信息：名称、引用名称、类型、帮助文本、以及行为或约束集。未明确地列出的非核心字段对于此工作项类型的所有实例将是隐含为空和只读的。

</FIELDS>

<FIELD>定义

字段由名称、引用名称和类型定义。还可设置字段为具有各种报告行为。

</FIELD>

字段名称

字段名称是Team Foundation服务器的字段所用的唯一的用户可见的句柄。这是为了鼓励给定TFS中所有团队项目和工作项目类型上的一致性。在构造查询或在工作项类型编辑器中工作时使用字段名称。在WITD的工作流程或表单部分中被引用的任何字段都必须具有<FIELD>元素，它在<FIELDS>部分中定义该字段。

字段可由TFS管理员重命名，例如从“Title”到“Headline”。因为字段可被重命名，所以对集成而言，用名称来引用字段不是个好主意。因此，集成和字段的内部表示应当使用字段引用名称而不是依靠字段名称本身。

字段名称的长度可以是42个unicode字符。被允许的Unicode字符类别是：

●小写字母{Ll}

●大写字母{Lu}

●标题字母{Lt}

●其它字母{Lo}

●数字{Nd}

●空格{Zs}

我们可考虑在beta 2后允许以下这些

单次出现的连接符标点{Pc}

单次出现的虚线标点{Pd}

修饰符字母{Lm}

Unieode代理

修剪字段名称的前导和后续空格。

字段引用名称

WITD语言和WIQL(工作项查询语言)的一个重要目标是使这些定义在TFS之间可移植。也很重要的是使第三方集成能够找到和引用某些字段。因为可改变字段名称，所以它们不适宜这一目的。

有人可能认为字段ID是最适宜于这一目的的；但是，因为可由用户添加自定义字段，所以我们不能确保字段ID从一个TFS到另一个的TFS的唯一性。

因此，我们引入字段引用名称的概念。和命名空间在.NET框架中是唯一的一样，字段引用名称是全局唯一的。

因而字段引用名称是全局唯一的，并且不能被重命名。因此，如果把字段名称“Title”改为“Header”，则字段引用名称将保持不变。

为与.NET命名空间惯例保持一致，我们将定义两个命名空间供我们自己使用：System和Microsoft。System命名空间将包括Team Foundation***功能强制的所有核心字段。将使用Microsoft命名空间来定义由Microsoft所定义的盒外工作项类型(out-of-the-box work item)所需的所有字段。顾客和合作者可为自定义工作项类型创建他们自己的字段命名空间。

System示例包括：

System.Id

System.Title

System.CreatedBy

System.CreationDate

System.ChangedBy

System.ChangedDate

System.State

System.Reason

Microsoft示例包括：

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

TFS将不会阻止顾客创建他们自己的System.X或Microsoft.X字段。但是，这是强烈不建议的，并且这可能阻碍TFS功能。

字段引用名称的长度可以是255个字符。所允许的字符是：

●小写英文字母a-z

●大写字母英文字母A-Z

●数字0-9

●句号“.”

●连字符“-”的单次出现

●下划线“_”的单次出现

修剪掉字段引用名称的前导和后续句号“.”。它们必须包含至少一个“.”。

WITD中的所有规则和表单必须通过引用名称来引用字段以使定义的可移植性最大化。

字段类型

字段的类型定义用户期望存储在该字段中的数据的种类和大小。每个TFS中，字段可具有一种，并且仅一种类型。这是为了鼓励组织在各项目和工作项类型上使用公用字段。

合法的字段类型是：

●String(串)

用于单句和短串字段。自由地在查询过滤器和结果列表中使用。多至255个unicode字符。

●Integer(整数)

用于整数值。自由地在查询过滤器和结果列表中使用。32位有符号整数。

●Double(双精度)

用于浮点值。自由地在查询过滤器和结果列表中使用。

●DateTime(日期时间)

表示存储在UTC中的一特定时刻，并需要调整到本地时区。

●PlainText(纯文本)

用于诸如描述等事物的长文本字段。

●HTML

用于诸如描述等事物的长文本字段。这与PlainText字段不同之处在于它被强类型化为HTML。此字段允许信息更为丰富的显示。

此外，仅为某些核心字段支持以下字段类型。这些字段类型不能被用于自定义字段。

●TreePath(树路径)

用于存储CSS区域或迭代路径的串字段。仅为核心字段System.AreaPath或System.IterationPath支持此字段类型。

●History(历史)

用于显示对话线程和修订历史的长文本字段。仅为核心字段System.History支持此字段类型。

字段报告

一些字段值对于报告目的特别有用。WITD允许为这些字段指定特殊属性。此属性是可选的。如果没有指定属性，则不会将字段数据导出到数据仓库。

将把具有可报告的属性的字段导出到数据仓库，并能包括在报告中。可报告的属性取以下三个值之一：

1. dimention

仅用于integer、string或datetime字段。数据进入仓库和多维数据集，从而它可被用来过滤报告。无须指定Formula(公式)属性，或如果被指定则仅可取“none”(无)值。

<FIELD refname="MyCorp.Field"name="MyReportableField"type="String"

reportable="dimension">

2. detail(垃圾或退化的dimension)

仅用于integer、double、string或datetime字段。数据进入仓库，但不进入多维数据集。不应指定Formula属性。

<FIELD refname="MyCorp.Field"name="MyReportableField"type="String"

reportable="detail">

3. measure

仅用于integer和double字段。聚集由formula属性定义聚集。如果没有指定任何formula属性，则默认的聚集是sum。

<FIELD refname="MyCorp.Field"name="MyReportableField"type="Integer"

reportable="measure"formula="avg">

formula属性使用户能够选择要如何聚集measure。如果未指定该字段的可报告属性，则忽略formula字段。formula属性有七个可能的值：

sum

count

distinctcount

avg

min

max

可报告的设置在整个TFS上是全局的。向工作项类型重新供应字段的不同设置将不会改变该字段的可报告的值。

在任何时候，将允许WIT作者通过不指定报告属性来禁用字段的报告。用户随即可通过重新指定这些属性来重新启用字段的报告(但他们不能将这些值从原始设置改变)。

这意味着当被禁用时，适配器将不再会把该字段复制到数据仓库中。数据仓库将包含较早的值(如果先前被启用)，而报告将能够引用该字段(可能带有不一致的数据)。

这将使管理员能够在绝对不需要字段时避免对适配器不必要的使用。

将由***设置核心字段的报告属性，并且不能改变。

字段帮助文本

字段还具有帮助文本，在运行时使用它来指导用户应向该字段中输入什么。字段帮助文本是可选的。和字段名称及类型不同，把字段帮助文本的范围界定到TP中给定的工作项类型。这允许每个TP定义对使用任何给定工作项类型的任何给定字段定义它们自己的方针。

字段帮助文本的长度可以是255个字符。

<HELPTEXT>Enter a brief description of the work item</HELPTEXT>

</FIELD>

注意，没有全局帮助文本，如果WITD不为文本字段提供帮助文本，

则将没有任何帮助文本可用。这包括核心字段。

字段规则

字段规则定义字段上的行为和约束，并且是在<FIELD></FIELD>块内所列出的附加元素。

例如，如果需要一字段，则XML将表现为：

<HELPTTEXT>Enter the business priority of the bug</HELPTEXT>

</FIELD>

注意，字段规则的范围被界定到特定团队项目中一项工作项类型，

没有任何全局规则或全局工作项类型的概念。

已把字段规则分组到以下子部分中：

●约束

●列表

●默认值

●条件

字段约束

字段约束定义字段值的要求。

注意，其中一些在这里所描述的全局上下文中没有意义。稍后在此说明书中，我们将谈及字段规则的范围将如何被界定到某些状态、状态转移及原因。

要求此字段为非空。可按照要求标记所有字段类型。

不能修改该字段。

在提交时将清除该字段值，且不会允许用户输入任何值。主要在状态转移期间使用。

一旦字段在提交后有了值，则不再能修改它。但是可使用<EMPTY/>约束来将其清除并在稍后再次填充。主要在状态转移期间使用。

一旦字段有了值，就不能清除或清空它。

该字段值不能和字段“Foo”中的值具有相同的值。例如，两个字段不能同时为空，或是“code reviewer”字段值不能和“assigned to”字段值相同。这应用于字段或类似的类型。对PlainText或HTML字段不支持。

该字段值必须是作为TFS Everyone成员的有效用户。注意：如果未指定<REQUIRED/>规则，则此字段将接受空值。用于String字段类型。

注意，对于此版本，工作项字段不区分不同域中的用户身份。因此，当将“redmon/jsmith”和

“tokyo\jsmith”输入到具有<VALIDUSER/>规则的字段中时，它们被相同对待。

但是，域的确区分Team Foundation中其他地方的用户身份。

使日期字段生效。Mustbe值或可是“after now”或可是“not after now”。“afternow”是在当前时间之后。“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匹配。匹配标号支持空值。

可指定多个<MATCH>元素。如果只有一个元素成功，则该字段具有合法值。

字段列表

使用字段列表来管理字段的捡取列表。有三种类型的捡取列表：被允许的值、被建议的值、及被禁止的值。字段列表可用于String、Integer和Double字段类型。

字段列表项

字段列表是由单个项组成的。例表必须包含至少一个项。使用<LISTITEMvalue=””>元素来指定列表中的项。被指定的值可以仅仅是串或可指定用或户组。该值不能为空。

此外，列表项可通过包括一个或多个<GLOBALLIST>元素来共享。

列表项基于TFS的现场而按字母顺序分类。

全局列表

在定义工作项类型时，将发现一些字段共享值的同一集。通常此共享是在若干工作项类型上，或甚至在若干个团队项目上。其中一些列表可能频繁地改变(例如，从每晚的建立来构建号码)。

为了要求管理员更新这些列表，在许多情况中频繁更新不是理想的。全局列表解决这一问题。

全局列表不过是全局地(TFS范围内)存储和使用的<LISTITEM>的集合。这些列表可用于诸如“Operating System”、“Found in Build”、“Fixed in Build”等字段。

全局列表具有名称。这些名称在整个TFS上必须是唯一的。全局列表可作为工作项类型定义的一个部分来定义和管理，或通过OM编程地管理。全局列表名称不能包含“\”字符。

用户可手动和编程地进行以下操作：

●创建列表

●添加列表值

●移除列表值

●取出TFS中全局列表的列表

●取出列表中的内容

如何创建及管理全局列表的信息见创作工作项类型实验

外部数据源和全局列表

在必须从某个第三方***派生出列表的情形中也可以使用全局列表。例如，假定公司维护单独的顾客数据库。当输入了顾客发现的一故障时，就有需要该顾客的名字的“Found by Customer”字段。对于这个版本，不支持允许在运行时动态查询顾客数据库以获得顾客名字列表的程序访问。动态能力的近似将是对OM编写代码以在每当其顾客数据库中的顾客列表被修改时更新全局列表。

项目管理员和TFS管理员可修改全局列表的内容。

如果全局列表尚不存在，则导入全局列表将创建一个全局列表。如果列表存在，则更新将不过是更新值的列表。如果WIT中的任何字段引用全局列表，则全局列表将随其内容一起成为被导出的XML的一部分。

字段列表类型

枚举的值列表将表示为下拉列表。用户必须拣选这些值中的一个。

枚举的值列表将表示为下拉列表。用户可选择这些值中的任何一个。用户还可输入这些建议以外的他们自己的值。

如果字段包含任何被禁止的值，则用户不能保存工作项。通常当先前允许一个值但目前不再有效时使用被禁止的值。

示例：

<HELPTEXT>Enter a brief description of the work item</HELPTEXT>

</FIELD>

<HELPTEXT>Enter the severity of the problem</HELPTEXT>

</ALLOWEDVALUES>

</FIELD>

列表项扩展

列表类型元素<ALLOWEDVALUES>、<SUGGESTEDVALUES>、

<PROHIBITED VALUES>具有两个可选属性expanditems和filteritems。

expanditems=true/false，默认为true

当设置expanditems为true时，将递归地展开表示分组或全局列表的列表项。即分组将使其子分组展开，并使子分组的子分组展开。在展开以后，表示分组的列表项将包括分组和用户作为列表项值。如果把expanditems设为false，则将不执行任何分组或全局列表展开。

filteritems=”excludegroups”

当此属性/值对出现时，评估所有列表项，且将移除任何分组。这是在只想要不带任何分组的用户列表时使用的。

注意：将来可以提供其他过滤器

示例

[Project]\Business Analysts是以下商务分析员用户的团队项目分组：jsmith、bbob、dmiller

Redmond\MyTeam是具有以下3个子分组的分组：Development、Test、PM。每个子分组分别具有一个用户“devuser”、“testuser”、“pmuser”。Redmond\MyTeam还具有一个用户“Juser”。

Redmond\MyReports是具有用户“userone”、“usertwo”、“userthree”和一个子分组“MyRemotes”的分组，其中该子分组具有“userfour”和“userfive”。

BoolValues是具有两个条目“true”和“false”的全局列表。

例1

串值、全局列表及分组，其展开是开启的，且分组已被过滤掉。

</ALLOWEDVALUES>

该字段的捡取列表将显示以下这些值：

string，true，false，jsmith，bbob，dmiller

例2

未执行任何分组过滤。

</ALLOWEDVALUES>

该字段的捡取列表将显示以下值：

string，true，false，juser，juser2，devuser，testuser，pmuser，Development，Test，PM

例3

未执行任何列表项展开。

</ALLOWEDVALUES>

该字段的捡取列表将显示以下这些值：

string，MyTeam，MyReports

注意：不显示全局列表名称和内容

例4

排除分组且没有展开

</ALLOWEDVALUES>

该字段的捡取列表将显示以下这些值：

string

注意：MyTeam是被排除且未被展开的分组，而BoolValues是全局列表，

因而既未被展开，也未被示出

在合成中使用列表类型

为单个字段指定多种类型的列表是可能的。这一部分定义如何确定最终的项列表。

合法值的确定

字段允许的合法值是通过从{集合A}减去{集合P}而获得的。如果{集合A}没有任何条目，则{集合A}被视为是所有可能的值(即，没有定义任何被允许的值，所以除了在{集合P}中特别标识的那些值以外所有的值都是被允许的)。{集合S}在确定字段的合法值中不起到任何作用。

捡取列表值的确定

如果{集合S}与{集合A}没有任何条目

结果：空列表

如果{集合S}有条目而{集合A}没有任何条目

结果：通过从{集合S}减去{集合P}所获得的值

如果{集合S}与{集合A}有条目

结果：通过以下步骤获得的值的列表：

a.使{集合A}与{集合S}相交以获得{中间集合I}

b.从{中间集合I}减去{集合P}

如果{集合S}没有条目而{集合A}有条目

结果：通过从{集合A}减去{集合P}的得到的值的列表

指定多个列表

如果在给定时间点指定多个<ALLOWEDVALUE>(例如，WIT的<ALLOWEDVALUE>集加上状态细节)，则取这多个集合的交集作为最终的{集合A}。

如果指定多个<PROHIBITEDVALUES>或<SUGGESTEDVALUES>，则分别取每一种的并集作为最终的{集合S}或{集合P}。

字段默认值

字段默认值是处理字段值如何被自动填充的规则。有三种类型的元素<DEFAULT>、<COPY>和<SERVERDEFAULT>。

当用户创建新工作项或编辑工作项时，<DEFAULT>元素将在字段为空的情况下填充该字段。如果字段已经有值，则默认值规则将被忽略。

<COPY>

当用户创建新工作项或编辑工作项时，<COPY>

与在编辑开始时填充值的<DEFAULT>和<COPY>不同，<SERVERDEFAULT>规则在工作项被提交给数据库时填充值。这在保存时在后端发生，且用户不能覆盖该值。字段在表单上将表现为只读。此规则将被用于如“Last Changed By”和“LastChanged On”等字段以支持安全审查跟踪。

以上每个标号都可取标识值源的from=”<fromtype>”。取决于<fromtype>，接下来可有其它属性。

有效的from(来自)类型是：

●value(值)

从指定的串常量取值。需要value=”xxx”属性。仅用于<COPY>和<DEFAULT>规则。

●field(字段)

从指定字段取值。被复制的值是来自最近成功提交的修订的目标字段的值。需要field=”xxx”属性。默认如果所指定的from字段为空，则不执行任何任务。仅用于<COPY>和<DEFAULT>规则。

●clock(时钟)

使用当前日期和时间作为值。不需要任何其它属性。用于DateTime字段。对于<COPY>和<DEFAULT>规则，此值是从本地机器时钟时间取得。对于<SERVERDEFAULT>，此值来自提交时的服务器时钟。

●currentuser

使用当前用户的短用户名作为值。不需要任何其它属性。用于string字段。

这里是指定默认优先级的示例：

<HELPTEXT>Enter the severity of the problem</HELPTEXT>

</ALLOWEDVALUES>

</FIELD>

这是清除Status(状态)字段的示例。

</FIELD>

这是保存最近改变工作项的人的用户名的示例。

<HELPTEXT>The user name of the person who last modified this bug</HELPTEXT>

</FIELD>

这是默认当前日期、但允许用户改变它的示例。

<HELPTEXT>Defines when a bug was found.</HELPTEXT>

</FIELD>

注意：对于如“Won’t Fix”等包含撇号的值，需要在XML中使用双引号。例如：

字段条件

还有其它用于从属捡取列表并用于提供详细的安全或自定义行为的从句。

当字段xxx有值yyy时，此元素内的任何事物都是适用的。

注意：value属性是大小写不敏感的，因此，如果xxx持有“ABC”而value＝“abc”，

则这两个是匹配的。

这是从属捡取列表的示例。

</ALLOWEDVALUES>

</WHEN>

</ALLOWEDVALUES>

</WHEN>

</FIELD>

这是当顾客报告故障时需要性的改变的示例，必须输入顾客严重程度。否则，不需要顾客严重程度。

</ALLOWEDVALUES>

</WHEN>

</FIELD>

当字段xxx有值而该值不是yyy时此元素内的任何事物都适用。

</WHENNOT>

当用户已修改字段xxx时此元素内的任何事物都适用。

<FIELD refname="MyCorp.StateDate"name="Date Of Last State Change"

type="DateTime">

</WHENCHANGED>

</FIELD>

</WHENCHANGED>

</FIELD>

<WHEN*>、<DEFAULT>和<COPY>规则的预期行为

此部分概述了当使用<DEFAULT>、<COPY>和<WHEN*>规则时预期的行为和交互。

1)用户示意要创建新工作项或编辑现有工作项。

2)填充字段默认值。对于所有字段，使用在<WHEN*>规则之外的任何<DEFAULT>规则。

3)复制字段值。对于所有字段，使用<WHEN*>从句之外的任何<COPY>规则。

4)对于具有匹配的<WHEN>规则的所有字段，在里面首先执行<DEFAULT>规则，然后执行<COPY>规则。

5)对于具有匹配的<WHENNOT>规则的所有字段，在里面首先执行<DEFAULT>规则，然后执行<COPY>规则。

6)对于从#1起其值已经改变、且具有<WHENCHANGED>规则的所有字段，在里面首先执行<DEFAULT>规则，然后执行<COPY>规则。

7)允许用户开始编辑

8)用户改变字段值并离开该字段

9)为该字段触发任何匹配新值的<WHEN>规则

10)为该字段触发任何匹配新值的<WHENNOT>规则

11)为该字段触发任何匹配新值的<WHENCHANGED>规则

12)将编辑能力返回给用户

13)用户示意将改变保存到数据库

14)对于所有字段，直接或间接地在<WHEN>或<WHENNOT>规则下执行为该字段定义的<SERVERDEFAULT>操作。

条件字段规则属性

有时想要把字段规则的范围界定到特定的组或用户。可添加属性“for”和“not”来支持此范围界定。在若干标号上使用这些属性来使它们专属于单个BIS组或专属于除单个BIS组中的人以外的任何人。拒绝优先于准许。

for和not属性是可选的，并不应有空值。

注意：在此版本中，我们不支持将字段规则的范围界定到特定用户。

这里是一些示例：

</FIELD>

</FIELD>

</FIELD>

注意，如果想要多个组，则需要创建超TFS组，其中包括想要使用的组的集合。

引用用户和组

诸如字段列表项、条件字段规则属性和转移安全等若干规则引用用户和组。WITD语言支持以下用于引用用户和组的令牌。

[Global]

使用此令牌来引用服务器范围的TFS组。

</FIELD>

[Project]

使用此令牌来引用团队项目范围的TFS组。

</FIELD>

Domain(域)

使用域限定符来引用域用户或组。注意，一些规则仅支持组，而不支持引用域用户。

必须通过以上令牌中之一来限定所有用户和分组。例如，以下XML是无效的，因为它没有用有效令牌限定所指定的组。

</FIELD>

工作流程

概览

WITD的工作流程部分描述有效状态、合法转移和转移的合法原因。原因标识用户为何从一个状态改变到另一个状态。

工作流程部分表现为如下：

</STATES>

</TRANSITION>

</REASONS>

</TRANSITION>

</TRANSITIONS>

</WORKFLOW>

必须定义恰好一个从无(即，“”)到命名状态的转移。这标识了新工作项的初始状态。每个转移必须定义恰好一个用<DEFAULTREASON>元素指定的默认原因。

工作项的最小工作流程必须包含一个状态、一个转移以及一个默认原因。以下是可定义的最小工作流程。

</STATES>

</REASONS>

</TRANSITIONS>

</WORKFLOW>

注意：状态名称和原因大小是写敏感的。

转移安全

必须指定两个状态间所有合法的转移。如果没有指定任何转移，则默认为不允许执行此转移。

此外，可在工作流程的转移元素中可选地使用两个属性“for”和“not”，以推敲允许谁执行转移。拒绝优先于允许。如果没有指定其中任何一个属性，则允许任何人进行此转移(特别是可修改该工作项的任何人)。

这里是规则的示例，该规则将转移的完成限制于除了刚刚加入团队的新测试员以外的所有项目测试员。指定单个用户身份也是可能的。

<TRANSITION from="Resolved"to="Complete"for="AllTesters"

not="NewTesterS">

</TRANSITION>

由状态、转移或原因界定字段规则的范围

我们迄今所定义的字段规则标识字段名称、其类型、帮助文本、以及工作项类型宽广的行为。即，该字段的行为不考虑故障的状态。例如，无论如何总是需要字段。

还可把字段规则的范围界定到某些状态、转移或甚至原因。应用于任何给定字段的完整规则集是从以下四个子集添加而成的：工作项类型专属子集、状态专属子集、转移专属子集、以及原因专属子集。

无论在其状态模型中是否有工作项都应用工作项类型宽广规则。例如，

<REQUIRED/>规则进行以下检查：

“MyField Value”!=NULL

在工作项实例处于某个状态时把状态专属规则的范围界定到该工作项实例。因此检查是：

State field value==“MyState”&&“MyField Value”!=NULL

把转移专属规则的范围界定到正在经历某个转移的工作项。对这些规则的检查更加复杂：

State field value==“ToState”&&“Previous State Before Edit/New”==

“FromState”&&“MyField Value”

把原因专属规则的范围界定到特定转移上的特定原因。对这些规则的检查是最为复杂的：

Reason field==“MyReason”&& State field value==“ToState”&&

“Previous State Before Edit/New”==“FromState”&&“MyField Value”!=

NULL

范围被界定的字段规则是通过在<STATE>、<TRANSITION>和<REASON>元素内使用<FIELDS>和<FIELD>元素来实现的。

注意，当列出工作流程中的字段时，应仅指定字段引用名称。

下面的示例定义以下规则：当故障处于活动状态时，不允许修改顾客严重程度字段。

</FIELD>

</FIELDS>

</STATE>

状态转移动作(状态转移自动化)

顾客和合作者可能想要基于在团队***中的其它地方发生的事件、或是在团队***本身以外(例如，调用跟踪工具)发生的事件而使工作项在状态之间自动地转移。为通过其它***(包括我们自己的***)支持工作项的自动转移，我们扩展工作项类型模型和OM。让我们通过例子来参见这些扩展。

一工具想要在用户登记改变以后将工作项自动转移到“resolved”(已解决的)。但是，作为集成供应商，你不知道WIT作者把什么状态声明为“resolved”。它可以是解决的、关闭的、完成的、测试准备就绪的、包括在建立中等等。一个选择是要求所有WIT作者包括明确地命名为“Resolved”的状态。但是，这太过于限制性，并且从I18N的角度来看非常糟糕，因为它不允许状态的本地化。作为替代，集成者将在其***中声明一动作(例如，“checkin”(登记)、“complete”(完成))，它将引入工作项的自动转移。然后WIT作者在适当的转移上声明此动作。

标识适当的状态转移

例如，Team Foundation版本控制***需要在登记时支持工作项的自动转移。定义一“microsoft.vsts.actions.checkin”动作。假定WIT作者定义“Defect”工作项类型，它具有对应于开发者正在进行改变时的称为“Working”的状态，以及称为“Ready To Build”的另一个状态，该状态标识何时已声明了缺点准备就绪供开发者每晚建立。作者可通过以下声明，以在登记操作期间将工作项从状态“Working”自动转移到“Ready To Build”：

</ACTIONS>

</TRANSITION>

使转移自动化

对于集成者而言，定义动作不过是第一步。当工具正在执行该动作时，它们必须进行转移。例如，假定Team Foundation版本控制***正在执行登记操作并且想要执行自动转移。版本控制***可通过OM调用来查询工作项跟踪***，以找出它应将相关联的工作项转移到的正确的“To”状态。

nextState＝workiteminstance.GetNextState(“Microsoft.vsts.actions.checkin”)；

如果工作项实例的当前状态具有对应于指定动作的动作条目，则它返回“To”状态。如果没有，则返回值为Null。

转移动作是供想要执行自动转移的合作者/集成者使用的帮助程序能力。一旦集成得到下一个状态，则由它们决定从该状态进行什么操作。例如，没有保留什么转移动作引起特定状态转移发生的记录-仅记录转移的正常原因。如果需要此种跟踪，则建议WIT作者标识特定值作为合法原因，并在转移期间将此值自动设置到Reason(原因)字段中。

转移动作细节

动作是可选的。集成应当从容地处理Null返回值。即：a)不会失败且b)留下因为寻找动作“xyz”但没有找到而没有自动转移的一些痕迹/日志，联系WIT作者添加此动作。

对于每个WIT，对于“From State/Action”对而言动作必须是唯一的。即，WIT作者不能为同一个动作指定多个“To”状态。

但是，支持同一个转移上的多个动作，以允许多个自动转移的集成。例如：

</ACTIONS>

</TRANSITION>

动作名称是不可本地化的。

动作名称应当与字段引用名称遵守同样的引用命名空间惯例。这避免供应商/顾客之间的动作名称冲突。但是，这将不是由工具来强制执行的。

Microsoft VSTS将使用“Microsoft.VSTS.Action.<your action>”。

自动转移出错检查和WIT作者建议

集成者有两种类型的自动转移可以尝试。第一种是由于某个用户示意而发生的自动转移，第二种是作为无人照管的自动化(例如，每晚的建立)发生的自动转移。在第一种情形中，可假定用户将会在场来处理可能出现的任何规则相关的问题，并应支持WIT作者可添加你的集成所不知的新的需要的字段这一事实。为实现此目的，在进行自动转移以后，需要检查WIT看是否有规则违反，并且如果发现有任何规则违反，则弹出该表单以便用户解决。

对于第二种情形，不能处理任何这些问题，因为没有用户在场来解决它们。在此情形中，集成应当从容地在出错日志中留下已尝试自动转移及其为何失败的一些指示。

当然，理想的情形是当自动转移在没有用户干预的情况下发生时。WIT作者可做一些事情来支持此情形。首先，他们可总是指定默认原因。如此，集成者和终端用户都不需要指定转移的原因。第二件事是确保转移所有必需的字段都有默认值。如此，自动填充所有适当的信息。

规则评估顺序

一般而言，规则是按照反映规则范围的顺序来执行的。例如，如果把规则的范围特别界定到当前状态，则在把规则的范围界定到全局之前调用它。在下例中，工作项类型对字段Status(状态)有全局的<COPY>规则，以及把范围界定到状态“Active”(活动的)的<COPY>规则。在此情形中，当工作项进入“Active”状态时，首先将值“Active”复制到字段Status中。然后，这将被复制到字段Status的空串的全局复制所覆盖。

</FIELD>

...>

</FIELD>

</FIELDS>

</STATE>

特别地，基于工作流程范围的执行顺序如下：

1.具有原因的状态转移

2.状态转移

3.状态

4.非状态范围

在以上所示的每个范围之内，规则进一步按其在条件内的范围排列。此顺序如下：

1. WHEN从句

2. WHENNOT从句

3.非WHEN/WHENNOT从句

最后，在以上每一个条件范围内，单个规则如下排序。

1.<DEFAULT>规则

2.<COPY>规则

3.除了<SERVERDEFAULT>规则以外所有其它规则，仅在保存工作项时评估<SERVERDEFAULT>规则。

当创建新工作项、打开现有工作项、以及在用户改变可能触发规则的字段时，对规则进行评估。当用户试图保存工作项时，评估所有规则以寻找规则冲突。如果有任何规则冲突，则阻止保存。

特殊规则限制

这个部分处理在提供和使用时可能引起问题的特殊情形规则和规则组合。把这些分成三个类别：无意义的、引起麻烦的、不合法的。以下讨论前两个。不合法的规则组合是引起***严重问题的那些规则组合。由***来防止这些规则的提供。

尽管要枚举顾客可能因各种规则而遇到麻烦的方式的完整列表是不可能的，但是在此列出常见的情形。当授权WIT时，最好是总是在将WIT应用于产品环境中以前在隔绝的***上考验WIT。

无意义的规则

无意义的规则是明显错误或无意义的规则。此类规则不应引起***崩溃，或具有不可预测方式的举止。

1.对同一个字段同时使用<READONLY/>和<REQUIRED/>规则

2.同时使用<REQUIRED/>和<EMPTY/>规则

3.默认或从“clock”复制到非日期字段

4.默认或从“currentuser”复制到非串字段

5.在非串字段上使用<VALIDUSER>

6.在非日期字段上使用<VALIDDATE>

7.在不同类型的字段上使用<NOTSAMEAS>元素。

8.为<LISTITEMS>中的整数字段指定串值

9.为整数类型的字段指定<GROUPITEM>或<USERLIST>项

引起麻烦的规则

引起麻烦的规则是看起来有意义、但产生糟糕的或不可预测的***行为的规则。

落入此类别的规则包括：

在使用带有<DEFAULT>和<COPY>从句的<WHENCHANGED>的多个字段中的隐藏的无限循环。

对同一字段在一个状态使用<ALLOWEDVALUES>而在另一个状态使用<SUGGESTEDVALUES>以引起无限循环。

表单

UI元素的内容和位置受WITD的<FORM>部分控制。每个工作项类型必需具有恰好一个表单。描述整个表单为包括所有标记、字段和分组。

目标是从一个表单定义出发，我们能够在Visual Studio中、在主宿的窗口表单控制中、及在WSS web部件中恰当地对工作项进行布局。基本观点是设计一次然后在任何地方使用它。

在顶级处，对WITD的<FORM>部分有三个元素。

此父元素包含工作项类型表单的所有布局信息。子元素将分组、列和控件放在该表单上。

<GROUP>

在表单上的同一个分组中包含子元素。分组由边界和可选的标号划界。邻近的分组纵向堆叠。

将所有子元素保存在同一列中，并横向分隔表单。列必需出现在<GROUP>中。可使用<COLUMN>内的<GROUP>元素来创建嵌套的分组。默认地，列平均地分隔<GROUP>。可使用可选的PercentWidth属性来改变列宽。

以下XML定义具有两行分组、且每个分组中有两列的表单。

<FORM>

<GROUP>

...

</COLUMN>

...

</COLUMN>

</GROUP>

...

</COLUMN>

...

</COLUMN>

</GROUP>

</LAYOUT>

</FORM>

控件

使用控件来呈现表单上的字段或其它信息。每个<CONTROL>元素具有Type(类型)属性和可选标号。

使用Type属性来指定以下所讨论的数种控件类型

●FieldControl

●TFStructureControl

●WorkItemLogControl

●LinksControl

●AttachmentsControl

Label(标号)属性指定要在控件邻近显示的文本。相关的LabelPosition属性指定标号相对于控件出现的位置。

FieldControl

使用此控件在表单上显示字段。字段控件必须用引用名称来引用字段。

<Control Type="FieldControl"FieldName="System.Title"

Label="Title"LabelPosition="Left"/>

TFStructureControl

此控件显示树中的Area Path(区域路径)和Iteration Path(迭代路径)字段。树示出可被展开和折叠的分层结构节点。

<Control Type="TFStructureControl"FieldName="System.AreaPath"

Label="Area"LabelPosition="Left"/>

WorkItemLogControl

呈现工作项的history(历史)和(conversation)对话字段。使用此控件可展开和折叠关于对工作项的历史修订的细节。

<Control Type="WorkItemLogControl"FieldName="System.History"

Label="Detailed Description and History"

LabelPosition="Top"Dock="Fill"/>

LinksControl

显示从此工作项到其它工作项的链接。用户可使用此控件来打开、编辑、添加和移除链接。

AttachmentsControl

显示工作项的文件附件。用户可使用此控件来打开、添加和移除文件附件。

所有元素

下表详细描述<FORM>部分所有可允许的元素和属性。包括以上所提及的元素以及其它元素。

元素	属性	描述	包含	需要？
元素	属性	描述	包含	需要？	Form		顶级表单元素	●Layout●Control●Types	是
Layout		定义控件	●Group●Control●TabGroup●Splitter	是	Form		顶级表单元素	●Layout●Control●Types	是
Layout		定义控件	●Group●Control●TabGroup●Splitter	是		Target	表单可包含以不同平台(例如，web相对于WinForms)为目标的不同布局。表单控件将首先寻找Target(目标)被设为“WinForms”的Layout(布局)。如果没有定义任何此类布局，则它将使用第一个不具有Target属性的Layout。		否
	Minimum Size	“(宽度，高度)”形式的串。此值指定表单本身的最小的大小。当容器控件的大小小于此大小时，将出现横向和纵向滚动条。				Target			否
	Minimum Size	“(宽度，高度)”形式的串。此值指定表单本身的最小的大小。当容器控件的大小小于此大小时，将出现横向和纵向滚动条。				Padding	“(左，上，下，右)”形式的串。

		Padding(填充)指定按像素计的在控件的边界周围(在它和它的内容之间)所想要的空间量。每边的空间量可以不同。
		Padding(填充)指定按像素计的在控件的边界周围(在它和它的内容之间)所想要的空间量。每边的空间量可以不同。				Margin	“(左，上，下，右)”形式的串。Margin指定按像素计的在控件的外边周围(在它和它的邻居之间)所想要的空间量。每边的空间量可以不同。
Column		表单的区域被划分为列	●Group●Control●TabGroup●Splitter			Margin
Column		表单的区域被划分为列	●Group●Control●TabGroup●Splitter			PercentWidth	指定列在包含元素内应占据的宽度的百分比。PercentWidth和FixedWidth是互斥的。		否
	FixedWidth	指定列宽为若干像素。PercentWidth和FixedWidth是互斥的。		否		PercentWidth	指定列在包含元素内应占据的宽度的百分比。PercentWidth和FixedWidth是互斥的。		否
	FixedWidth	指定列宽为若干像素。PercentWidth和FixedWidth是互斥的。		否	Group		提供类似于Windows GroupBox的元素视觉分组。	●Column
	Label	要在group元素中显示的标号		否	Group		提供类似于Windows GroupBox的元素视觉分组。	●Column
	Label	要在group元素中显示的标号		否		Dock	指定Group应如何被停靠在包含元素内。被允许的值是：●Top●Bottom●Left●Right●Fill指定当Dock属性时，group将伸展以占据固定大小的项目未占据的任何剩余空间。		否
	Padding	见以上Layout下的描述。				Dock			否
	Padding	见以上Layout下的描述。				Margin	见以上Layout下的描述。
TabGroup		主宿一个或多个tab(标记)	●Tab			Margin	见以上Layout下的描述。
TabGroup		主宿一个或多个tab(标记)	●Tab			Padding	见以上Layout下的描述。
	Margin	见以上Layout下的描述。				Padding	见以上Layout下的描述。

Tab		标记分组内的一个标记。	●Group●Control●TabGroup●Splitter
Tab		标记分组内的一个标记。	●Group●Control●TabGroup●Splitter		Label	指定要在标记上显示的标号	否
	Padding	见以上Layout下的描述。			Label	指定要在标记上显示的标号	否
	Padding	见以上Layout下的描述。			Margin	见以上Layout下的描述。
Control		指定在表单上要出现的字段。			Margin	见以上Layout下的描述。
Control		指定在表单上要出现的字段。			Name	控件的名称。如果没有指定任何名称，则名称默认为FieldName。	否
	Type	指定控件的类型。		是	Name	控件的名称。如果没有指定任何名称，则名称默认为FieldName。	否
	Type	指定控件的类型。		是	FieldName	设置控件的FieldName(字段名称)属性	否
	ID	字段的ID。ID和Name的使用是互斥的。		否	FieldName	设置控件的FieldName(字段名称)属性	否
	ID	字段的ID。ID和Name的使用是互斥的。		否	Label	字段的标号。如果指定了标号，则它将覆盖元数据中与该字段相关联的任何标号。	否
	LabelPosition	指示应相对于字段数据把标号放置在哪里。可能的值是：●Top●Bottom●Left●Right		否	Label	字段的标号。如果指定了标号，则它将覆盖元数据中与该字段相关联的任何标号。	否
	LabelPosition	指示应相对于字段数据把标号放置在哪里。可能的值是：●Top●Bottom●Left●Right		否	Dock	如果指定了，则dock(停靠)属性允许字段伸展以填充容器的其余部分。有效的字段停靠值是：●Top●Bottom●Left●Right	否
	Padding	见以上Layout下的描述。			Dock		否
	Padding	见以上Layout下的描述。			Margin	见以上Layout下的描述。
ControlTypes		此元素必须为在表单的Layout(布局)部分中被引用的每一个自定义控件包含一			Margin	见以上Layout下的描述。

	个ControlType元素。
	个ControlType元素。		ControlType		引用外部组件和该组件内的控件。Layout中指定Type(类型)属性的控件元素必须在ControlTypes部分中具有对应的ControlType。
Name	指定控件类型的名称。Layout部分中的控件使用Type属性来按名称引用ControlType。		ControlType
Name	指定控件类型的名称。Layout部分中的控件使用Type属性来按名称引用ControlType。			Assembly	包含工作项控件的组件。
Class	要被实例化的类的名称。			Assembly	包含工作项控件的组件。
Class	要被实例化的类的名称。		Splitter		在表单中按计划的方向在其兄弟表单元素之间放置splitter(分隔符)
Dock	描述splitter的朝向和停靠行为。有效值是：●Top●Bottom●Left●Right	是	Splitter		在表单中按计划的方向在其兄弟表单元素之间放置splitter(分隔符)

示例

这里是WITD的示例表单。

<FORM>

<Group>

<Control Type="FieldControl"FieldName="System.Title"

Label="Title"LabelPosition="Top"/>

</Column>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Common.Discipline"Label="Discipline"

LabelPosition="Top"/>

</Column>

</Group>

<Group>

<Group>

<Control Type="TFStructureControl"FieldName="System.AreaPath"

Label="Area"LabelPosition="Left"/>

<Control Type="TFStructureControl"

FieldName="System.IterationPath"Label="Iteration"LabelPosition="Left"/>

</Column>

</Group>

</Column>

</Group>

</Column>

<Control Type="FieldControl"

FieldName="System.AssignedTo"Label="Assigned To"LabelPosition="Left"/>

<Control Type="FieldControl"

FieldName="System.State"Label="State"LabelPosition="Left"/>

<Control Type="FieldControl"

FieldName="System.Reason"Label="Reason"LabelPosition="Left"/>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Common.Rank"Label="Rank"LabelPosition="Left"

/>

</Column>

</Group>

</Column>

</Group>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Common.ShortDescription"Label="Summary"

LabelPosition="Top"/>

<Control Type="WorkItemLogControl"

FieldName="System.History"Label="Detailed Description and History"

LabelPosition="Top"Dock="Fill"/>

</Tab>

</Tab>

</Tab>

<Group>

<Group>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Common.Issue"Label="Issue"

LabelPosition="Left"/>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Common.ExitCriteria"Label="Exit Criteria"

LabelPosition="Left"/>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Build.IntegrationBuild"Label="Integration

Build"

LabelPosition="Left"/>

</Column>

</Group>

</Column>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Scheduling.RemainingWork"Label="Remaining Work

(hours)"

LabelPosition="Left"/>

<Control Type="FieldControl"

FieldName="Microsoft.VSTS.Scheduling.CompletedWork"Label="Completed Work

(hours)"

LabelPosition="Left"/>

</Column>

</Group>

</Column>

</Group>

</Tab>

</TabGroup>

</Layout>

</FORM>

WITD本地化和全局化

一般而言，可对终端用户可查看的WITD的所有元素进行本地化，以使它们以用户的本机语言显示。这包括状态、原因和转移的名称，各个元素的“label”(标号)和“name”(名称)属性，以及诸如工作项类型描述和字段帮助文本等预期向终端用户显露的且支持所有Unicode字符的信息。这里唯一的例外是字段的友好名称，它被限制于Unicode字符的一个较小子集，如在字段名称部分中所讨论。

XML定义本身是不可本地化的。因此，诸如<WORKITEMTYPE或<FIELD等标记必须是英文的。此外，诸如<VALIDDATE mustbe=”after now”中的“after now”值或<Control Type=”AttachmentsControl”/>中的“AttachmentsControl”值等固定属性值必须被逐字并以英文来使用。最后，字段引用名称仅支持英文字符(见字段引用名称)，因为这些名称旨在供程序使用，而一般不在UI中显露。

以下提供WITD中可本地化的元素的示例。

名称属性的值可本地化。

<DESCRIPTION>Work item descriptive text here</DESCRIPTION>

工作项类型描述可本地化。

字段引用名称和类型是不可本地化的。字段“name”(名称)属性的值可本地化。但是，记住为字段拣选的名称将在任何给定TFS的所有客户机中使用。同样记住，用户将在构造工作项类型查询时看到字段名称。

字段的帮助文本可本地化。这是根据工作项类型的，而工作项类型是根据团队项目的。

任何串值都可本地化。

状态和原因名称可本地化。

当定义表单时，可标记表单上的分组、标记和字段。这些都可以本地化。

因此使用相同的字段集定义在一个项目中的表单上使用法文名称的bug_french.XML和另一个项目中的bug_english.XML，并由此支持跨项目的查询是可能的。但是，应当注意，当构造查询时，用户将仅访问友好字段名称，而该名称将仅为一种语言。

V1删剪列表

从V1的规范中移除此部分中的项目，但可能会在以后的版本中考虑。

多值字段

列出用户可多选项目的字段。

状态图标/符号

指定将在UI中显示的为每个状态使用的图标。

全局列表

删除-可能必须将此建档以供更深入的管理

分类

添加到前面

添加到后面

在……后添加

字段类型

●Boolean

我们将支持Boolean字段类型，它在表单上将表现为多选框。但是，因为目前这没有在ProductStudio中被很好地实行，且还有其它工作(带0和1值的整数字段)，所以我们对V1不考虑此类型。

●DateOnly

表示年、月和日。不是特定时刻，因此不被绑定到特定时区。

●Day

此类型的字段取星期中的有效日(例如，Tuesday(周二))。

●Month

此类型的字段取有效月份(例如，February(二月))。

●Year

此类型的字段取有效年份(例如，2004))。

字段规则

<MIN/>/<MAX/>规则

串字段类型

设置串字段类型的最小和最大字符

整数/双精度字段类型

设置整数或浮点字段类型的最小和最大值

表单将指示该字段为只读，但通过OM，该字段仍然是可写的。和<READONLY>元素不同，所有Currituck客户机都负责遵守此规则。

双精度确认规则

确认双精度值的规则，诸如指示小数位的个数。

双精度显示选项

字段显示控件上用于格式化双精度的选项，诸如当前值、四舍五入等。

动态列表

用户可仅在字段中输入值并自动把其添加到该字段的允许值列表的列表。

字段索引

一些字段值对于查询或报告而言特别重要。WITD允许为字段指定两个特殊属性。两者都是可选的。单个字段可同时包括这两个属性。

Indexed(被索引的)

具有此属性的字段将有为其构建的索引，它可提高查询性能。少量使用此属性，并仅用于工作项类型中的关键字段。索引仅可配合String、Integer或DateTime类型的字段使用。

工作项类型规则-顾客情形

多产的、集成的、可扩展的

1 摘要…………………………………………………………………………94

2 概述和范围…………………………………………………………………94

3 要求用户填充字段值………………………………………………………94

4 自动填充字段值……………………………………………………………97

5 限制字段值的编辑…………………………………………………………99

6 管理灵活的捡取列表 ……………………………………………………101

7 管理严格捡取列表 ………………………………………………………102

8 将用户分配给字段值 ……………………………………………………105

9 2级从属捡取列表…………………………………………………………108

10 2级从属捡取列表(状态和原因) ………………………………………110

11 3级从属捡取列表 ………………………………………………………112

12 扩展状态模型……………………………………………………………116

13 确认整数字段值…………………………………………………………117

14 确认串字段值……………………………………………………………120

15 确认DateTime字段值……………………………………………………121

16 使用索引来提高查询性能………………………………………………122

17 在报告中包括自定义字段值……………………………………………123

18.1 XML示例 ………………………………………………………………124

19 不允许由用户/组进行转移 ……………………………………………126

20 在收官阶段请求代码检查………………………………………………127

21 通知列表情形……………………………………………………………129

22 请求复制链接……………………………………………………………130

1 摘要

此规范描述顾客在创作工作项类型时想要实现的关键情形。

2 概述和范围

此文档的目的是确定和确保在创作工作项类型商务逻辑时对关键顾客情形的支持。此文档指定顾客正在试图实现什么，标识可能的XML规则构造，并定义所需的用户接口和要实现/强制执行的OM/BRIE行为。此文档还起到顾客面对工作项类型创作文档的基础的作用。

此文档并不试图枚举顾客可能试图应用于工作项类型的所有可能的情形。它也不覆盖在工作项类型定义语言中顾客可用的所有规则。

在每个情形本身的部分中对其进行定义。灰色的部分是从M3.3里程碑中剪切出来的。

此文档是工作项类型定义语言规范的补充规范。

3 要求用户填充字段值

工作项类型的作者想要确保用户在某些时间输入一组字段的值。换言之，不能留下空的被标识的字段。

3.1 XML示例

用户必须输入工作项的标题。

</FIELD>

3.2 用户界面处理

用户界面的总体目标是使用户能更容易迅速地视觉地确定他们在所有字段中是否都具有合法值。为实现此目标，当必需的字段当前不具有值时，应以某种方式高亮突出。这可以是背景色、字段标号色和/或星号。在设计中应把可访问性要求纳入考虑范围。

如果必需的字段在标记上，而当前未选择该标记，则该标记上的某些指示符应当示出该标记上需要填写有一些必需的字段。

当用户已经填充了值时，高亮突出应当消失。这样，，用户可迅速确定他们何时可满足保存工作项的要求。

3.3 OM/BRIE处理

当有人试图保存所具有的必需的字段仍为空的工作项时，后端应当产生有目的的出错。OM应当提供一种方式，使可选的用户界面的开发者能够迅速地确定哪些字段需要值，所以它们能够为用户产生有用的出错消息。

当用户试图保存具有多个空的必需的字段的工作项时，出错消息应当指示需要填充的所有字段，而不是一次一个字段地呈现出错。

3.4 规则范围处理

必需性是加性的。例如，如果为工作项类型定义了<REQUIRED/>规则，则该字段总是必需的，无论状态、转移或原因是什么。如果<REQUIRED/>规则是在给定状态上，则该字段在工作项处于该状态时，或在工作项正在进入该状态时是必需的，而无论转移或原因是什么。

3.5 情形

3.5.1 总是要求“Title”(标题)字段有值。总是要求为工作项输入描述。

</FIELD>

3.5.2 当处于“Investigating”(调查)状态时，“Assigned To”(分配给)字段是必需的。一些工作项在“Submitted”(已提交)或“New”(新建)状态中进入生命。从那里出发它们移动到另一个活动的状态。在此例中，是“Investigating”。当工作项处于“Investigating”状态时，必需把它分配给某个人。

.

</FIELD>

</FIELDS>

</STATE>

.

3.5.3 当转移到“Closed”(关闭)状态时，“Reviewed By”(被……查看过)字段是必需的。为要关闭工作项(无论原因是什么)，工作项必须已被某人查看过。

</FIELD>

.

</FIELD>

3.5.4 当由于“Duplicate”(复制)的原因转移到“Resolved”(已解决的)状态时，“Duplicate ID”(复制ID)字段是必需的。

如果某人正在为工作项复制的原因解决工作项，则必须把复制id输入到Duplicate ID字段中。对于任何其它状态或原因，此字段可保持为空。

</FIELD>

</REASON>

3.5.5 当“Source”(源)字段有值“From Customer”(来自顾客)时，“Customer Priority”(顾客优先级)字段是必需的。

此工作项具有标识源的字段，如果源来自顾客，则必须填充顾客优先级字段。

<FIELD refname="MyCorp.CustomerPriority"name="Customer Priority"

type="String">

</WHEN>

</FIELD>

4 自动填充字段值

为简化工作项输入，顾客试图尽可能多地自动填充字段。有四个规则支持此自动填充，<DEFAULT>、<COPY>、<SEVERDEFAULT>和<EMPTY>。

4.1 XML示例

设置默认优先级为P3。

<FIELD refname="Microsoft.MSF.Priority"name="Priority"

type="String">

</ALLOWEDVALUES>

</FIELD>

将当前用户名称复制到指示检查该工作项的人的字段中，但允许修改该值。

</FIELD>

在提交时将当前用户名称和日期复制到字段中。这些字段在GUI中是不可修改的，因为当用户提交修改时会覆盖服务器上的值。

</FIELD>

</FIELD>

在提交时清除字段的值。清除字段并且在GUI中不可修改，因为将会丢失用户输入的任何值。通常在转移期间使用此规则。例如，如果想要在重新打开故障时(从Closed转移到Active)清除Reviewed by字段。

</FIELD>

.

4.2 用户界面处理

如果字段为空的，则default(默认)规则在在字段中放置值。如果字段已有值，则应忽略默认规则。copy(复制)规则将值放到字段中，而无论该字段中是否有任何先前的值。default或copy规则都不应隐含关于字段是只读还是必需的任何信息。

应在copy规则之前处理default规则以允许在驱动复制行为的字段中***默认值。当用户创建新工作项或开始编辑现有工作项时，应遵守以下顺序：

-应处理when从句以外的所有default规则

-应处理when从句以外的所有copy规则

-按以下顺序处理when从句内的所有default规则然后是copy规则：

WHEN、WHENNOT、WHENCHANGED

-按需重复至3级

-将控制移交给用户

开放式问题：这实际上如何工作？

在提交以后serverdefault(服务器默认)和empty(空)规则操作服务器方。字段在GUI中应该是只读的，因为用户放在这些字段中的任何值在提交时都会丢失。

4.3 OM/BRIE处理

OM/BRIE必须处理这些规则以如上所述地驱动GUI。

还应确认字段的内容，并且必须捕捉WIT作者可能错误地放在默认规则中的任何不合法的值。取以下示例，其中默认值是不合法的：

</ALLOWEDVALUES>

</FIELD>

当用户为serverdefault和empty规则保存工作项时，后端将放置服务器时钟时间、当前用户，或清除该字段。

4.4 规则范围处理

和加性的必需规则不同，当范围变得更为细分时，应覆盖default和copy规则。因此，状态专属的default/copy规则将覆盖工作项类型default/copy规则，转移专属的default/copy规则将覆盖状态专属的default/copy规则，而原因专属的default/copy规则将覆盖转移专属的default/copy规则。

为所有字段类型支持default和copy。

开放式问题：这能实现吗？

4.5 情形

4.5.1 默认priority(优先级)字段值为P3。

我有一组被允许的优先级值，但想要为用户填充默认值P3。

4.5.2 如果severity(严重程度)字段是S1，则将优先级字段复制为P1

我有定义了商务优先级和顾客报告的严重程度的工作项类型。如果顾客报告的严重程度是S1，则默认的商务优先级应为P1。

开放式问题：我们将会需要<SERVERDEFAULT from='field'value='PI/'>我们能删剪掉它吗？

4.5.3 默认“Discovered On”(在……被发现)字段为当前时间，但允许用户修改该值。

我想要跟踪发现工作项的日期。这可能在把它输入到***中的日期之前。但是，大多数时候，它是正在输入工作项时的日期，因此默认“Discovered On“字段为当前日期，但允许用户在需要的情况下编辑它。

开放式问题：我们能删剪掉此情形所需要的<COPY from='clock'/>吗

4.5.4 当用户保存工作项时，将“Last Saved On”(最近在……被保存)字段复制为服务器时钟时间

当用户保存工作项时，总是强制“Last Saved On”字段为服务器时钟时间。

4.5.5 当处于“Assigned”状态时，默认“Assigned To”(分配给……)字段为当前用户。

如果尚未把工作项分配给某人，则当处于Assigned状态时默认为当前用户。

4.5.6 当用原因“No Repro”决定工作项时，“Reviewed By”字段应和“Assigned To”字段具有相同的值。

当开发者决定不能再生工作项时，用被分配了该工作项的任何人的值填充reviewed by字段。

5 限制字段值的编辑

顾客想要控制允许谁对某些字段进行改变。他们可使用<READONL/>规则来实现此目的。此外，可使用for和not属性的使用来将这些规则的适用性的范围界定到个人的子集。

5.1 XML示例

在此例中，顾客想要仅允许TriageMembers组的成员修改Triage字段中的值。

</ALLOWEDVALUES>

</FIELD>

5.2 用户接口处理

字段应具有灰色的背景，且用户应不能够编辑该值。

5.3 OM/BRIE处理

OM/BRIE应阻塞所有写<READONLY>字段的尝试。这里的例外是在后端操作的<SERVERDEFAULT>和<EMPTY>元素。

5.4 规则范围处理

<READONLY>是加性的。这包括for和not约束。

5.5 情形

5.5.1 全局READONLY(只读)

预期的结果，始终是从GUI和OM两者只读字段。

5.5.2 状态专属READONLY

预期结果，当状态字段='some state'时，字段是只读的。

5.5.3 转移专属READONLY

预期结果，当原始状态字段值='from state'且新状态字段值='to state'时，从GUI和OM两者只读字段。

5.5.4 原因专属READONLY

预期结果，当原始状态字段值='from state'且新状态字段值='to state'且原因字段值='some reason'时，从GUI和OM两者只读字段。

5.5.5 全局GRAYOUT

预期结果，在GUI中使字段灰化，但可从OM修改。

5.5.6 状态专属GRAYOUT

预期结果，在GUI中使字段灰化，但当状态字段='some state'时，可从OM修改。

5.5.7 转移专属GRAYOUT

预期结果，在GUI中使字段灰化，但当原始状态字段值='from state'且新状态字段值='to state'时，可从OM修改。

5.5.8 原因专属GRAYOUT

预期结果，从GUI使字段灰化，但当原始状态字段值='from state'、新状态字段值='to state'且原因字段值='some reason'时，可从OM修改。

5.5.9 for的4x

重复5.5.1到5.5.4，但使用for。预期行为，对此组中的或被特别标识的用户，字段为只读，但对其他用户非只读。

5.5.10 not的4x

重复5.5.1到5.5.4，但使用not。预期行为，对不在此组中的或被特别标识的用户，字段为只读，但对此组中的用户非只读。

5.5.11 forgroup和notgroup的8x

重复5.5.1到5.5.8，但使用forgroup和notgroup构造。

6 管理灵活的捡取列表

顾客想有带有用户可从中选择的一组建议值的字段。但是，他们不想约束用户输入他们自己的值。

6.1 XML示例

顾客想要跟踪在哪个建立中发现了故障。他们有每晚建立的列表，但也想要允许开发者输入本地建立号。

<FIELD refname="Microsoft.Build.FoundIn"name="Found In Build"

type="String">

</SUGGESTEDVALUES>

</FIELD>

6.2 用户接口处理

应向用户呈现允许他们拣选建议值中的一个的下拉列表。用户还可手动输入值。从来没有对字段为不合法的值(除了在字段还具有<REQUIRED/>元素的情况下，在此情况下NULL值是不合法的)。

如果有一个建议值，则它应当被预填充(就好像有默认规则)。当然用户可改变该值。

开放式问题：这最后一段受到支持吗？

6.3 OM/BRIE处理

对于灵活的捡取列表，没有任何特定的OM/BRIE处理强制。

6.4 规则范围处理

用建议值集的并集来创建建议值规则。应由OM从列表中移除相等的值，从而不会向用户呈现多个但相等的选项。如果工作项类型作者想要每个原因的专属列表，则他们可仅在原因级指定建议值。

6.5 情形

见以上的XML示例。

7 管理严格捡取列表

顾客想要严格地管理给定字段的合法值列表。用户仅可从给定列表选择一个合法值。

7.1 XML示例

详见以下情况。

7.2 用户接口处理

应向用户呈现下拉列表，它提供从中选择合法值的当前列表。如果值已存在于字段中，且它位于被禁止的值的列表中，或者既没有被禁止的值规则也没有允许现有值规则，则应高亮突出字段以指示用户需要进行改变。如果值已经存在于字段中，且有allowexistingvalues(允许现有值)规则，则不应高亮突出任何事物。

7.3 OM/BRIE处理

后端应当基于当前规则组强制各字段总是具有合法值。例外的是如果一字段有不合法的原先值(编辑以前)与有被允许的值规则，则后端应当接收提交并保持该字段值不变。

7.4 规则范围处理

用被允许的值的交集创建被允许的值列表规则，这包括被禁止的值。如果工作项类型作者想要指定特定原因级规则，则他们可通过仅将值列表放在原因级处来实现此目的。

开放式问题：被禁止的值也是并集或交集吗？

7.5 情形

7.5.1 管理具有默认值的合法值列表

工作项类型作者想要值为emergency(紧急)、major(大)、minor(小)或very minor(非常小)的severity字段来指示缺点的严重程度。默认值是‘minor’。

<FIELD refname="MyCorp.DivA.Severity"name="Severity"

type="String">

<HELPTEXT>Enter the severity of the problem</HELPTEXT>

</ALLOWEDVALUES>

</FIELD>

7.5.2 在需要推迟的更新的情况下移除先前的合法值

稍后他们决定VeryMinor实际上不是那么有用。他们想要将其从允许值列表中移除，并且他们想要在编辑现有记录时将其从中移除。以下XML示出此修改。注意，只不过是移除值，且编辑工作项的任何时候，将需要修改具有“VeryMinor”值的任何先前的工作项：

<FIELD refname="MyCorp.DivA.Severity"name="Severity"

type="String">

<HELPTEXT>Enter the severity of the problem</HELPTEXT>

</ALLOWEDVALUES>

</FIELD>

7.5.3 在不需要任何更新的情况下移除先前的合法值

在有许多来自工程的反馈以后，公司后来决定将现有的“VeryMinor”值改为“Minor”是不合理的。较佳的是允许这些值按以前的方式保持。工作项类型作者进行以下修改：

<FIELD refname="MyCorp.DivA.Severity"name=“Severity"

type="String">

<HELPTEXT>Enter the severity of the problem</HELPTEXT>

</ALLOWEDVALUES>

</FIELD>

7.5.4 管理在多个字段中相同的列表

多个字段需要同一个列表是可能的。例如，有found on operatingsystem(在操作***上找到)和fixed on operating system(在操作***上修复)字段。两者都有必需的操作***的列表。将使用以下XML来保持和管理在一处的此列表。注意，默认值是来自found on operating system字段的。

</GLOBALLIST>

</GLOBALLISTS>

.

</FIELD>

</FIELD>

7.5.5 值被存储在另一个***中的管理列表

另一个列表管理情形，我们想要支持的是顾客用存储在Currituck外部的数据来自动保持最新的Currituck列表的能力。这是通过创建全局列表(如上所述)来实现的。但是，我们需要允许使用我们的OM的开发者进行以下操作的OM接口：

●添加列表值(到开头，到结尾，***在索引前)

●移除列表值

●取得列表中的值的个数

●在列表上迭代

●对列表分类

这里主要的示例是建立id的列表。XML将简单地定义列表如下(注意，XML中至少必须指定一个项)：

</GLOBALLIST>

</GLOBALLISTS>

8 将用户分配给字段值

用户想要分配工作项。但是，分配可能呈现许多意义。例如，有时需要基于在其中提交了故障的区域而把该故障默认地隐含分配给某个用户。又如，将故障分配给要被检查的组(如将其分配给TriageTeam)。在另一情形中，作者想要用户进行明确的分配，但是是从***中所有用户的子集出发。此部分概述这些不同的情形。

8.1 XML示例

以下为每种情形概述XML示例。

8.2 用户界面处理

在V1中，没有任何“user/group”类型的字段，只有“string”。尽管如此，工作项类型作者仍有三种手段来确认用户分配。

它们是<VALIDUSER/>、<VALIDUSER group='group'/>和

<ALLOWEDVALUES>/<PROHIBITEDVALUES>规则。

使用有效用户规则来确认所输入的用户id是否是***中的合法用户。如果不是，则将高亮突出该字段以示其具有无效值。带有组的VALIDUSER构造应确保所输入的用户是在该组中。

以下为每种情形概述

<ALLOWEDVALUES>/<PROHIBITEDVALUES>行为。

8.3 OM/BRIE处理

在V1中，没有任何“user/group”类型的字段，只有“string”，因此OM/BRIE只需强制执行适当的规则(见上)。

8.4 规则范围处理

<VALIDUSER/>规则是加性的，所以它们使字段在范围中所有较低级的地方都需要有效的用户id。

8.5 情形

8.5.1 将当前用户分配给字段

当创建新工作项时，默认地把创建该工作项的用户分配给该字段。因为没有任何允许值列表，且此字段有<VALIDUSER/>规则，所以可分配给在TFS中定义的任何用户，并且应从此字段上的捡取列表中获得。此外，用户能够手动输入用户id。GUI高亮显示帮助用户作出有效的选择。OM/BRIE确保输入的是有效的用户id。

<FIELD refname="System.AssignedTo"name=′Assigned To′

type=′String′>

</FIELD>

开放式问题：确切而言有效用户是什么？是Currituck数据库还是BIS中的用户？

8.5.2 将用户从特定组分配到字段

分配给此项目中的工作项的用户必须是项目团队的成员。所有项目团队成员是“MyProjectMembers”组(BIS或Windows)的一个部分。assignedto字段默认为当前用户。下拉列表应为MyProjectMembers中的所有用户的列表，该列表被扩展以包括是MyProjectMembers的成员的任何子组中的用户。例如，如果MyProjectMembers仅有3个子组Developers(开发者)、Testers(测试员)、ProgramManager(项目经理)，则将不会示出这些子组，但将会示出这三个子组中的所有用户的列表。

如果currentuser不是此组成员，或用户手动输入了不是此组成员的用户id，则GUI应高亮突出该字段以指示无效值。后端应确认此字段由于<VALIDUSER value=”MyProjectMembers”/>规则而包含来自所指示的组的有效用户。

<FIELD refname="System.AssignedTo"name=′Assigned To′

type=′String′>

<!--Note there can one only be one of these in allowed values lists

-->

</ALLOWEDVALUES>

</FIELD>

8.5.3 分配给用户、组或值

在此情形中，可把工作项分配给用户、组或特定值。对于此例，我们有一“MyProjectMembers”组，它是分配给该项目的用户(bob，shirley，dave，brian，max)的平坦列表。我们还有一“MyProjectGroups”组，它有子组“Development，Test，Documentation，ProgramManagement”，且在此级上没有任何用户。此外，我们可能想要将故障分配给“Triage”，而它根本不是一个组。

<FIELD refname="System.AssignedTo"name=′Assigned To′

type=′String′>

</ALLOWEDVALUES>

</FIELD>

在此情形中，下拉列表值应为：

Triage，bob，shirley，dave，brian，max，Development，Test，Documentation

开放式问题：我们是否应在GUI中给用户关于这些是值、用户或分组的一些提示？

当字段可能包含不是有效用户的值时没有任何有效用户规则。

8.5.4 基于区域分配用户

公司常常想要基于正对其报告故障的区域、组件或应用程序来将默认的项目领导分配给传入的故障。给定了区域路径，我们应当能够实现此目的。

对于此例，顾客想要强制执行以下规则：

●自动分配给Currituck工作项类型定义语言上的’brianwh’故障。

●自动分配给链接子***的Currituck上的‘lingbao’故障。

●否则将故障分配给‘bryanmac’。

●不允许提交覆盖着分配，除非他们是项目团队的成员(我们假定他们可能知道更多)。

●确保输入是有效用户

●决不允许故障进入而未被分配

<FIELD refname="System.AssignedTo"name=′Assigned To′

type=′String′>

</WHEN>

</WHEN>

9 2级从属捡取列表

用户有两个字段，一个字段从属于另一个。即，在一个字段中所允许的值依赖于第一字段的值。对于此例，我们使用两个字段Platform(平台)和Version(版本)，其中平台是基本操作***，而版本表示操作***的版本。

9.1 XML示例

这是2级从属捡取列表情形的基本XML。以下将为每种情形指示XML的其它片段或修改。还要注意在Platform值未知的情况下清除version字段的规则。

</FIELD>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</FIELD>

9.2 用户界面处理

以下为每种情形描述期望的行为。

9.3 OM/BRIE处理

OM/BRIE处理主要是强制执行与第3部分中的必需字段的值相同的合法值以及管理第7部分中的严格捡取列表。

9.4 规则范围处理

没有把此例的范围界定到状态、转移或原因。

9.5 情形

9.5.1 新工作项，取默认值

用户创建新工作项然后保存。预期的结果是向字段platform(平台)分配默认值Windows，而向字段version(版本)分配默认值XP。

9.5.2 新工作项，改变版本

他们接受了默认值“Windows”。用户然后选择“Version”字段的下拉列表。它包含值“95、98、W2K，XP”。用户选择95并保存。

9.5.3 新工作项，改变平台(以默认值)

用户创建新工作项。把默认值“Windows”和“XP”放在platform和version字段中。然后用户选择“Platform”字段的下拉列表。他们得到值“Windows”、“Unix”、“Linux”和“Unknown”(未知)。用户选择“Unix”。现在高亮突出字段“Version”，因为它包含不合法的值“XP”。用户看到了并选择version字段的下拉列表，并看到选择“SunOS，HP-UX，和Solaris”。他们捡取“Solaris”。version字段的高亮突出消失。用户保存。

9.5.4 现有工作项，改变平台，改回，保存

用户打开平台值为“Windows”而版本为“XP”的现有工作项。用户选择platform字段的下拉列表并捡取“Unix”。高亮突出值为“XP”的version字段作为不合法值。用户选择平台下拉列表并将其改回为“Windows”，不再高亮突出version字段。

9.5.5 改为未知，保存

用户打开现有的或新的工作项。platform字段是“Windows”，version字段是“XP”。用户选择平台的下拉列表并将其该为“Unknown”。清除version字段为在GUI中为只读。

9.5.6 将平台改为未知，改为Linux，保存

用户打开新的或现有的工作项。platform字段起初是“Windows”，version字段是“XP”。用户选择平台的下拉列表并将其改为“Unknown”。清除version字段。用户回忆起平台是“Linux”。他们对platform字段进行此选择。version字段默认为值“RedHat”。

10 2级从属捡取列表(状态和原因)

工作项类型的工作流程定义工作项遍历的状态、转移和原因。这在XML的<WORKFLOW>部分中定义。但是，有两个核心字段State(System.State)和Reason(System.Reason)，用户在其中操纵状态模型。这些字段的行为就像带默认值的2级从属捡取列表一样。

10.1 XML示例

</STATES>

</REASONS>

</TRANSITION>

</REASONS>

</TRANSITION>

</REASONS>

</TRANSITION>

</REASONS>

</TRANSITION>

</REASONS>

</TRANSITION>

</REASONS>

</TRANSITION>

</TRANSITIONS>

</WORKFLOW>

10.2 用户接口处理

以下为每种情形描述期望的行为。尽管这两个字段的行为类似于2级从属捡取列表，但是仍有一些区别，以下为每种情形用粗体高亮突出这些区别。

10.3 OM/BRIE处理

OM/BRIE处理主要是强制执行和第3部分中的必需字段的值相同的合法值，以及管理第7部分中的严格捡取列表。

10.4 规则范围处理

把原因的范围界定到转移，而把转移的范围界定到状态对。

10.5 情形

10.5.1 新工作项，保存

用户创建新工作项。设置状态为“NEW”，设置原因为“New”。

10.5.2 新工作项改变原因，保存

用户创建新工作项。设置状态为“NEW”，设置原因为“New”。用户选择reason(原因)的下拉列表并捡取“Found By Customer”并保存。

10.5.3 新工作项改变状态

用户创建新工作项。设置状态为“NEW”，设置原因为“New”。用户试图改变状态，但他们不能够，因为新工作项只有一个合法状态。

10.5.4 改变状态，默认的原因

用户打开状态值为“NEW”且原因被设为“New”的现有工作项。他们选择State(状态)的下拉列表，该列表提供“NEW”、“ASSIGNED”或“CLOSED”。用户选择“ASSIGNED”，reason(原因)字段默认为“Triaged”。

10.5.5 改变状态，改回并保存

用户打开状态值为“NEW”且原因被设为“New”的现有工作项。他们选择State(状态)的下拉列表，该列表提供“NEW”、“ASSIGNED”或“CLOSED”。用户选择“ASSIGNED”，reason(原因)字段默认为“Triaged”。用户然后改变了主意，并再次选择state字段，并将其改回为“NEW”。高亮突出reason(原因)字段以指示它不再包含有效值。用户或可重设reason字段，或可在不保存改变的情况下关闭工作项。

11 3级从属捡取列表

许多顾客想要N级捡取列表。此情形概述了3级捡取列表的示例，该列表构建在第9部分的2级捡取列表之上。在此例中，我们有来自前例的Platform和Version字段，但我们添加了第三级“Patch”(补丁)字段，它指示操作***可能具有的任何补丁。

11.1 XML示例

此XML示例定义Patch字段。在第9.1部分中描述Platform和Version字段。

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</WHEN>

</FIELD>

11.2 用户界面处理

除了3级捡取列表之外，关于上例还有几件事要注意。首先，如果platform字段是Unknown，则我们象对Version字段所作的那样清除Patch字段。第二，如果用户选择Platform＝Linux和Version＝Other，则我们允许用户输入自由形式的文本，而不是明确的允许值列表。

11.3 OM/BRIE处理

后端不过是进行正常必需的和允许的值的强制执行。

11.4 规则范围处理

对于此例，使不同规则的范围被状态、转移和原因界定是无意义的。虽然无法想像出现这种情况的情形，但肯定有这样的情形。在此情形中，我们的建议是将字段清楚地分割。因此，如果字段C依赖于字段B的值，而字段B依赖于字段A的值，且字段C还依赖于原因，则我们将说在全局<FIELDS>部分中定义字段A和B。在特定原因下在<WORKFLOW>部分中定义字段C的<WHEN>从句。

以此方式，从属捡取列表将恰好有一个完整的定义。即，字段C在原因部分中将不会有一些全局允许的值和不同的允许值集。这遵循当前***加性行为的规则。

11.5 情形

11.5.1 新工作项，取默认值

用户创建新工作项然后保存。预期的结果是向字段platform分配默认值Windows，向字段version分配默认值XP，并向字段Patch分配默认值“None”。

11.5.2 新工作项，改变补丁

用户创建新工作项。他们接收默认值“Windows”和“XP”。用户随即选择“Patch”字段的下拉列表。它包含值“None”和“SP1”。用户选择“SP1”并保存。

11.5.3 新工作项，改变平台，改变版本，改变补丁

用户创建新工作项。默认值“Windows”、“XP”和“None”被放在platform、version和patch字段中。用户随即选择字段“platform”的下拉列表。他们获得值“Windows”、“Unix”、“Linux”和“Unknown”。用户选择“Unix”。现在高亮突出字段“Version”，因为它包含不合法值“XP”。未高亮突出patch字段，因为它包含合法值“None”。用户选择version字段的下拉列表，并看见选择“SunOS、HP-UX、AIX和Solaris”。他们捡取“Solaris”。version字段高亮突出消失。用户随即选择Patch下拉列表并取得“None”或“.01”。用户选择“.01”并保存。

11.5.4 现有工作项，改变平台，改回，保存

用户打开现有工作项，其平台值为“Windows”、版本是“XP”，补丁是“SP1”。用户选择platform字段的下拉列表并选择Unix。高亮突出version和patch字段为无效。用户选择平台下拉列表并将其改回为“Windows”，不再高亮突出version和patch字段。

11.5.5 改为Unknown(未知)，保存

用户打开现有的或新的工作项。platform字段是“Windows”，version字段是“XP”，patch字段是“None”。用户选择平台的下拉列表并将其改为“Unknown”。清除version和patch字段。

11.5.6 将平台改为Unknown，改为Linus，保存

用户打开新的或现有的工作项。platform字段起初为“Windows”，version字段是“XP”，patch字段是“SP1”。用户选择平台的下拉列表并将其改为“Unknown”。清除version字段。用户想起平台是“Linux”。他们对platform字段进行此选择。version字段默认为值“RedHat”，patch字段默认为“None”。

11.5.7 Linux，其它，输入Patch，保存

用户打开新工作项。platform、version和patch的默认是“Windows”、“XP”、“None”。用户为platform选择“Linux”。高亮突出version字段为无效(该字段为XP)。用户为version选择“Others”(其它)。patch字段仍然是“None”。用户选择“None”并清除该字段。他们将“BL5”输入patch字段并保存。

12 扩展状态模型

用户想要通过创建被绑定到state(状态)字段的“Sub-State”(子状态)字段来扩展盒外工作流程。子状态指示工作项处于给定状态时的状态，并且每当有状态改变时应被清除。

12.1 XML示例

<FIELD refname="Microsoft.Common.SubState"name="SubState"

type="String">

</WHENCHANGED>

</ALLOWEDVALUES>

</FIELD>

</FIELDS>

</STATE>

</ALLOWEDVALUES>

</FIELD>

</FIELDS>

</STATE>

.

</WORKFLOW>

12.2 用户界面处理

每当状态改变时就清除“SubState”字段值。对于每个状态，都有允许值的下拉列表可供用户从中选择。

12.3 OM/BRIE处理

因为没有<REQUIRED/>规则，所以无需SubState值即可保存工作项。当处于给定状态时，该值必需是允许值列表中的一个或为空。

12.4 规则范围处理

每当状态改变时就进行清除操作，而无论它所去往的状态是什么。

12.5 情形

12.5.1 分配子状态

用户打开现有工作项。状态是“ACTIVE”且sub-state(子状态)字段为空。用户选择sub-state字段的下拉列表并取得对“Blocked”、“Investigating”和“Fixing”的选择。他们选择“Fixing”并保存工作项。

12.5.2 改变状态并维持子状态为空

用户打开现有工作项。状态是“ACTIVE”，子状态是“Fixing”。用户将状态从“ACTIVE”改为“RESOLVED”。清除子状态字段。用户保存工作项。

12.5.3 无效条件

用户打开现有工作项。状态是“ACTIVE”且sub-state字段为空。用户输入子状态值“On Hold”。高亮突出该字段为无效。用户选择sub-state字段上的下拉列表并选择“Blocked”，并保存工作项。

13 确认整数字段值

顾客在一字段中想要整数值，但想要约束合法输入。

13.1 XML示例

在下例中，顾客想要优先级是1和5之间的整数值。

<HELPTEXT>Enter a value from 1 to 5</HELPTEXT>

</FIELD>

13.2 用户界面处理

用户手动在priority(优先级)字段中输入值。如果它不满足最小/最大规则，则应高亮突出该字段以向用户指示该值不合法。用户可悬停在字段上来获得帮助文本(应当是有所帮助的)。一旦他们纠正了问题，即移除高亮突出。

13.3 OM/BRIE处理

如果值不满足最小/最大约束，则后端应当失败。

13.4 规则范围处理

规则是加性的，因此有效范围将是约束的交集。因此，例如，如果全局约束是<MIN value='5'>，状态专属约束是<MAX value='20'>，转移专属约束是<MIN value='8'/>而原因专属约束是<MAX value='10'>。则对于处于给定状态的工作项，在特定的转移期间，且在给定此原因的情况下，合法值将在范围8-10内。

合法和不合法字段见以下情形。

13.5 情形

13.5.1 仅有最小值

考虑<MIN value='-5'>。合法值是-5或以上。

13.5.2 仅有最大值

考虑<MAX value='100'>。合法值是100或以下。

13.5.3 最小值和最大值有效

考虑<MIN value='1'/><MAX value='5'/>。合法值包括1-5。

13.5.4 最小值和最大值边界

考虑<MIN value='5'/><MAX value='5'/>。该字段仅有一个合法值，且该值为5。在此情形中，如果字段中还没有值，则UI应当将该字段值默认为5。

13.5.5 最小值和最大值无效

考虑<MIN value='10'/><MAX value='5'/>。没有任何合法值。导入程序应当捕捉此条件并不能提供该工作项类型。

13.5.6 仅范围被界定的最小值有效

考虑为字段指定最小值规则而无论状态是什么，并指定另一状态专属的最小值规则。应为(字段级/状态级)最小值处理每个这些情形和结果：

●10/5(较小的最小值)

○合法值＞＝10。规则是加性的并且是最具限制性的，因此这里全局规则优先。

●10/20(较大的最小值)

○合法值＞＝10，除了在状态专属时，在后一种情形中，字段必须＞＝20。

13.5.7 仅范围被界定的最大值

考虑为字段指定最大值规则而无论状态是什么，并指定另一状态专属的最大值规则。应为(字段级/状态级)最大值处理每个这些情形和结果：

●10/5(较小的最大值)

○合法值＜＝10。除了在状态专属时，在后一种情形中，字段必须＜＝5。

●10/20(较大的最小值)

○合法值＜＝10，规则是加性的并且是最具限制性的，因此这里全局规则优先。

13.5.8 范围被界定的最小值/最大值

考虑为字段同时指定了最小值和最大值规则而无论状态是什么，并指定了另一状态专属的最小值/最大值规则对。应为(最小值-最大值全局/最小值-最大值状态专属)最大值处理每个这些情形和结果：

●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(最小值相同，最大值较大)

○合法值是10-20，状态专属合法值同样是10-20。

●10-20/10-15(最小值相同，最大值较小)

○合法值是10-20，状态专属合法值是10-15。

●10-20/5-20(最小值较小，最大值相同)

○合法值是10-20，状态专属合法值是5-20。

●10-20/15-20(最小值较大，最大值相同)

○合法值是10-20，状态专属合法值是15-20。

13.5.9 范围被界定的最小值/最大值无效

以下情形是无效的，导入程序应当捕捉这些情形并在提供期间失败。

●10-20/1-5

●10-20/25-30

○两者都是全局合法的，但对于状态专属是不合法的值。

14 确认串字段值

有时，而不是像使用<ALLOWEDVALUES>来进行那样指定串字段的明确值的列表，工作项类型作者想要对串输入强制执行某个惯例。很好的示例有建立id或版本id。这是使用<MATCH>从句来完成的。

还可进行匹配以在不想枚举所有可能id的地方指定包含数字的id。

注意，串确认总是大小写不敏感的。

14.1 XML示例

<FIELD refname="MyCorp.FoundInBuild"name="Found In Build"

type="String">

<HELPTEXT>Enter a Build Id using format ANN.NN.NN.BNN</HELPTEXT>

</FIELD>

<FIELD refname="MyCorp.ProductCode"name="Product Code"

type="String">

<HELPTEXT>Enter the product code using format AA-NNN</HELPTEXT>

</FIELD>

14.2 用户界面处理

理想地，如果输入了无效串值，则用户界面应当高亮突出。但是，相信这是P2。最高优先级是在用户悬停在字段上的情况下显示字段的帮助文本。我们建议在帮助文本中指示字段的格式要求。

14.3 OM/BRIE处理

后端应确认字段的值与<MATCH>串一致。应以字段无效并包括匹配串(这是防止用户万一误输入了帮助文本)来向用户回报出错。

14.4 规则范围处理

如<DEFAULT>规则，<MATCH>规则应相互覆盖而不是加性的。

14.5 情形

我们应测试有效和无效组合以及若干匹配串。

15 确认DateTime字段值

顾客想要用户输入日期或者日期和时间，但想要确保所输入的值是合法的。这是使用<VALIDDATE>构造来完成的。

15.1 XML示例

描述顾客可能试图创作的示例性工作项类型定义。

确认日期字段。Mustbe值可以是‘after now’或‘not after now’。‘after now’是在当前时间以后。‘not after now’要求该字段值为当前时间或以前。用于DateTime字段类型。

15.2 用户界面处理

以下为每种情形描述期望的UI处理。

15.3 OM/BRIE处理

以下为每种情形描述期望的OM/BRIE处理。

15.4 规则范围处理

<VALIDDATE>规则是加性的。同时有‘after now’和‘not after now’是不合法的。应在提供时捕捉此情形。

15.5 情形

15.5.1 默认为当前时间，允许用户用稍后的时间覆盖

用户想要字段保持所计划的完成任务的时间。他们想要默认为当前时间以给用户正确格式的概念，但允许用户覆盖该值。他们想要确保所输入的时间是现在或将来。最后，如果已完成任务，则他们想要该值是只读的以便于历史审查。

<FIELD refname="MyCorp.EstDate"name="Estimated Date"

type="DateTime">

</FIELD>

.

</FIELD>

.

用户创建新工作项，Estimated Date(估计日期)字段必须包含将来的值。

用户再次打开该任务，estimated date字段仍然可编辑。用户选择State(状态)字段上的下拉列表并将值改为Complete(完成)。Estimated date字段变为不可编辑。

15.5.2 日期永远不能是将来

用户想要有保持故障被关闭的日期的字段。他们想要在用户保存故障时填充此字段，但不要用户能够直接修改该字段。他们想要该字段保持为空，除非它处于CLOSED状态，在这种情形中它是必需的。他们还想要通过OM的任何修改决不会把将来的日期放到此字段中。以下XML是工作项类型作者如何处理这一问题。

<HELPTEXT>Defines when a bug was fixed.</HELPTEXT>

</FIELD>

</FIELDS>

.

</FIELD>

.

</FIELD>

.

用户提交新的故障，fixed on字段为空且不可编辑。用户打开故障并将状态从RESOLVED改为CLOSED。用当前时间填充字段fixed on并且不可编辑。一个会议打断了用户。一个小时以后，他们保存修改。当提交故障修改时，把Fixed On字段中的旧时间更新为服务器时间。

16 使用索引来提高查询性能

工作项类型作者正在添加新的字段CustermerID，他知道该字段将被大量用于查询。他想要确保对此的查询性能是非常好的。

16.1 XML示例

<FIELD refname="MyCorp.CustID"name="Customer ID"type="String"

indexed="true">

<HELPTEXT>Enter a Customer Id using format AA.NNN</HELPTEXT>

</FTELD>

16.2 用户界面处理

不需要任何终端用户UI修改。工作项类型编辑器将允许你看到是否索引了字段。

并改变该值？

16.3 OM/BRIE处理

索引字段。

16.4 规则范围处理

不适用。

16.5 情形

我们应确认这将提高性能。例如，创建10,000个记录。在清除高速缓存和加载高速缓存的情况下测试查询性能。使用工作项类型编辑器改变要索引的主字段。重新运行查询。预期行为是对清除高速缓存中内容的情形有显著提高的性能。而对有高速缓存的数据的情形有较小的或没有性能提高。

17 在报告中包括自定义字段值

工作项类型作者正在添加新的字段CustomerID，他知道在报告中将大量使用该字段。他想要确保顾客id数据在数据仓库中可用。

17.1 XML示例

<FIELD refname="MyCorp.CustID"name="Customer ID"type="String"

reportable="detail">

<HELPTEXT>Enter a Customer Id using format AA.NNN</HELPTEXT>

</FIELD>

17.2 用户界面处理

不需要任何用户界面修改。一旦把此字段结转到仓库中，Rosetta报告作者就应使此字段可用于报告中。工作项类型编辑器应允许作者看到字段是否是可报告的。

17.3 OM/BRIE处理

应当按适当定义的时间间隔把此字段有值的所有工作项结转到仓库中。

17.4 规则范围处理

不适用。

17.5 情形

向新工作项类型提供自定义字段。创建一些工作项。转到Rosetta并创建使用该自定义字段的报告。运行报告以验证其生效。

18 强制执行审查跟踪

使用Currituck，用户可为工作项类型定义他们自己的状态。重要的是注意对状态名称没有任何约束。我们将为工作项类型提供一些核心级的审查，如对工作项的每次修订改变了什么的完全审查跟踪，并且我们将跟踪Created On、Created By、Last Modified On和Last Modified By值。

当顾客可从历史日志(即，对话控制)中取得状态进入/退出信息时，顾客可能想要能够对工作项最近何时进入或从特定状态退出，以及谁进入或退出了该状态运行查询。他们还想要此信息不可被用户修改，以使他们具有安全的审查跟踪。这支持如对其自己状态的Resolved On和Resoved By(退出Resolved)或Activated On、Activated By(进入Active)等查询。以下示例确定对Resolved On和Resolved By状态这是如何进行的。

18.1 XML示例

<FIELD refname="MyCorp.Resolvedon"name="Resolved On"

type="DateTime"/>

<FIELD refname="MyCorp.ResolvedBy"name="Resolved By"

type="String"/>

.

</FIELD>

</FIELD>

</FIELDS>

</STATE>

</FIELD>

</FIELD>

</FIELDS>

</STATE>

</FIELD>

</FIELD>

</FIELDS>

</STATE>

</STATES>

.

18.2 用户界面处理

这些规则指示何时工作项是Active(活动的)，Resolved On和ResolvedBy字段为空的。这些字段在UI中将表现为是只读的，并且将不具有任何值。

当决定工作项时，这些字段将是required(必需的)(必须不为空)并在第一次更新时即设为服务器时间和当前用户，然后冻结。成为必需是确保字段有值。当第一次把工作项保存在Resovled状态时，SERVERDEFAULT将其设为服务器时间和用户。冻结确保在设置ResolvedOn和Resolved By值以后不会修改它们。

当关闭工作项以后，这些字段是必需的(必须有值)和冻结的(没有人可改变其值)。

如果重新激活工作项(转移回到Active状态)，则清除这些字段。

18.3 OM/BRIE处理

此情形更加复杂，并且示出若干规则<EMPTY/>、<FROZEN/>、<SERVERDEFAULT>和<REQUIRED/>的协调。这些规则应当联合工作以允许用户审查自定义状态。

18.4 规则范围处理

不适用。

18.5 情形

见上。

19 不允许由用户/组进行转移

顾客想要将安全应用于转移以允许一些用户和组进行某些转移并禁止其它用户和组进行相同操作。

19.1 XML示例

</TRANSITION>

19.2 用户界面处理

对于V1没有特殊用户界面处理。在V1栏以上，我们从state字段上的下拉列表移除状态值，从那里我们知道用户没有进行转移的许可。

19.3 OM/BRIE处理

后端应当在允许保存工作项类型前确保用户有进行状态转移的许可。如果禁止用户访问，则后端应通过UI向上报告出错。例如，“You do nothave permission to transition the work item from Resolved to Complete state”。

19.4 规则范围处理

不适用，这些构造仅对转移有效。

19.5 情形

19.5.1 AllTesters的成员

允许用户执行转移。

19.5.2 NewTesters的成员

不允许用户执行转移。

19.5.3 AllTesters和NewTesters两者的成员

不允许用户执行转移。禁止取得优先。

19.5.4 既不是AllTesters也不是NewTesters的成员

不允许用户执行转移。任何ALLOW/DENY构造限制隐含的“可访问此工作项的任何人被允许转移”。

19.5.5 仅允许某个用户

可为这些规则指定特定用户，但是每个转移只能有一个<ALLOW>或<DENY>。

开放式问题：确认此陈述

20 在收官阶段请求代码检查

工作项作者正试图强制执行以下公司策略，当开发项目处于收官阶段(end-game)时，所有故障必须是由与所分配的用户不同的某个人检查的代码。它们还想要确保没有一个人围绕此过程进行工作。

我需要我们所没有的三件事来实现此规则

when从句将字段值与当前用户相比较<WHEN field=”fieldname”value=”currentuser”>

当字段不是特定值时的转移停止从句<ALLOWWHEN field=”fieldname”value=“somevalue”">

绕开<ALLOWWHEN>规则的方法

20.1 XML示例

<!--Field that a code reviewer sets after the review

<FIELD refname="MyCorp.CodeReview.Reviewed"name="Reviewed"

type="String">

<HELPTEXT>Set to true when the bug′s fix has been code

reviewed</HELPTEXT>

</ALLOWEDVALUES>

</WHEN>

<!--Field that contains code review comments,primarily used to

pass alongthe reason for a failedcode review.Comments are required.

<FIELD refname="MyCorp.CodeReview.ReviewNotes"name="Review

Notes"type="RichText">

</WHEN>

</WHEN>

</WHEN>

<FIELD refname="MyCorp.CodeReview.ReviewedBy"name="Reviewed By"

type="String">

<HELPTEXT>The user id of the person who reviewed the

workitem</HELPTEXT>

</WHENCHANGED>

</FIELD>

.

20.2 用户界面处理

在下文描述。

20.3 OM/BRIE处理

在下文描述。

20.4 规则范围处理

不适用。

20.5 情形

20.5.1 项目进入收官阶段

当项目进入收官阶段，工作项类型作者添加规则<ALLOWWHEN>来有效地阻止在没有执行代码检查的情况下到Resolved的任何转移。

20.5.2 Bob修复故障

Bob修复了分配给他的故障。他还没有时间读关于他们已经处于收官阶段的电子邮件，因此他没有要求任何人进行代码检查。他选择State并将值从“Active”改为“Resolved”。和在收官阶段之前一样，设置Reviewed字段为“notdone”，而Review记录为空。两个字段都是只读的。

Bob点击保存。后端报告出错“Unable to transition from Active toResolved，the field“Reviewed”must have the value“passed”.”。Bob看到项目现在处于收官阶段，并且他需要检查他的修改代码。

好，假定Bob右击工作项并选择“Send To”，这创建了带有到此故障的URL的电子邮件消息。Bob输入一些文本以要求Sam进行代码检查。

20.5.3 Sam检查了故障

Sam转到该故障并查看链接标记。他看到了到Bob所进行的修改集的链接。他双击该链接来转到Hatteras并选择每个源文件并进行“区别原有文件”。在检查以后，Sam调出该故障。

被检查的字段对他而言不是只读的，并且他将值改为“passed”。现在如所要求而高亮突出Review Notes(检查记录)字段。Sam填入了简单的记录。关闭高亮突出，Sam保存故障并向Bob发送电子邮件。

20.5.4 Bob解决了故障

Bob调出该故障并从Active转移到Resolved。这次它生效了。

20.5.5 给予故障例外

在另一种情形中，故障可能需要在没有检查的情况下***，因此需要有方法使某些个人能够绕过该过程。在此情形中，<ALLOW>规则优先于<ALLOWWHEN>规则。TriageLead可解决故障，而无论它是否是经检查的代码。

21 通知列表情形

这里的基本情形是顾客想要为给定工作项维护通知列表。只要编辑工作项，就向通知列表上的所有用户发送电子邮件。

我不确定BIS事件通知是否支持此情形。假定它不支持，则我将如下进行尝试。注意，这可能是可扩展性的问题，而不是WIT的问题。

我试图将此从规范中移除，但不要现在就丢掉它。

21.1 XML示例

<FIELD refname="MyCorp.NotifyList“name="NotifyList"

type="PlainText">

<HELPTEXT>Add your user id for notification.Separate user ids with

semi-colons</HELPTEXT>

</FIELD>

21.2 用户界面处理

不适用。

21.3 OM/BRIE处理

不适用。

21.4 规则范围处理

不适用。

21.5 情形

用户编写监听任何工作项改变事件的事件句柄。如果有事件进入并且“NotifyList”字段中有值，则它构造电子邮件并发送给通知列表中的所有用户。

22 请求复制链接

顾客想要强制执行下列规则，解决了故障，并且原因是“Duplicate”，则要求已经建立至少一个复制链接。

这里需要新事物：

测试该字段的一些方法，使用了<ALLOWWHEN greaterthan=“0”>

当然，这隐含许多的事物，像lessthan，equals，notequals等。

我们需要探索这一个问题，因为它是我认为我们没有良好的回答的一个简单的问题。

22.1 XML示例

<ALLOWWHEN refname="System.DuplicateLinkCount"

greaterthan="0"/>

.

22.2 用户界面处理

见下。

22.3 OM/BRIE处理

后端应为每个链接类型维护核心字段，并对被创建的该类型的链接的个数进行计数。

22.4 规则范围处理

不适用。

22.5 情形

用户试图在没有建立任何复制链接的情况下，以原因Duplcate将工作项转移到Resolved。将提供出错“You are unable to transition toResolved for reason Duplicate，field Duplicate Link Count be greater than0”。

Claims

1.一种调控影响工作项跟踪***的一个或多个工作项的用户动作的方法，所述方法包括以下动作：

(A)响应于影响所述工作项跟踪***的第一工作项的第一用户动作，确定对应于所述第一用户和/或所述第一工作项的一个或多个工作项规则；

(B)诠释所述一个或多个被确定的工作项规则；以及

(C)基于对所述工作项规则的诠释来响应所述第一用户动作。

2.如权利要求1所述的方法，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于所述第一用户或所述第一用户所属的用户组，以及

其中所述动作(B)包括诠释所述至少一个被确定的工作项规则。

3.如权利要求1所述的方法，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于工作项的内容，以及

4.如权利要求1所述的方法，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于工作项的一个或多个属性，以及

5.如权利要求1所述的方法，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于产品的至少一个方面，以及

6.如权利要求1所述的方法，其特征在于，还包括：

(D)提供使用户能够定义一个或多个工作项规则的用户界面。

7.如权利要求1所述的方法，其特征在于，所述工作项跟踪***包括按逻辑分层结构组织的多个工作项规则、包括所述一个或多个工作项的多个工作项，

其中第一工作项对应于所述分层结构的第一级，且第二工作项对应于所述分层结构中优先于所述第一级的第二级，

其中所述动作(A)还包括确定对应于所述第一工作项的第一工作项规则，以及确定对应于所述第二工作项的第二工作项规则，以及

其中所述动作(B)包括诠释所述第一和第二工作项规则，并至少部分地基于所述分层结构中优先于所述第一级的所述第二级，用对所述第二工作项规则的诠释覆盖对所述第一工作项规则的诠释。

8.如权利要求1所述的方法，其特征在于，所述工作项跟踪***至少分布在第一网络元素和由一个或多个通信介质连接到所述第一网络元素的第二网络元素上，所述第一网络元素包括第一模块，所述第二网络元素包括第二模块，所述方法还包括以下动作：

(D)所述第一模块从用户接收指定影响所述第一工作项的用户动作的输入，

其中所述动作(A)-(C)是由所述第一模块执行的，且所述方法还包括：

(E)所述第二模块诠释所述一个或多个被确定的工作项规则。

9.一种用于调控影响工作项跟踪***的一个或多个工作项的用户动作的***，所述***包括：

第一工作项规则引擎，用于响应于影响所述工作项跟踪***的第一工作项的第一用户动作，确定对应于所述第一用户和/或所述第一工作项的一个或多个工作项规则，诠释所述一个或多个被确定的工作项规则，以及基于所述诠释来响应所述用户动作。

10.如权利要求9所述的***，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于所述第一用户或所述第一用户所属的用户组，

其中所述第一工作项规则引擎可用于诠释所述至少一个被确定的工作项规则。

11.如权利要求9所述的***，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于工作项的内容，

12.如权利要求9所述的***，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于工作项的一个或多个属性，

13.如权利要求9所述的***，其特征在于，所述一个或多个被确定的工作项规则中至少有一个对应于产品的至少一个方面，

14.如权利要求9所述的***，其特征在于，还包括：

使用户能够定义一个或多个工作项规则的用户界面。

15.如权利要求9所述的***，其特征在于，所述工作项跟踪***包括按逻辑分层结构组织的多个工作项规则、包括所述一个或多个工作项的多个工作项，

其中所述第一工作项规则引擎可用于确定对应于所述第一工作项的第一工作项规则，以及确定对应于所述第二工作项的第二工作项规则，以及

其中所述第一工作项规则引擎可用于诠释所述第一和第二工作项规则，并至少部分地基于所述分层结构中优先于所述第一级的所述第二级，来控制用对所述第二工作项规则的诠释对所述第一工作项规则的诠释的覆盖。

16.如权利要求9所述的***，其特征在于，所述第一工作项规则引擎驻留在第一网络元素上，且所述第一工作项规则引擎可用于从用户接收指定所述第一用户动作的输入，所述***还包括：

第二工作项规则引擎，它驻留在由一个或多个通信介质连接到所述第一网络元素的第二网络元素上，所述第二工作项规则引擎可用于用和所述第一模块应用所述一个或多个被确定的工作项规则不同的方式来诠释所述一个或多个被确定的工作项规则。

17.一种计算机程序产品，包括：

计算机可读介质；以及

定义了指令的、存储在所述计算机可读介质上的计算机可读信号，所述指令作为由计算机执行的结果，控制所述计算机执行调控影响工作项跟踪***的一个或多个工作项的用户动作的一种过程，所述过程包括以下动作：

(B)诠释所述一个或多个被确定的工作项规则；以及

(C)基于对所述工作项规则的诠释来响应所述第一用户动作。

18.如权利要求17所述的计算机程序产品，其特征在于，所述过程还包括：

(D)提供使用户能够定义一个或多个工作项规则的用户界面。

19.如权利要求17所述的计算机程序产品，其特征在于，所述工作项跟踪***包括按逻辑分层结构组织的多个工作项规则、包括所述一个或多个工作项的多个工作项，

20.如权利要求17所述的计算机程序产品，其特征在于，所述工作项跟踪***至少分布在第一网络元素和由一个或多个通信介质连接到所述第一网络元素的第二网络元素上，其中所述第一网络元素包括第一模块，而所述第二网络元素包括第二模块，所述过程还包括以下动作：

其中所述动作(A)-(C)是由所述第一模块执行的，且所述过程还包括：

(E)所述第二模块诠释所述一个或多个被确定的工作项规则。