In our organization, we use azure devops integrated with servicenow. In devops we need to create feature that must be an child of an epic. If no epic is found as parent, we need populate a alert to add a parent to the feature.
Currently, azure devops does not provide a field about the parent related link, so we cannot directly set the process rule for the parent related link.
As a workaround, we can first create a custom field named setEpicAsParent for the feature work item type to populate a alert to add a parent to the feature.
Organization settings -> Process -> choose the inherited process -> choose Feature work item type -> New field:
Then add a custom rule like below:
When a feature item is created, the user needs to select true in the setEpicAsParent field, otherwise the item cannot be saved.
Related
Can I add URL as a field in Azure DevOps work items via manually or through automation and that can be editable?
Expecting a new field type to add a URL to open a URL in a single click
Expecting a new field type to add a URL to open a URL in a single click
I am afraid that there is no built-in field type can meet your requirements.
To meet your requirement, you can use this extension: Clickable Links.
Here are the steps:
Step1: Create a normal string type field in work item(Organization Settings -> Process).
Step2: Click the option: Add custom control and select the normal string type field.
It will generate a new URL type field with the same name.
Result:
I've added some custom fields for Test Plan in Azure DevOps. But when I try to create a new Test Plan through the Rest API call, it is only creating a Test Plan with default fields populated, while custom fields remain blank.
I've tried using both the field name (like Team Name) along with field reference name (like custom.TeamName) but to no avail. Even Get is also not exposing custom fields. Is some extra configuration required for custom fields, or it is a code related issue?
Details: I've created one Inherited process under the organization, and then under Process->Test Plan I've created new fields in the Test Plan, as shown in the screen shot:
I've tried below code to create Test Plan as Work Item and successfully created it with extra fields. But as I couldn't create a test suite independently, it is not behaving properly.
I've created a JsonPatchDocument and added all the fields (adding just one here) like below code:
JsonPatchDocument patchDocument= new JsonPatchDocument();
patchDocument.Add(
{
Operation=Operation.Add,
Path="/fields/System.TeamName",
Value="Xander"
}
);
VssConnection connection=new VssConnection(uri,credential);
WorkItemTrackingHttpClient workItemTrackingHttpClient= connection.GetClient<WorkItemTrackingHTTPClient>();
WorkItem res=workItemTrackingHTTPClient.CreateWorkItemAsync(patchDocument,project,"Test Plan").Result;
It is creating the Test Plan, but not Test Suite. So it is acting weirdly. Kindly check this.
Insert value into Azure DevOps Custom Fields through Rest Api
I could reproduce this issue with the REST API Test Plans - Create.
I think this should be related to the REST API, that because even if I use the REST API Test Plans - Get to get the custom field, but the request body does not include the custom field.
Since we could not get the custom field, we could not use the POST or PATCH for the custom filed.
You could add this request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
Objective
We would like to setup multi-site wagtail with approval chain.
Develop -> QA -> Release -> Production
Description
A develop / content editor goes to the wagtail admin and creates the content. Once done, sends the request for approval to move to QA site.
QA moderator reviews the content on develop site. If approved, the content gets moved to QA site. The content carries over to next stage approval (release).
Same process ahead for next sites in approval chain.
Questions
Is it possible to setup a publish chain with approval policy in wagtail? I tried to research a bit but could only find "workflow" and "workflow tasks". Do I need to custom code a workflow task to be able to achieve this?
This should be possible but you will need to consider what you really want to do in regards to the 'move' step, do you want to actually move the Page instance to a new site in a new tree or copy the current (and its history) and move that copy Page OR make a copy to put in place of the Page that was moved.
Nonetheless, the documentation on how to add a new Task type is the best place to start, it walks you through custom Task types.
In the solution below however, I thought it would be simplest to create a new model that behaves exactly like GroupApprovalTask (the default task included, used for moderation) but add a field that links it to the Site model.
This way, in the admin UI the admin users can now create as many PublishSiteTask as you want, one for each Site (QA/Dev/Prod etc) and then each of those could be linked to different user groups. It is important to differentiate between the database model (a task type with some fields) and the instances (a task created in the UI) and the actual task instances that are created against each page revision (not page) as the workflow steps progress.
Code Example
models.py
from django.db import models, transaction
from wagtail.core.models import GroupApprovalTask, Page, Site
# ... other imports
class PublishSiteTask(GroupApprovalTask):
site = models.OneToOneField(Site, on_delete=models.CASCADE)
admin_form_fields = ['site'] + GroupApprovalTask.admin_form_fields
#transaction.atomic
def on_action(self, task_state, user, action_name, **kwargs):
"""Performs an action on a task state determined by the ``action_name`` string passed"""
if action_name == 'approve':
# get the page that this action is referring to via the task_state.page_revision
page = task_state.page_revision.as_page_object()
# find the new parent target at this task's site
# how this is done depends on the site/page structure
new_parent_target = self.site.root_page
# move the page to a new location
# note: this will actually move it from its current tree, you may want to make a copy first
page.move(new_parent_target)
# be sure to preserve any existing task behaviour
super().on_action(task_state, user, action_name, **kwargs)
Additional Links
Task class definition
GroupApprovalTask class definition
You may want to do some pre-work in the code to check that the page can actually move to the different Site, each Page has a method can_move_to that could help.
The move method referenced above is part of the Wagtail code but the full docs for that method can be found in the Treebeard API docs which Wagtail uses to manage the tree structure.
In Azure Devops, I can add markdown in a pull request's description to automatically change a linked ticket's state once the pr is completed, like this:
NewState: #TicketNumber
for example:
Committed: #1000
Is there a way to also change the assignee? I have tried:
#PersonName: #TicketNumber
but it didn't apply the change.
You can try using the work item rules to do this.
For example, you can create the rule as when the work item state is changed to completed (Closed, Done, Completed, etc.), set the assignee to the specified user.
To view more details, you can see "Add a rule to a work item type".
However, this method will always assign the work item to the same user who is specified in the rule whenever the work item state is changed to completed.
If you want to dynamically set the assignee according to the user you mentioned in the description, this methods is not available. In this situation, you can try to set up a pipeline with the following steps:
Try to get the linked work item ID, and the account information (username and email address) of the user you want to assign the work item to.
Try using the API "Work Items - Update" to changed the assignee.
When we create a pull request and link a work item, after the PR is completed the status of the work items are automatically changed to "invalid". How can we change that behavior to a different status?
In a recent update to Azure DevOps, you can now customize work item state when pull request is merged.
When you create a PR, in the description, you can set the state value
of the linked work items. You must follow the specific syntax.
{state value}: #ID When you merge the PR, the system reads through
the description and updates the work item state accordingly. In the
follow example we set work items #300 and #301 to Resolved, #323 and
#324 to Closed.
The Set work item state in pull request feature is also works for custom states. Here is my sample:
Add a custom state to task.
Create a new pull request and add the Description like:
Ready for QA: #id
Create pull request and complete the merge. Do not check "Complete linked work items after merging" option.
Now, the status of my task has been updated to Ready for QA.
In addition, the product group is still improving this feature. If you have any concern or suggestions, you can share it in this suggestion ticket and this one.