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.
Related
We use TFS2013 on premise. A request came up that when using Web Access, some members with Stakeholder access should only have limited rights when opening work items.
They should be able to edit Description, Acceptance Criteria, etc fields, but others should be read-only, such as Iteration, State, etc.
The only option I saw was about tags Create tag definition option under
Security >> Permissions, but that's not enough for me.
One idea was Customizing a process template, but this seems to be thin ice as our team doesn't have any experience with it and the things to avoid list is quite long.
The best workaround approach so far is to reference the TFS ClientLibrary from Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\ and create a custom website which implements only the required features (for example when opening a work item, State would be a Label instead of a DropDownList).
The drawback of this solution is that it would keep the whole WebAccess portal hidden, including its nice features.
So my question in short: is there a way to make certain fields read-only on the work item form for stakeholder members?
UPDATE
Eventually I went towards Template Customization using TFS Power Tools 2013. Now I have to following problem:
Applying rules for certain fields work just fine, but in case the field type is TreePath, saving the template gives the following error
TF26062: Rule '< READONLY for="[Global]\Stakeholders" />' is not
supported for the field 'System.AreaPath'.
There were validation errors. Continuing to save may cause the file to
become unloadable, do you want to continue?
According to this answer from 2009: "there are some particular fields which can't be applied rules for"
Any suggestions how to go on?
You can choose the work item types to make some fields read only.
You will never need to be careful to not mark field read only that are needed for adding items. That would include area and iteration. Use witadmin.exe to export the desired work item and add read only clauses only for those in the stakeholder group.
You would be better with a permissive model. Allow everything and tell them what bout to change. Then have an alert for changes to those fields by stakeholders.
I'm customizing the Work Item Definition Schema for the 'task' work item in TFS Server 2012. I've created a new field for hold a CustomerReference value. It works as I expected, but I would like add a UNIQUE restriction for security. I'd like add a rule than it makes imposible create two workItems with sme CustomerReference.
I think that none of the rules defined here http://msdn.microsoft.com/en-us/library/cc339553(v=vs.90).aspx achieve my target.
Any idea? Thanks in advance,
As a last resort there is a way to write a custom plug-in that can enforce this server-side. See this link for more info on creating an ISubscriber plug-in: http://nakedalm.com/team-foundation-server-2010-event-handling-with-subscribers/
Unfortunately, the plug-in model doesn't allow you to prevent changes; but it could allow you to detect when somebody has violated the rule and react. For example, it could send an email off to somebody, and possibly clear out the CustomerReference field from the duplicate.
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.
Hallo experts,
i'm newbie to TFS, but responsible for SW Test in my group. I'm trying to create a couple of test cases thru MS Visual Studio. I don't know how to change the Test Case IDs, which seem to be automatically assigned by the system. However we want to adapt the IDs to the conventions in our SW specifications. Thanks in advance.
JohnMunich
If what you're looking for is a custom Test Case ID, you'll probably want to modify your work item template for the test cases with a new, custom field.
You can do this by exporting the appropriate work item type using the TFS Power Tools, adding the field and re-importing.
If you want the field to show up in the warehouse, be sure to make it reportable.
Note: The direct link is for the TFS 2010 power tools. This page also contains a link to the TFS 2008 Power Tools.
I don't believe there's any way to do this within TFS itself. These numbers are assigned and internally they are used as primary keys for the data.
You potentially could change the number that will be assigned. I think this might be of help.
The problem is that this will change the next User Story ID that you generate, too.