I didn't know how to phrase the subject or what
to use as search phrases so please excuse this
post if this has been answered previously.

I would like to have a field where the values
that are allowed come from data store on the
TF server. Specifically, since you can have multiple
solutions on any TFS project, I would like to have
an optional drop down to specify which Solution a
task is for.

Does my question make sense Instead of having
a static list or a manually maintained global list of
allowed values, I would like the field to grab it's
values directly from the TF server when the form is
opened. So something like this would be what I'm
looking for:

<FIELD name="ProjectName" refname="mycompany.agile.projectName" type="String" >
<HELPTEXT>The applicable Project</HELPTEXT>
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="[Project]\Solutions" />

Re: Team Foundation Server - Work Item Tracking Allowed values from Database...

Gregg Boer MSFT

Your question does make sense, and your suggestion is a great one. Currently, in V1 (as you probably already know), the only way to do this is via Global Lists. You could write some external program that keeps the global lists up to date with some external list.

However, your question is to list solutions, or some other TFS-specific data source. I'm wondering, what other data sources, besides solutions, do you think would be useful That information would be helpful to us.

Re: Team Foundation Server - Work Item Tracking Allowed values from Database...


Hmmm... other info that might be helpful... well
I remember seeing a post about build numbers,
(they wanted to have a drop down of the builds
that have been performed)

To get more fine grained, this would be more
for testers to submit specific bug reports, it
might be useful to also be able to specify the
VS project as well.

Now let me explain what I mean by that because
I find the MS terminology somewhat confusing.

TF server has Projects
---- TF projects can contain many VS Solutions
---------- Each VS solution in turn can have Projects
(Which I call VS projects)

So for a tester it might be helpful to say:

There is a bug in TF Project Enron, VS Solution
Accounting, VS Project DAL.

Does that make sense So if you could have
a dependent combobox such that you pick the
solution and then depending on the solution you
picked you would get a selection of VS projects
for that particular solution.

This might be useful for task allocation for a project
manager on regular feature requests and such. A
regular user might not specify anything because
he/she might not know the proper place to put the
request. However after the task has been submitted,
a Project Manager can look at it and say, Oh this is
a request for the Accounting Group, specifically the
GUI. Then people in that group can create task filters
to only look for things that appear in their specific
expertise instead of seeing all the tasks for the entire
TF project. What do you think Am I being a little too

Thanks for the quick reply though!

Re: Team Foundation Server - Work Item Tracking Allowed values from Database...

Dan Kershaw

Thanks for the feedback.

Typically we use the "area path" (which is scoped to a project) to classify a work item into a particular area, so that you could query for, say active bugs under "Enron\Accounting\Data Access Layer". You can create the area tree structure by right-clicking on the project node, and selecting "Areas and Iterations...". The work item types that are part of the CMMI and MSF Agile process templates already reference this area path as a tree list.

Is this what you are looking for

Re: Team Foundation Server - Work Item Tracking Allowed values from Database...

Gregg Boer MSFT

This is good stuff. I've logged this in our product idea data to look at for a future release.

And I don't think you are needy at all. The purpose of this product is to make it easier for you to do your job. "Laziness is the mother of invention" :-)

Thanks for taking the time to give feedback. These are great ideas!

Re: Team Foundation Server - Work Item Tracking Allowed values from Database...



That could work, but I'm not a big fan of it for 2 reasons:

1) Unless I am mis-informed about areas & iterations,
     you must set the up manually (which is what I am
     trying to get away from).
2) With this approach, unless I am mis-interpreting what
     you wrote, you are structuring your areas/iterations around
    you architectural components instead of your deliverables/
    milestones.  This means that instead of planning my iterations
    according to "Milestone one with features X, Y and Z implemented"
    I am planning around "Data Access Layer".  This wouldn't work
    for me (and for most iterative projects I would guess).