Dela via

All WITD XML elements reference

  • Artikel

You can customize an existing work item type (WIT) or create a WIT to meet your project tracking requirements. A WIT defines the rules, fields, states, and transitions for an item of work that will be tracked for a team project, such as a bug, requirement, or risk.

A WIT cannot be empty. The root element in each definition of a WIT is the WITD element, which must have only one WORKITEMTYPE element defined. The name of each WIT must be unique in a team project, and each type name must be no more than 254 Unicode characters long. For more information, see Naming conventions for work item tracking objects.

To customize or create a WIT definition, you modify the type definition XML file. You maintain and manage definitions of types of work items for each team project.

WITD syntax structure

The following example shows the high-level structure of a WIT definition.

<WITD application="work item type editor" version="1.0">
    <WORKITEMTYPE name="bug">
        <DESCRIPTION>Bug work item types are used to track defects in the code.</DESCRIPTION>
        <GLOBALLISTS> . . . </GLOBALLISTS>
        <FIELDS> . . . </FIELDS>
        <WORKFLOW> . . . </WORKFLOW>
        <FORM> . . . </FORM>
    </WORKITEMTYPE>
</WITD>

A small number of XML elements appear between WORKITEMTYPE tags at the highest levels of the WIT definition. You start defining a WIT by providing a name and a description. You also use certain standard XML tags to wrap the WIT definition.

WITD child elements

The structural elements used in the previous example are described in the following table:

Element

Description

WITD

The complete WIT definition is wrapped by the tag WITD. You can use any name for the application name. The version identifies the schema of the work item type that changes from one release to the next. Use "1.0".

<WITD application="Work item type editor" version="1.0 [1]">
   <WORKITEMTYPE> . . .</WORKITEMTYPE>
</WITD>

WORKITEMTYPE

Names of WITs must be unique in a specific team project. At run time, you use the name specified by this element. For example, the name can appear as a menu option. In this case, a user could choose Bug on the New Work Item menu.

<WORKITEMTYPE name="WorkItemTypeName">
    <DESCRIPTION>Text</DESCRIPTION>
    <GLOBALLISTS> . . .</</GLOBALLISTS>
    <FIELDS> . . . </FIELDS>
    <WORKFLOW> . . . </WORKFLOW>
    <FORM> . . .</</FORM>
</WORKITEMTYPE>

DESCRIPTION

Specifies a string that describes the type of work item that you are defining. The description should help any user who is customizing the WIT.

Note

You can view the description only in the XML definition. You cannot view the description anywhere in the user interface, and it has no relationship to the field System.Definition.

<DESCRIPTION> DescriptionOfWorkItemType</DESCRIPTION>

You specify a string of text that describes the type of work item that you are defining.

GLOBALLISTS

Contains the global list definitions that are used by the work item type. You use global lists to share list items among multiple work item types for a team project collection. Using global lists provides support for ease of maintenance and cross-group collaboration.

<GLOBALLIST name="globalListName">
    <LISTITEM> . . . </LISTITEM>
</GLOBALLIST>

For more information, see Define global lists.

FIELDS

Contains the set of field definitions that are used by the WIT. Within the FIELDS element, you define all the fields that you want to use to track data for the type of work item. This includes fields that you will use to run queries and generate reports.

<FIELDS>
   <FIELD> . . . </FIELD>
</FIELDS>

For more information, see Define and modify work item fields.

WORKFLOW

Contains the set of STATE and TRANSITION elements that define the workflow. The workflow is a set of valid transitions from one state to another and the specific conditions associated with each transition.

<WORKFLOW>
   <STATES> . . . </STATES>
   <TRANSITIONS> . . . </TRANSITIONS>
</WORKFLOW>

For more information, see Change the workflow for a work item type.

FORM

Contains LAYOUT, CONTROL, GROUP, TAB, TABGROUP, SPLITTER, and other elements that define which fields and controls appear on the form and the display of these elements on the form.

<FORM>
   <Layout> . . . </Layout>
</FORM>

For more information, see Design the work item form.

Process template work item types

TFS provides three default process templates. These files are located in the following directory:

%programfiles%/Microsoft Team Foundation Server 12.0/Tools/Deploy/ProcessTemplateManagerFiles/1033

You can find the work item type definitions in the WorkItem Tracking\TypeDefinitions folder. For more information, see Work with team project artifacts, choose a process template.

You can customize or create type definition files in the TypeDefinitions folder. Then you can import your new work item type to a single project, or you can add it to your process template and upload the modified template to your Team Foundation Server. For more information, see Add type definitions for work items to a process template.

See Also

Concepts

Customize work tracking objects to support your team's processes

Other Resources

witAdmin: Customize and manage objects for tracking work