Hi,

We are using the MSF for CMMI templates and with the default Issue definition it seems like the Description is plain text whereas the Analysis allows rich text/HTML markup, i.e. within the VS Team Explorer when editing a Work Item.

The problem is when I then synchronise Issues which have carriage returns/new lines in the Analysis fields, the Content Controls within the Word document are displayed with the <P> and >&nbsp;

We really need this resolved asap.

Thanks,

-Pat Ramadass

Hi,

We are currently evaluating TeamSpec and we like it, but the tools inability to edit richtext/HTML fields from a work item makes it unusable to us as we have our test cases defined as work items where the description is HTML. We really want our manual testers and business analyst to get away from using VSTS/Web Access for editing test fields and start using Word with its rich editing capability.

Is this a feature you are going to provide in the near future and if so it would be nice to have an indication on when to expect this to be available?

Cheers

  Lars

 

Hello Lars,

This is a feature that has been requested again and again!  The limiting factor in TeamSpec supporting Rich Text is really two fold.

1. By default, the description field for the built in templates in TFS are deceptive!  They appear to be RichText (you can put the content in as rich text, but as soon as you save it, the formatting is stripped).  This leads to confusion for why the content is no longer Rich Text formatted.  It is possible to change the WIT (work item type) definition to use an HTML field for the description, which does support TFS. Once you do actually have a Rich Text supporting field in your WIT definition, saving the content through TFS Web or VS will keep the correct formatting.

2. Word API.  We have been fighting with the Word API to give us consistent formatting for a given region of text.  The most abstract way of looking at the problem is the following conversion to get word content into and out of TFS:
    Word -> RTF -> TFS - (potential RTF TFS edits) -> RTF -> Word
Each of these steps is a translation to a given formatting that the next piece can store.  Unfortunately, the possible set of inputs is enormous, which leads to many conversion differences.  Thus, you will likely always see differences in fields in your document even though the displayed text is "the same".  On top of all this, the word object model does very strange things and the documentation is limited.

The second issue is a difficult issue to pin down.  Most of the basic tests work fine (Bold, italics, etc), but once you start doing anything "interesting", we can never correctly save out the content and get it back into word without destroying the formatting of the document.

So, for the time being we are investigating bigger and better ways to support RTF.  And yes, it is one of the most important items on our todo list for an upcoming version.

Thanks,
~Joe