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.
Related
I'm working on enhancing metadata in our SharePoint online (O365) environment. Since a portion of my user base is used to foldering (explorer style), I've started using default column values to automatically set values on any files added to that specific folder (we have content organized categorically by folder currently). An example is our HR documents library - we have separate folders for recruiting, payroll, personnel files, etc. that automatically categorize files added to that folder with the same categories (recruiting, payroll, personnel, etc.). This supports both "search" and "click" users and makes adoption WAY easier while getting important metadata.
I want to implement this in a larger, more dynamic fashion, so manually setting default column values on each folder is not going to be scalable.
How can I reference the top level folder within the library (or even the current folder) for each newly added file and populate the "category" field for that new file with that folder name? I can do some very basic C# or Java code copy/paste, but bonus points for non-coding solutions =)
This problem can be solved through no coding.You can use the workflow to implement this by SharePoint Designer.
Create different view for different function team, and then use the view filter to show the document.
If you upload a file, use the workflow to set the metadata of the file. There are some known limitations: if you upload multiple files at the same time, the metadata for the file maybe does not work well; or if you upload a folder, the meta will not work for it and the file in the folder may not be set to right metadata.
I was actually able to use MS Flow to accomplish this in a pretty simple and straightforward fashion without managing custom views per team. The concept at a high level was:
(Trigger) When a new document is created in a folder in the library
Get the link of the parent folder of the newly added document
Create a variable (or just code it out in the Flow step) to parse out the name of the parent folder from the parent folder link (should be all text to the right of the last "/")
Set the category field as the variable
I'm sure that you could do the same right in a SharePoint designer workflow, but I prefer flow due to the visual aspect of it and being far easier to troubleshoot.
I need to add a logic hook to a module built in Module Builder in SugarCRM 6.5( Community Edition ).
This logic hook should take all the fields that I have just saved after completing a form in a module and create a new record in a different module with these fields( in order to simulate a workflow ).
All the tutorials on the internet( on logic hooks ) talk about modifying stuff in "./custom/Extension/modules//..." but, after creating and deploying a module in sugarCRM, I do NOT have my module present in either "./custom/Extension/modules/" or "./custom/modules" .
Thank you for your time,
Those directories are for customizations and extensions like studio changes and custom code like hooks.
That those directories are not present only means that there are no customizations yet, so feel free to create those folders and add your hook inside.
Make sure that you create the directories with the correct names (as stated in the tutorials), including the correct case for all letters.
Also don't forget to give the web-process ownership/write-permissions to the all folders you create in custom, otherwise Sugar might fail to save studio changes and aggregation files at some point in the future.
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 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:
I'm just starting into some Eclipse (juno) plugin experimentation. A key part of the plugin I want to create needs to provide the user with the ability to create New java-based classes. These classes may be 1 of 3 different types.
Is it possible to do this using variation of the NewFileWizard that will use a template for each class type under the hood?
For example, when the user is in the new Custom project they created from the plugin, I'd like them to be able to do a right-click, "New" and be given 3 choices. Depending on the choice, the wizard will use a corrosponding code template - filling in class name, package name, etc., and then generating the file in the proper project folder.
Please let me know if you need any clarification on what I'm asking.
Is it possible to do this using variation of the NewFileWizard that will use a template for each class type under the hood?
Yes.
You're basically going to have to get the Eclipse source code for the New File Wizard, bring it into an Eclipse plug-in project, and modify it to meet your specific needs.