views:

17

answers:

2

When adding a work item to TFS 2010 via the SDK, the incidents are created using the same identity that was used to authenticate to the TFS server.

In other applications providing defect tracker/work item support the API normally allows you to set a Reporter/ReportedBy/CreatedBy field, so you can make it appear as if the user your service is creating the issue on behalf of "has created the issue", rather then say a generic "service account" you have setup to allow a 3rd party application access to TFS/defect tracker.

It appears you can not set the CreatedBy field when creating a work item via the TFS SDK (you get a TF26194 - The value "Created By" cannot be changed" error) and I can't see any Reporter field that comes as standard with the common TFS templates.

Is it possible to set the "Created By" to another user, or impersonate another user (without knowing their password etc.) for the purposes of creating new work items?

+2  A: 

The CreatedBy field is important in terms of accountability regarding who enters data. In my organization, we added an additional user field for use when the work item is created on behalf of another user.

You can use the Process Template Editor (part of the Team Foundation Server Power Tools) to easily add fields to your work items.

kbrimington
I do like the idea of a separate reporter field - but in this case all work items would be created by a single "service" account - so it's not particularly useful - especially when it comes to email alerts etc.
Bittercoder
+1  A: 

Interesting question. We were looking for an answer for TFS 2008 (there doesn't seem to be one), and found this one for TFS 2010. I'm interested to know if this works for you:

http://blogs.microsoft.co.il/blogs/shair/archive/2010/08/23/tfs-api-part-29-tfs-impersonation.aspx

Robaticus
This worked OK - only catch - you can't authenticate to TFS by providing Network Credentials (where the credentials are for a user with the "Make requests on behalf of others" permission), and then impersonate another user from there.Instead the impersonation permission check is actually on the user who own's the entire process, so in the case of our application this was the identity associated with the IIS application pool.Implication being we cant use impersonation if the IIS server hosting our application is on a different domain etc.
Bittercoder
True. I believe you could add the IIS user to the groups on TFS, though.
Robaticus