I am working adding some customization to TFS 2015 Update 1 work item templates. I have started with the bug template and have successfully mirrored that across multiple projects.
I now have to make changes to the feature template, those changes need to include fields of the same name due to queries that will be filtering on values in the custom field.
I am finding that I cannot resuse the custom fields from the bug in the feature template. I also cannot create a custom field for the feature template with the same name as that in the bug.
Is there anyway to do this? My custom field in the bug is named "Task Status" with a ref name of .task.status.
Is there any way of making this existing custom field usable across template types? My end users don't want to have to duplicate queries to obtain the same data from multiple work item types.
Thanks!
I cannot reproduce this issue at my side, list my steps for your reference (I'm doing it from TFS Power Tools\Process Template Editor):
Add "TaskStatus" field for Bug and save it:
Add "TaskStatus" field for Feature and save it(The setting is the same):
Then I just need one query for both Bug and Feature work items:
Related
I need to find a way to display info to which sprint issue is assigned in issues table.
Two possible ways I see:
Through List Settings
With automatic assign of tags to issue in Sprint №
Probably there are other solutions.
Solutions for YouTrack Lite is preferable.
List Settings in Issues
Tag in issue
Both options are valid. The most common one would be using the list settings though. The main idea here is to link a sprint to a specific field value. For example, you create a field called Sprint (or whatever you want), and this field's values correspond with your sprints. For that, boards have a special setting called Link Sprints to Values for Custom Field.
After that, all you need to do is to add this sprint field to the issue list.
I am using TFS 2015 on premises and I am trying to understand the scoping of process templates and the work item type definitions within them. I have been reading a number of the reference documents provided by Microsoft, yet I still find myself confused.
https://learn.microsoft.com/en-us/vsts/work/work-items/guidance/manage-process-templates?view=vsts
https://learn.microsoft.com/en-us/vsts/work/customize/reference/process-templates/customize-process?view=vsts
https://learn.microsoft.com/en-us/vsts/work/work-items/guidance/work-item-field?view=vsts#what-is-a-field-how-are-field-names-used
The above articles clearly suggest that the work item fields are at the project collection level (emphasis added by me):
Most process template components that you customize will affect only the team project that you create by using the process template. The exceptions to this rule are global lists, link types, and work item fields. These objects are defined for a team project collection.
Why then when I import a work item type definition, do I specify a project within a collection to import it to? The importwitd documentation here states I am importing my changes to a particular project:
https://learn.microsoft.com/en-us/vsts/work/customize/reference/witadmin/witadmin-import-export-manage-wits?view=tfs-2018&viewFallbackFrom=vsts
importwitd: Imports work item types from an XML definition file into a team project on a server that runs Team Foundation Server.
I must be failing to understand some of the intricacies here, but I cant seen to wrap my head around the impact radius of making work item type definition changes.
Your team project contains 14 or more work item types (WITs), based on the process (Agile, Scrum, or CMMI) used to create the team project. A WIT is the object you use to track different types of work. When you modify a WIT, you should have known which WIT under which team project you want to modify, and export it:
witadmin exportwitd /collection:CollectionURL /p:ProjectName /n:TypeName /f:"DirectoryPath/FileName.xml"
Work item fields defined for work item types that are defined for a team project collection. Changes that you make on work item field attributes will apply to all team projects within the team project collection. If you have installed TFS power tools, you could check Work item field explorer there:
Also, you could use command to list the fields:
witadmin listfields /collection:CollectionURL /n:RefName [/unused]
Work item process template changes are scoped to a single team project. If you have multiple team projects and you change a work item type definition, you have to import it into all of the team projects where you want the change to be visible.
After (or before) we convert from TFS 2012.2 to TFS 2015.3 (which we have done just fine in a test run) we would like to revert our team project to the standard TFS 2015 Agile process template, and no longer use the customized agile process that we had modified from TFS 2012. We are quite willing to delete all of our work items and start over, but need to keep the team project history and change sets. Anyone know how to do this? Answers to prior questions on this did not address this situation. Thanks.
There is no easy way to do it. Basically the steps require you to use a lot of witadmin commands. Start by deleting any work item types that were added and don't exist in the default template.
Then push the standard work item definition for each work item type.
Then push the categories
Then push the process configuration
Then delete any fields that are no longer used
That should bring you back to the standard template.
An alternative you could try is to use the WitMorph project. You can write a set of rules to migrate your data back into working order.
I want to create a record of an entity, but I need to pass a list of guids to the pre create plugin. I don't want to create fields or related entities to do this. Can I use the Shared Variables to do it?
In other words is it possible to set shared variables before initiating the action that will trigger the plugins that will consume them?
EDIT:
I can be creating this type of records from different points that integrate with crm, silverlight, external pages or even plugins of other entities. My current problem can be solved with a field on the entity, but this way if I had to send parameters to control the execution of the plugin for two or more independent actions I would need one field for each action or instead use only one field using a complex format/parse pattern to parameterize each different action. Using fields to accomplish this feature looks a bit excessive.
If the shared variables could be set before the call of the action that will trigger the plugin that would solve the problem and I wouldn't have to create fields in the crm database, because the data I want to pass to the plugin it will only be needed at that time, like a parameter in a function, no need to persist them in the database.
But if it is not possible I will have to stick with the fields :(
Not if they vary by entity/execution of the plugin.
Options:
Set them in the plugin configuration if they don't change but need to be updated
without a recompile.
Apply them as a delimited string in a single field on the entity if they vary per record.
What's the reason for not wanting to use 2?
Nope. The easiest solution that I can think of is to add a BAT (big-ass text) field to the entity and populate it with a comma-delimited list of GUIDs, then access that field in your Create plugin. You could even clear it out if you don't want that extra data in your system.
Edit after your edit:
General comment about your thinking process: you are probably overthinking it. :) Using a single field, you could pass in any kind of "command" using a json or xml formatted string. As I said above, in the pre-create plugin, after you have extracted this "argument" field, you can clear out that field in the Target entity image and that data will never be persisted to the database. Technically it achieves the exact result you want with the only side effect being one extra "argument" field that is always NULL in the database. Don't fight simplicity so hard! :)
I have a custom list with a text field that set to append changes to the field. This uses versioning. The problem I have is that existing entries have been duplicated in versions. I'd like to go and clean up these programatically, but I don't see a way to pull this. The client object model gives me access to the list item, but there are no methods that I see there to even read past versions, let alone edit them. Or is this something that can only be done server side? Thanks for the help!
I got the answer I was looking for at How to delete versions without having column name in sharepoint list - It looks like it is not possible through the client model, only server side.