For context, I just read this question Creating Issues on Board in Azure DevOps from API
I have the exact same goal, except the solution didn't address it enough in my opinion because it didn't create the element inside the board.
I am using https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-5.1&tabs=HTTP, It works great, however, I cannot send my item in a specific team board, it always end in "Work Items" menu, did I miss a field or something ?
That depends on your board.... as an example, for Agile you have to create User Story, Feature, or Epic.
Additionally, check your team settings (Define area paths and assign to a team)... if it uses custom settings for Area Path, you have to add Area Path to your request body.
Related
I am comparing Jira against Azure Devops Board and notices few limitation:
1. Components field
JIRA - Components are sub-sections of a project; they are used to group issues within a project into smaller parts. Components add some structures to the projects, breaking it up into features, teams, modules, subprojects and more. Using components you can generate reports, collect statistics, and display it on dashboards and so on.
To add new components, as shown in the above screen you can add name, description, component lead and default assignee.
DEVOPS BOARD - No component field, even if we can customized to add one, it is just a String.
2. No Issue-Type Prefix Ticket ID
JIRA - We can customized to have an issue key, -. For example : REQ-1313
DEVOPS BOARD - Just a number.
3. Workflow Sequencing
JIRA - We can use workflow properties for changing the order of the sequence of transition buttons. So from "Ready" state, we can either go back to "New" / "In Progress" / "Rejected" but not "In Testing"
DEVOPS BOARD - Seems like we can jump to any state we want.
I'm not sure if I'm misconfigure, but if so, please provide a way to do so, or maybe an alternatives to limitations listed above.
Thanks!
1. Component field
Azure DevOps uses the Area Path field for that purpose. About area and iteration paths (aka sprints), Define area paths and assign to a team
2. No Issue-Type Prefix Ticket ID
I can not understand where is a problem here? Can you describe some example?
3. Workflow Sequencing
You can restrict change of the State field with rules: Prevent reopening work item once closed
I am working through creating a custom process in Azure DevOps and was curious if field values from parent can be shared with child items.
Here is an example:
Create field 'Custom Field 9' on Epic work type
Create the same field 'Custom Field 9' on Product Backlog Item work type
Create an epic and fill in the value of 'Custom Field 9'
Create a child Product Backlog Item, 'Custom Field 9' is then inherited to the backlog items field.
What I've tried so far is to use a rule on either Epic or Product Backlog Item, however, I do not believe the rules can apply to creation of children processes.
One other option I'm going to try later today is a Flow that detects when a child work item is created and perform it automatically. I'd like to try to keep this contained to Azure DevOps if possible.
Edit: Thought it helpful to mention that we are using the hosted solution of DevOps and nothing on premise.
Sorry to say that as default, there does not such a work item features with "out of the box". But you can use another tool to achieve this.
Like you said, Microsoft Flow, there does not such feature supported while connect with Azure Devops.
But, in addiiton, I think you can do this with writing some custom scripts. And then configure Web hook to trigger this custom events.
Also, here has another tool named TFS Aggregator (Web Service) to achieve what you want. You can set and configure apply certain rules (such as copying fields from a parent item to a child item). And it will trigger after a work item is created or saved.
I know this is very inconvenient, here has an same feature suggest which raised by others. They has the same demand with you. You can vote and comment for this suggestion. When there are enough communities vote and add comments for this feedback, the product team member will take this feedback seriously.
I needed this feature as well, but in it's absence I have got it to work (relatively easily) with an Azure Logic App (for anyone also using Azure)
Trigger
When a work item is created
Then
Get work item details using "Parent" as the work item ID to search for
Finally
Update the new work item with any field from the parent you require
We have created a few extensions for Azure DevOps (0) that are pipeline extensions.
We are trying to create new extensions that can react to changes in work items of Azure Boards. The API's for interacting with changes in work items are fairly straight-forward, but we are struggling with configuration of the extension.
Essentially we need to allow the users to configure the extension on two levels
1) On "Organization level"
It should be possible for a user (Project Administrator) to configure parameters as "external system URL" etc. An example of this could be something like below mockup:
2) On "Project level"
For each project in Azure DevOps an admin should be able to configure parameters like "Enable/disable extension" or "External UID" etc. An example of this could be something like below mockup:
When the extension reacts to "Work item saved" it will query the parameters on both levels to figure out what to do.
My problem is: where the heck do I save this information? I could add a number of "custom fields" to the template in use, but since fields can only be added to work item types, it is really not ideal in any way.
Where can I save this information through the API's?
PS: Source code for our extensions are available as OSS (Apache license) here:
(0) https://bitbucket.org/projectum/
Thank you :-)
It turns out that Azure DevOps has a way to store data for extensions. It can store data on both Project Collection scope as well as User scope.
I think I will be able to use this to store the data I need. All I need now is to figure out where to put the UI that the user or admin will use to maintain this data.
https://learn.microsoft.com/en-us/azure/devops/extend/develop/data-storage?view=vsts
:-)
For #1, it somewhat looks like what you can configure under a pipeline's service connections. This is per project though and not at an organization level.
This might be easier to manage outside of an extension and instead just use a service hook to call some middle tier that accomplishes what you want.
Or developers need the Work Item forms as designed for our agile process, but we'd like our regular users to be able to add new bugs and user stories using a simplified form, where a lot of fields are removed and some have team specific default values.
How can this be done?
The closest match I've found so far is templates, where field defaults can be defined, but the form that's used/displayed is still the large cluttered one. Being able to use the template link to land directly on a pre-filled form is a step in the right direction, though.
Azure DevOps allows you to modify your process template and add new work items to your project. You can find the documentation to do this here.
Go to Organization settings for your account --> Process --> Create an inherited process from your process template --> New Work Item Type.
You can then define the fields you want and the layout of the template.
Something else that could be useful in your scenario is the Test and Feedback Extension. This is a simple browser plugin that lets users explore feedback requests and file comments and bugs.
I work in IBM RTC (Rational Team Concert); the Project Area I own is built on the IBM Formal Project Management Process Template.
I’m looking for a mean to get work items created programmatically;
I do want when I create a Change Request work item, to allow the selection of different teams and from this attribute(s), create automatically children work items Task directly assigned to the right team/member.
How would you recommend to do so?
Although it is not a direct answer to your issue, but I guess it would help. It's more like a workaround more than a solution to your requirement.
The work around is divided into two steps:
Create a work item template from a CR with all its sub tasks included in the work item template.
Create a CR using the previously created template programmatically.
Note: This means that you'll need to create a work item template for each team.