I got a call from one of my customers that when a user is trying to open work item he get the error- 
From looking inside the template of the work item I saw that the filed have a rule of VALIDUSER, from further investigation I found that the user was renamed from Cathy Smith –> Cathy Jones.
Each team the work item was opened the value “Cathy Smith” was thrown as an error since the user “Cathy Smith” didn’t exist anymore.
The solution to the problem was to add to the field the rule ALLOWEXISTINGVALUE, This rule allows a previously entered value to still be valid even if that value is no longer a valid value.
After a while of working with TFS work item, a lot of data is been assembled inside the TFS. This data can be access by the TFS quire and even can be exported into Excel sheet, but what about exporting the data into Word document?
There are a few tools in the market that you can use to export the data to Word document but none of this tools will export the data and will generate the report with the correct hierarchy format that will represent the hierarchy of the data and will also will create the report using a few general roles on the data.
With the great help of Lior Amsalem we created a project which purpose is to auto generate documents that are related to any type of data stored on the TFS. The documents can be tailored documents according to TFS specific data, or standard reports that are required by regularity needs (FDA, ISO or…), or internal company's development documents (STD, STR, Project Plan…).
The project is based on a few layers
- DAL - The system is using a layer that connects to TFS on top of the TFS APIs and handles all communication and data retrieval from the TFS.
- BL - There is a reporting data layer which is responsible to build custom data structures according to the reports we need.
- UI – The actual reports generation is using OPEN XML SDKs in order to generate any type of office documents (Word, Excel…).
For example in one of the company that I advise for, they MUST produce a document that describes the requirement from the product (for FDA needs). They have dozens of work items that describe the product requirement, in the past they have produce the document by hand (copy and paste of work item data into word document) and it took them between 2-3 days with the hope that no mistake was done in manual process.
For the purpose of automatic documentation generation we have developed an infrastructure that can read a TFS quire “Report Product Requirement”
and generate a word document with full hierarchy format of the work items
The product requirement document was the simplest document that was “Automatic generated”, we have also created a SRS (software requirements specifications) and STM (software traceability matrix) which involve also the Test runs results and test cases.
