I'm using TFS 2013. In one field we have a Bug ID. It's a unique number and people often refer to it when working on projects (e.g., "Did you take care of bug 3456 yet?"). I know we get a Work Item ID with TFS (and that it is a unique number within a Team Project Collection), is there a way I can create a custom field that takes the first initial for the work item type and then attaches an the unique ID to it after? For example, for a bug it could be "B-3456" or for a task it could be "T-4242"? I'm just looking for a better way to way to organize ID numbers...
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 want to change the work item ID from format "3456" to "B-3456". It's not able to do this, this ID is stored in TFS database and have various purposes such as work item query, TFS API and so on.
There is no easy Work Item Customization snippet you can apply to a new customize field to have it set to auto increment on save for a specific work item type. If you really want to do this, one way is follow Jesse Houwing's solution in this similar question.
And either in VS or in the web portal, it's easy to judge which work item type you are refer to. They have different icons or colors.
Related
I am new to TFS and know the basic concepts. In my case we have customized TFS a lot which contains around 17 collections, custom fields in work items etc.
I have some queries for which I require some answers. The questions might be generic, but any help or suggestions on the below queries would be great.
Following are my queries:
1.) Show Work Item ID in a specific format. Can it be done
2.) Auto Fill custom fields for a work item based on a category / linked bugs (analogous to Relative Path column type)
3.) While raising a WI through Visual Studio development tool, the datepicker only takes date value and not time. The same work items when raised through web portal the datepicker gives time value as well.
4.) Auto Fill the efforts spent in Child Work items (summation of all child link items in the parent)
5.) Reminders to be sent if iteration / scrum set date crossed. Also check for Work Items as well, if set date is crossed.
6.) Create Queries which can query across all collections / verticals. Currently queries can be made only against each entire collection, but not across all collections. Do we have any mechanism to query against multiple collections?
7.) Email alerts customizations in TFS.
8.) Can the collections be merged into 1 default collection.
I have tried to find few answers from my end as well, and would like to know, if it is correct.
1.) Work Item ID cannot be shown in a specific format as it is system generated
2.) For Auto Filling of Work Item fields, it cannot be done. Manual approach is the only way (unless there is a way to pre-populate fields
3.) One can only query for all projects in a single collection. But it is not possible to query against multiple collections and get the results.
So require assistance on the above queries and also validate the answers I have got for few of my questions.
Any help or suggestions or relevant links would be great.
Thanks In Advance!!!..
Please kindly check below inputs
You are right. This is by designed. You can not change to use other
format of work item.
Yes. This could not be done at present. It's still a user voice, but
on the Roadmap. Support for calculated fields and roll-ups.
Sorry, not get your point.You could use the DateTimeControl type to give users a calendar picker to select a date for a DateTime field. By using this control, you can quickly select a date and time for the field. For details.
You could do this from a sprint backlog or task board. Details
please take a look at our official tutorial here: Rollup of work
and other fields
We do not have this kind of build-in time reminder for work items.
However, as a workaround, There is a dashboard widget that uses #me
in its query.
You can also cobble something together using the REST API and a
scheduled build. Calling a work item query and sending email is
pretty easy from PowerShell.
No, they are using different database. You are only able to query
across team projects int the same project collection.
It's able to do this but with a little bit complicated. For detail
info, please take a look at this link: Customize TFS 2015 alert
email
There is no default way to do this. I do not think there is a
possibility of merging two TFS collections other than creating a new
collection, creating the team projects and use a tool such as TFS
integration tools to move the team projects from the source
collections.
As you can see, history will be rewritten with new dates, changeset
and work items ids etc, if you are trying to merge collections.
Sorry the poor English.
I'm using Visual Studio Team Services for a first time, and I follow the guided tour where I created three work items as example. Basic conceptions learned, I then deleted these first example work items and started to Create my own work items. Their numbering was sequential to the three first ones.
I managed to delete my Project to start a new one. I was think a new Project will start its work items from number 1 onwards, but the numbering from the deleted one is being used. I tried creating the repository with another Project name but no success.
I wasn't able to find how this is occurring, and it's very annoying to me. Someone has any idea about what's going on and how to correct this behavior (unless this is a feature)? Thanks in advance.
In TFS you have a Collection Database, that has a WorkItem table, all Work Item Id's are sequential in that table. A Collection contain one or more Team Projects. To reset the numbers you would have to create a new Collection.
In VSTS Collections are not a concept that you can manage, you have an account instead, you would probably have to delete and re-create your account - I don't think there is any way to create a new Collection in your account - I may be wrong, I'm only a personal user of VSTS.
I wouldn't worry too much about what ID's each work item has. I don't think it matters that much, you will soon lose control of them. Every WI you create has a new incremental ID, you you get Bug #1, Test Case #2, PBI #3, and so on. If you have >1 Team Project you will also end up with that taking ID's from you.
I am trying to import some existing requirements into TFS 2013 (currently just maintained in a Word doc). However, I need to preserve the existing, pre-assigned requirement IDs (for tracking against existing test cases outside of TFS, etc.). I've come up with multiple ways of doing it:
Keep it as part of the requirement title
Add it to the description for the requirement
Add a tag with the legacy req id to the appropriate req in TFS
Add a new field for it to the requirement template (or simply use an existing unused field)
All of these seem pretty unclean to me except the "new field" option, but I'd rather avoid changing the work item template if I could.
Are there are other/better ways to do this? Has anybody done something similar before?
I usually add a field to most of my work items called External ID that I use for this purpose. It's also useful to link TFS Work Items to say a ticket ID in a Help Desk ticketing system.
We're about to implement TFS 2012 and I've been having some fun customizing some work items to aid us in our reporting. One issue we have is our reporting based on clients.
Our Product Backlog Items keep our requirements, however, we need to report our requirements per client (government regulations). Some requirements will affect all clients, some will only reflect certain ones. I've been able to add a global list of clients along with a multi-select option and that part is working great.
The issue is we need to also note the requirement number for each selected client. I know I can go in and add a field for each 'Client Requirement', but as that list gets bigger, that screen will be insanely huge.
Does anybody know of such a way to implement something of the sort?
One option would be to create a custom Work Item Type for Clients. Then link your PBI's to the appropriate client WI's. When you create a link you can enter a link comment also which you could use to capture the client-specific requirement number.
I would create a custom "Client Requirement" work item that has the list of clients to select and includes a field for Client ID. You can then either use the related link type or create your own, maybe "Implements \ Implemented By" so that you can create a Reporting Services report that pulls the ID's
I would like to customize a Work Item Type in TFS to automatically set the Assignee to a particular role. For example (to compare to another Issue Tracker), in JIRA the default Assignee is the Project Lead (so that any ticket not otherwise assigned, gets automatically assigned to whatever person is designated in the role of Project Lead). Can I do something similar in TFS?
So, I realize that one difference between JIRA and TFS is that TFS doesn't (to my knowledge) have the concept of "Roles". The closest thing to that is "Groups", but unlike Roles, Groups can have multiple people (which may be the restricting factor in this problem). I know how to configure a TFS Work Item so that only a certain Group gets listed in the "Assign To" field, but I would like to go a step farther, if possible, and create a custom Group with just one member (e.g., "Issue Guru") and then set up the work item to get automatically assigned to that person.
I'm trying to replicate the Jira functionality here, and maybe there is just no good way to do it in the TFS framework. Any suggestions?
There's a Step by Step Guide on Ivan Fioravanti's Blog for enabling it.
If you are unfamiliar with customising Work Item Types, have a look at the following links (stolen from Grant Holliday's blog).
I never tried this in production but here is something I tried quickly and it seems like it could work.
You can set the default value to a Group by editing work item template in template editor.
Just select Assigned to field and add a DEFAULT rule like shown in the image below.
This will also require you to create one or more groups (one global or maybe one per project). Once you set this up you won’t have to make any updates in the future but only manage people who are in the groups.