We are trying to impose couple of rules on our project , can you tell us if it is possible to do? and if yes where should I start on this?
One of the example rule is
Deliverable can’t be closed with non-closed children.
This means that even in resolved state a child item would block closing the deliverable.
This should apply to parent child link types only
This would only apply to deliverable parent and any type of valid child
There are two ways you can do this.
Server-side:
You can add a plugin to tfs, that changes workitems. A good example would be TFSAggregator. It won't have the solution for your specific problem, but I can show you how to change work items on the server side. Shouldn't be a big problem to add your case.
The problem with this solution is, that it only changes a workitem after it has been saved. So user will still be able to close the child, but the server will re-open it.
Client-side:
The second solution would be a custom control, which can be implemented in the WITD of your work item. It can be just an invisible control, that adds some validation. You can find some examples here.
The downside of this solution? You have to install the custom control on every single client that uses Visual Studio and you may have to develop a specific version for web-access.
Related
I use VSTS/TFS for work and side projects and I wanted to setup a trigger/rule that would automatically move stories into a certain iteration when I move them from "New" to "Approved" or whatever column is associated with an active state. I know how to change the iteration manually but it would be way easier if there was a way to say something like this psuedocode:
if (workItem.State == "Active") {MoveToIterationActiveForTodaysDate();}
Ideally too, if this isn't too picky, I would like it to only run on initial move so I can reassign to a different iteration later if I wanted to.
If anyone has an easier way to do this too that accomplishes the same thing (moving items to an iteration without having to manually activate the story and move it to the desired iteration) that would work as well. I'm still figuring out the ideal way to manage VSTS/TFS. Thanks in advance
Using VSTS is able to customizable work item rules.
Whether it be automatically setting the value of certain work item
fields or defining the behavior of those fields in specific states,
project admins can now use rules to automate the behavior of work item
fields and ease the burden on their teams.
More details please refer this tutorial: Add a rule to a work item type
However, it works with fields in the work item, not able to move work item to different iteration or area directly.
There is no out of box feature could achieve your requirement with TFS and VSTS for now. You may have to customize TFS events/actions to achieve the same feature as right click the work item--select move iteration--choose iteration.
Moreover, you could also use some 3-rd party extensions/tools such as Giulio
suggested TFS Aggregator.
As of today, there is no built-in automation, so the community wrote some tools that react at TFS/VSTS events and run scripts.
I can suggest TFS Aggregator which is used by many organization throughout the world: I am one of the core contributor.
Is it possible to programmatically move a WIT (PBI, Bug, etc.) from one Collection/Project to another?
I have a use case where a bug may be inadvertently opened under the wrong team project, and needs to be "moved" intact (history, attachments, etc.).
I've seen hacks that involve manipulating the underlying SQL tables, but I'd like a cleaner API-based solution.
You cannot move a work item from project to another or one collection to another. But you can copy it to another project in the same collection using the copy option in Web Access (manually). This actually just creates a new work item and copies all the matching field values to the new item.
If you want to do this in code or if you need to do this from one collection to the another collection you will have to create a new work item and copy all the fields you need over to the new instance. If you need the actual move experience you can destroy the old work item after the save of the new item is completed.
Note that you will always get a new ID both since ID's have to be unique within a team project collection. If moving items around is an ongoing concern for you consider moving all related teams into a single team project and use Team's to keep them aparte where necessary. You can move work items from one team to another within the same team project.
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 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.
Does TFS 2010 have the concept of checking out work items and checking them in. This action would lock the item for edit by other users while it is checked out.
I know I can do this for files under source control, but what about regular work items?
I haven't yet come across any documentation around this. If it's possible, does someone have a code sample?
That is not possible. In TFS11 we have added 'merge on save' so there are less conflicts when saving a work item.
Would love to know why you want this feature though.
You could achieve a lock mechanism on work items if you write a custom control that allows or denies saving based on the result of some query you make to a custom service.
You would want to create a visual studio plugin that sets and resets the lock per work item.
While you're at it, you could write a server plugin that persists a serialized copy if the work item to disk or to the version control system.
I know it's a lot if work, but it should give you what you asked for.