I am using Azure DevOps WIT One Click Extension. I am trying to create a Rule to generate multiple Work Items (Child Tasks) when an specific Work Item gets saved or assigned to an individual.
I have tried over and over and the rule does appear for me to manually executed but it is not working to automatically generate the Tasks.
I have no code... I am not a Programmer or Developer. I am a user trying to use the tool
I expect the rule to work and automatically create the Child tasks when the Request Item (Parent) is saved or assigned to someone.
I'm afraid the trigger way you want does not support by this extension now.
generate multiple Work Items (Child Tasks) when an specific Work Item
gets saved or assigned to an individual
For this rule you would like -- save a specific work item and assigned to an individual are belong to trigger way -- as I understand, what you want is when a work item saved and be assigned to someone, it will trigger the action generate multiple child tasks.
So, in this rule, save a work item or assign it to someone is trigger way. The action is generate multiple child tasks. But, unfortunately, these trigger ways does not be support by this extension. It just support New work item load and Field changed now.
That's why it does not working automatically. Because the trigger way you configured not supported.
The rules you can create which also supported by this extension, is open a workitem or change one field will link a child task.
In addition, I also check the rules which Azure Devops support. The trigger way you want are also does not supported.
Related
Is there is a possibility in TFS 2013 where a particular work item like Bug an d Change Request has to be created and closed by Testing team and task by developers.
No, we cannot achieve that as the requirements conflict each other.
You can set the permission Edit work items in this node for a
specific user group on an specific Area. But it applies to all the
work item types.
You can customize work tracking experience for restricting access to
work items:
For example, you can prevent the majority of project contributors
from creating the work items by adding WITs to the Hidden Categories
group. You can create a hyperlink to a template that opens
the work item form and share that link with those team members who
you do want to create them. But you cannot prevent other team members
closing the work items.
You can restrict access to work tracking objects in one of two ways:
By adding WITs to the Hidden Categories group, you can prevent the majority of project contributors from creating them. You can create a hyperlink to a template that opens the work item form and share that link with those team members who you do want to create them.
Set a condition field rule, a condition-based field rule or a combination of the two that applies to a group. You can restrict changes from being made to a field by specifying a qualifying rule and making it apply for a specific group.
Conditional rules can include CANNOTLOSEVALUE, EMPTY,
FROZEN, NOTSAMEAS, READONLY, and REQUIRED elements.
For more information about how to customize WITs, see Modify or add a
custom work item type (WIT).
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.
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.
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.
I am using the TFS 2010 Scrum template and want to modify the Task work item template so that I can display the PBI's backlog priority (read only).
I am familiar with editing the process templates, but not sure I can setup a field to pull data from another work item
There are no rules available to get data from other work items. If you want to do this, you can either use the eventing service (which is a service that is invoked on work item save for example) or you can create a custom work item control.