I'm considering storing the URI for a workitem from our TFS environment in our helpdesk system, however looking at the URIs TFS gives us (vstfs:///WorkItemTracking/WorkItem/327), there doesn't appear any recognition of which team project it is associated with, which makes me wonder how meaningful they are?
Is it possible to load a workitem by just URI? Or will I have to store the Project URI as well?
The work item URI is unique across the Team Foundation Server in TFS 2008/2005 or across the entire Project Collection in TFS 2010 (TFS 2010 has a new notion of project collections - see here for more information). The Team Project that it is in does not affect the ID.
Therefore to have a unique reference to the work item so that you'll always be able to get to it in the future you need a TFS server URI and a Work Item URI (i.e. http://tfsserver:8080/ + vstfs:///WorkItemTracking/WorkItem/327)
If you will only ever have a single TFS server or a single TFS project collection in TFS 2010 that your CRM system is attached to then you can assume all work items are linked to a single TFS Url.
The URI is meaningful since the item number at the end of the URI is unique and links to the item in TFS. I think storing this URI in another system makes sense considering the fact that it contains the identifier of the item.
Related
I am trying to import a work Item from TFS to Azure and I want all the link types associated with the work Item to be imported in Azure. we have lot of custom fields and links in TFS. What can I do if the link type exists in TFS but does not exist in Azure. Can I do any mapping like how we do for field mappings.
For example in TFS , I have a User story implements (link type) a spec but in Azure I want to use User story references (link type) a spec.
So when I am importing a user story with specs linked to it and link type 'implement' it should convert it to 'references' when it imports. Is it possible?
You'll need to use the Azure DevOps Migration Tools, and create a mapping configuration specifying the from/to of work item types, fields and relations.
You'll probably need to build a WorkItemLinkEnricher to map from one link type to another.
You could also do an as-is import of the project collection and leave it in XML mode, that way the existing links will migrate over, but you won't have all the advantages of the new Process Model in Azure DevOps.
I have a TFS2018 on-premise and Azure DevOps Server on-premise with many collections, and my goal is to migrate workitem from one collection to another within each server.
" You can only move work items from one project to another project within the organization or collection . " - said https://learn.microsoft.com/ru-ru/azure/devops/boards/backlogs/remove-delete-work-items?view=azure-devops&tabs=browser#move-a-work-item-to-another-project .
What does it mean within the organization ? From one collection to another? :)
So is it really possible?
Thanks in advance
within the organization or collection - its just within Azure DevOps Organization (old VSTS) and Azure DevOps Server (or TFS) Collection. Organization = Collection. We can not move a work item into another collection or organization.
TFS/Azure DevOps Server include three level, sever level--collection level--team project level
Azure DevOps Service include two level organization(equal to default collection)level--team project level
It's not able to migrate WIT from one collection to another in TFS server.
Another evidence to prove is work item ID, it's unique in a single team project collection.
Work Item ID
The unique identifier that is assigned to a work item. Work item IDs
are unique across all team projects and within a team project
collection. Reference name=System.Id, Data type=Integer
If you are able to migrate across team project collection, how would you handle a work item with same ID in different collection.
Actually this ID is stored in TFS database and have various purposes such as work item query, TFS API and so on. Each collection has it own's database.
You cannot move items from collection to collection, you'll need to export them to excel and then remap to the new collection/Azure DevOps Account and publish them, like Patrick mentioned those items will not have the same number they will be created with a new number. There are others ways to do this, you can use the REST api and write some .NET or PowerShell code, or you can try and use Martin's migration tool (https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration).
I have a PBI in TFS under ProjectA with an iteration and area value filled in. Is it possible to move this PBI to ProjectB without creating a new PBI?
I am not seeing a way in the Visual Studio UI to do this. If I try to manually type in the area path of ProjectB, Visual Studio says that the path cannot be found.
I am using Team Foundation Server 2013 and Visual Studio Ultimate 2013.
No. Work items cannot be moved between team projects.
The reason is simple: The process template of the team project defines the work items. Team projects can have different templates. What if you tried to move a work item from a team project using a Scrum template to one using a CMMI template?
I would go a little deeper and say that if you need this feature then you should not have two Team Projects in the first place.
http://nakedalm.com/one-team-project/
The term that I use is:
"If you have artifacts that interact, with artifacts defined as people, code, or work items, then they should be in a single Team Project"
http://nakedalm.com/creating-nested-teams-visual-studio-alm/
Using a single Team Project can give you many more capabilities at the backlog/ work tracking perspective. Like the nested teams described above.
EDIT: This does not work for TFS2017 and forwards.
Yes, see http://www.codeproject.com/Tips/1018002/Yes-You-Can-Move-TFS-WorkItems-Between-Projects for a downloadable utility, source and a more detailed explaination.
It is a backdoor, SQL Manager approach, not supported by Microsoft, but it works for me. Here is the SQL:
UPDATE [Tfs_xxx].[dbo].[WorkItemsAre] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsLatest] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsWere] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
With the Tfs_xxx being replaced with Tfs_<your collection database name>.
Essentially, the project is inherited from the Area and the Iteration. Changing these from the current project to the target project causes the workitem to "move" to the target project. Additional rough edges are that the assignment pool or the workflow states might not align and have to be edited mannually in the UI to get the workitem back in the flow of the target project.
See my related answer.
Though not applicable to TFS on-premise, one can now do this with Azure Boards in Azure DevOps.
I have a TFS 2010 Work Item Type with a custom field called "Requested By." This field can be populated with any name, but since most of the requests come from project developers throughout the organization, the SUGGESTEDVALUES property should populate the dropdown list with members of any TFS team project.
I have tried various values for SUGGESTEDVALUES, but both Collection\ Project Collection Valid Users and Server\ Team Foundation Valid Users seem to return every valid Active Directory account—well over 10,000 names.
I recognize that one option is to add an ALLOWEDVALUES item with multiple LISTITEM entries for Project\ Contributors for every team project, but with more than 150 team projects in the organization, this would be time-consuming initially and challenging to manage in the future.
Is there any easy way to populate the drop-down with TFS valid users who have actually been assigned to any team project in the collection, and exclude "Valid" users who exist in Active Directory but have never been assigned to a project?
What do you get if you use Project Collection Valid Users?
Project Collection Valid Users is the correct group to use, and I have entered it correctly.
However, one project team wanted to make their code available to the entire organization, and added ORG\Domain Users to the [Project]\Readers group. This was discovered by running a full audit with TFS Projects based on a hunch that something like that must have happened.
Having answered this question with "because a project team was doin' it wrong," I have posted a follow-up question to find out how to correctly grant all valid TFS users access to a specific project. See How can I grant Team Project access to all Project Collection Users? for the discussion on (hopefully) doing this "the right way."
I'm looking for a way to add work items into tfs from the project portal that it creates. Basically we want our helpdesk to be to raise workitems inside of tfs, so we can then track the build etc that there fixed in.
Can anyone shed any light on this?
Microsoft released the Visual Studio Team System Web Access 2008 Power Tool.
Base download
Service pack 1
Team System Web Access SP1 lets you do all the things you can do in Visual Studio in your browser. You can view, create, and edit work items, associate work items with each other and with changesetsand view source, diffs, changeset contents, and branches.
SP1 also includes what was once called TFS Work Item Web Access. Work Item Web Access lets users without TFS licenses submit and view work items through the browser.
With a little SharePoint magic you should be able to frame Team System Web Access within your existing team sites.