tfs-workitem

how to get Task,Feature id,completed hours by date. lets say there is a task 123 in which was created on a sprint which start date is 1st July and end at 10th July task 123 effort hours is 5 completed hrs is 0 from 1-7-2018 and on 5th July effort is 3 hrs completed 2 hrs and on 10th July effort is 1 hr and completed is 4 hrs so how can i find task id,Feature id (by Tree WIQL) of date from 1st July to 5th July. Based on your description, seems you want to get the history (revisions) for a specific work item. If it is, then you can use the REST API to retrieve that: See Get a list of work items

i have a Hierarchical structure like this in which a Feature can have many User Stories each having one to many Tasks. But a User Story may have no parent Feature as well as some Task may have no parent User Story F1 -->U1,U2,U3 --->t1,t2,t3 I need a Wiql Query in c# by which for any Taskid input I get its parent storyid (or 0 if it has no parent) along with this latter parent Feature id (0 if it has no parent User Story) and name ('other' if Feature id is 0) You may find any parent branch for work item with this query: You can use this code to get a list of parents: using Microsoft

I would like to develop software which runs every time a work item is being created or changed in a TFS team collection. My TFS server version is 2013 and i'm planning to upgrade soon to 2015. I tried the following article but it doesn't work on 2013... What do you recommend? Found the answer! here's my code: using Microsoft.TeamFoundation.Common; using Microsoft.TeamFoundation.Framework.Server; using Microsoft.TeamFoundation.WorkItemTracking.Server; using System; using System.Collections.Generic; using System.Diagnostics; using System.Linq; using System.Text; using System.Threading.Tasks;

This is part of a larger restriction, but the part that is tripping me up is being able to allow only the user that created a work item (the value of the "System.CreatedBy" field) to transition a work item to the Closed state. I am aware of how to restrict the transition using the "For" and "Not" clauses, but those are limited to groups. I want to restrict it to the specific creator of THIS work item. VALIDUSERS is also limited to groups (either TFS or AD). Thanks for your help. Scott I was able to find a suitable solution last night. This solution actually works perfectly for my need as it

I created a GIT repository on GitHub, then created a TFS Project with Git scm and Agile process template, then I chose Import Repository and specified the GitHub URL. After the TFS Project was created I see an error message in Team Explorer: Access to the registry key 'HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\15.0_8708a912\WorkItemTracking\TeamMenu\AddWorkItemMru\TFSServer01\XYZProjectCollection\64c06df7-220f-433c-b7d6-6a59426340e1' is denied. I get a msgbox with the same error when I try to create work items. The symptom of the problem is not the root cause; the registry key doesn't

The default check-in action for a work-item is "resolve". I'd like to set it to "associate" so that this work item isn't automaticaly closed if I check-in stuff too fast. How can I do that? Martin Woodward Yup, the check-in action can only be associated to a state transition (i.e. Active to Resolved). In my blog post that Fredrick linked to ( http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html ) I talk about how to remove that. You'll need to customize the work item for everyone in your team project to make this happen. For help on that see http://msdn.microsoft.com/en-us/library/ms243849(VS

We are currently using TFS 2008 with the Scrum for Team System template from Conchango, with a few minor tweaks. We are looking at upgrading to TFS 2010 and we are considering moving to the MSF for Agile template. What is the best way to move to a new process template and keep history? I'd like to be able to create a new team project on the TFS 2010 server, get everything checked-in, and move our source to the new project. It would be nice if we could somehow keep the check-in comment history and possibly even be able to navigate back to the work item history associated with a changeset in the

We have begun using the following branching structure in TFS 2010: All changes so far have been performed in the Development branch, and all check-ins have been associated with a Task work item. The Tasks are all children either of a Bug or a Product Backlog Item work item. Each CI build is triggered for a particular changeset, and the changeset is associated with a Task, so we can manually figure out which Bug or PBI was just built. Some time after the code has been built, deployed to our Integration environment and tested by the developer, it is merged to the Main branch. Obviously, more