Before you consider customizing work items, you probably should be aware of existence of the “special” fields, that behave differently from the custom ones you define. In most cases you will have to use the special fields in your custom type, so to understand peculiarities of the behavior is pretty important.
Most of those fields are defined in System.XXX refname space (I will omit the namespace specifier for all System fields below); let me enumerate them and detail their behavior.
Read-only fields are always available for all work items, and yet you do not have to do anything to define them. The fields are:
- Id – work item unique (within TFS server) identifier
- TeamProject – work item Team project name
- WorkItemType – work item type name
- CreatedBy – user who created WI
- CreatedDate – datetime of WI creation
Calculated fields relate to work item links (set in LinksControl and AttachementsControl in UI). The names are self-descriptive:
- AttachedFileCount – number of files attached to WI
- HyperLinkCount – number of links (URLs) in WI
- ExternalLinkCount – number of links (version control artifacts) in WI
- RelatedLinkCount – number of links (to other WIs) in WI
Auto-updated read-only fields are different from read-only fields as they are updated every time work item is changed:
- ChangedBy – user who last changed the work item
- ChangedDate – datetime of the last change
- Rev – current revision of work item
And now, very special fields – so special that they represent a category onto themselves.
AreaPath/IterationPath fields – represent WI area/iteration. Those tree values are represented as tree in UI and can be displayed only in WorkItemClassification control. Not all behaviors are applicable to those fields (for example, they cannot be made mandatory)
And most importantly, those fields are basis for WI grouping and security model, and as such are provided separate dedicated UI. In that UI one is able to view or modify areas/iterations as well as assign permissions to them. By allowing WORK_ITEM_WRITE/WORK_ITEM_READ, it is possible to control whether certain groups of users may edit/view work items (and whatever WI appear in the WIQL reports).
State field has its values and behavior defined in dedicated WORKFLOW section.
Reason field is also defined in WORKFLOW section and its values are dependent upon state. It becomes enabled only on state change, and its behavior cannot be changed.
History field cannot be modified or used in any way except for display in WorkItemLogControl; no other behaviors are supported (by the way, similar display controls – LinksControl for WI links, and AttachmentsControl for WI files attachments – do not even have associated fields, only UI controls)
And finally, there are not so special but yet very important System fields that are recommended for use in every work item – Title (for work item title), Description (for WI textual description) and AssignedTo (for user assigned to specific WI).
Additionally, I would like to mention fields defined in different Microsoft.VSTS.XXX namespaces, that you should consider using when customizing your work items. For those fields, you do not get extra behaviors as for some of System.XXX fields, but out-of-the-box templates can be used as a good example of usage for those common fields and provide an easy start for customization. I will list several most interesting fields:
Microsoft.VSTS.Common fields
- StateChangeDate – date of the last state change
- Rank – work item priority (numeric)
- ActivatedBy/Date – date the work item becomes active (and who activated it)
- ClosedBy/Date – date the work item becomes inactive (who deactivated it)
Microsoft.VSTS.Scheduling fields
- StartDate – date of WI (task) start
- FinishDate – date of WI (finish
Microsoft.VSTS.Build fields
- FoundIn – build the WI discovered in
- IntegrationBuild – build the WI was first integrated in
FoundIn and IntegrationBuild fields provide most interesting automated behavior connected with builds. When you perform a first build in Team Project, global list with the name “Builds - [Team Project name]” is created by TFS and is associated with the fields in all work item types in the project (using SUGGESTEDVALUES behavior). The mechanism uses TFS eventing model (see the detailed post by Jason Prickett). After the list is created, each subsequent build is added to that global list and in such way available for selection in work items.
Related posts:
- Work Item Customization: fields maintenance (part 7)
- Work Item Customization: global lists (part 6)
- Work Item Customization: system fields (part 5)
- Work Item Customization: user interface (part 4)
- Work Item Customization: state transitions (part 3)
- Work Item Customization: conditional field behavior (part 2)
- Work Item Customization: fields definition (part 1)
No comments:
Post a Comment