Team Foundation Server Using Custom Fields instead of System Fields - tfs

I'm introducing TFS 2010 in our company.
After a lot of work on item customizations, I'm considering using custom fields as some system fields.
One example...
I've got some management requirements for the field "System.priority". This field should be set to "REQUIRED", so everyone has to do an estimation about the priority of a bug or task.
Are there any well known problems with creating an custom mypriority field and using it? (except the whole customizing afterwards for the basic reports...)
I know i cant delete the system fields but i can delete the references for system.priority from the layout tab and then im going to use my own customized ones ..
Is this possible?

Avoid creating custom fields when the default ones can serve the purpose. E.g.: Use the REQUIRED rule where needed:
<FIELD name="Priority" refname="Microsoft.VSTS.Common.Priority" type="Integer" reportable="dimension">
<REQUIRED />
</FIELD>

Related

MS TFS 2015 mandatory linking between work items

In TFS there is possibility to link work items between each other - for example PBIs to Features, or Impediments. Does anybody know - how to make these links mandatory, so for example it will be not possible to save PBI if it was not linked to feature?
I'm using TFS2015 on premises.
According to the request, you need to set the Required rule for the links control, but as far as I know the default Links control not support Required rule.
So, as workaround you can add a hidden field, then set 'Required' rule for the hidden field, thus it will prompt that you need to link to Features or other workitems when you save the PBI without any linked workitems.
Here is the example. You could add field called Links, which is hidden field and it would have the following syntax:
<FIELD name="Links" refname="lc.RelatedWorkItems" type="Integer">
<WHEN field="System.RelatedLinkCount" value="0">
<REQUIRED />
</WHEN>
<WHENNOT value="0" field="System.RelatedLinkCount">
<DEFAULT from="field" field="System.RelatedLinkCount" />
</WHENNOT>
<HELPTEXT>This is a hidden/internal field that will help to force the user to associate the work items.</HELPTEXT>
</FIELD>

TFS work item : setting a field required based multiple fields

I have a TFS form, where I need to set a field as required based on two fields when the state changes to closed.
<STATE value ="Closed">
<FIELD refname="Microsoft.VSTS.T1">
<WHENNOT field="Microsoft.VSTS.T2" value="Yes">
<REQUIRED />
</WHENNOT>
</FIELD>
</STATE>
The above code works fine, when T2 is Yes, T1 is required. However, I need to add the following condition : When T2 is Yes and T3 is not NA, then T1 should be Required. Else it should not.
I know nested conditions are not allowed in TFS, but is there a work around for this?
You are right that nested conditions are not allowed in TFS, but TFS allows customer develop controls to be hosted in work item form. Those controls can implement various business logics or add additional functionality to work with the workitemform. You need to customize a work item control to achieve your requirement. More information, check https://witcustomcontrols.codeplex.com/

How to disable TFS workitem link funcationality when the workitem is in Removed state?

For example, if there is a Product Backlog Item in Removed State, how can I prevent team to add tasks or test cases to it?
I originally thought of setting the workitem as FROZEN. But it might not work if we need to be able to reactivate the PBI when requirement changes.
Education.
You need to train your users in use of the system so that they don't make amateur mistakes like that.
There is no way in the tool to prevent links based on state.
I'd go for #MrHinsh's answer by default.
I haven't tried this myself as yet, but I think it should work... I'll delete the answer if it doesn't.
To make a work item read only for most people, while still allowing selected users to edit it you can put the work item into a situation where the validation rules fail for most but succeed for the selected users. That way, people can make the changes but can't save them.
For example, add a field such as the following:
<FIELD name="ReadOnly" refname="My.ReadOnlyFlag" type="String">
<WHENNOTCHANGED FIELD="System.State">
<PROHIBITEDVALUES expanditems="true" for="[Project]\Contributors">
<LISTITEM value="true" />
</PROHIBITEDVALUES>
<HELPTEXT>The work item is now locked. No changes can be saved</HELPTEXT>
</WHENNOTCHANGED>
</FIELD>
Then in the transitions to the Removed state, set the My.ReadOnlyFlag value to true.
See how you go with that approach and whether it works for you.

Assigning users in TFS if two fields have specific values

Updated question with additional info as solution was not applicable.
Sorry, I will have to ask this question once again. My objective is to implement some TFS automation for the Assigned To field. This field is to be populated certain values in the module and category field are selected.
Is there a way to create an "And" operator within the TFS WI XML that can handle this? I asked this question a couple of months ago and received an answer. Unfortunately, I haven't had time to implement it due to several items that came down the pipe. When I tried implementing the solution and when importing the WIT, TFS would throw a "WHEN" has an invalid child element "WHEN" error.
Example:
If "Module" field = value X and "Platform" field = value Y, then "Assigned to" field is set to specific user
Given solution does not work:
<FIELD name="QA Owner" refname="<QAOwnerFieldReference>" type="String">
<VALIDUSER />
<WHEN field="<ModuleReferenceName>" value="Compliance">
<WHEN field="<AnotherFieldName>" value="SomeValue">
<DEFAULT from="value" value="<QATester>" />
</WHEN>
</WHEN>
</FIELD>
I do have an idea, is it possible to merge the second "WHEN" condition with the first, such that:
<WHEN field="<ModuleReferenceName>" value="Compliance" && WHEN field="<AnotherFieldName>" value="SomeValue">
Link to previous post: Assigning users in TFS if two fields have specific values
What you need to do is to cascade two conditions, to create an and effect. Not ideal, but what'll you do :)
Here's what your WIT field definition could look like:
<FIELD name="QA Owner" refname="<QAOwnerFieldReference>" type="String">
<VALIDUSER />
<WHEN field="<ModuleReferenceName>" value="Compliance">
<WHEN field="<AnotherFieldName>" value="SomeValue">
<DEFAULT from="value" value="<QATester>" />
</WHEN>
</WHEN>
</FIELD>
The only viable solution I could find for this is to create a custom control that will process a set of rules before saving the work item.
Check out Gregg Boer's blog for a short guide to creating WI custom controls. Note that this will need to be installed on each desktop client's machine.
Note that you will want to write a handler for the BeforeUpdateDatasource event.
Also, if you need this to run on the web, you'll need to create a web-access custom control (see Ewald Hoffman's post on WA controls).

TFS 2010 - anyway to restrict editing of work items

Just installed TFS 2010 and noticed that the main text in work items can be edited. We'd like to freeze all editing of work items (except for admins), in order to keep a more auditable trail of discussion for each bug and minimize confusion over what the original bug was, etc.
Is there a way to configure TFS 2010 so that the main text previously entered for a work item is not editable by most users?
You can edit the process template and make the field only editable by Admins.
If you have not already, you will need to install the power tools and then open the work Item and change:
<FIELD refname="System.Description" name="Description" type="PlainText" />
To:
<FIELD refname="System.Description" name="Description" type="PlainText">
<READONLY for="[Global]\Project Collection Valid Users" not="[Global]\Project Collection Build Administrators" />
</FIELD>
You can obviously replace the groups with project specific ones. This makes this field perminantly readonly.
The entire history of the work item fields is available in the "History" -- it will show you what fields have cahnged and by whom.
What you might want to do is change your template so that both the description and history show on the same tab. Make it a standard of convention that only the history is updated, not the description.
Then, if the description does ever get changed, you can review it in the history window (along with any manually entered notes).

Resources