Setting custom fields on Azure Devops

General Questions
, ,
1

Originally asked by Jose Lobo on 03 November 2020 (original question)

SI am wondering if you have any Sync Rule resources that you can point me towards to help navigate this configuration issue in the Sync Rules.

We have a customized Bug form in Azure DevOps that has two required fields (“Product Version" and “Found In Version”). In Azure DevOps the acceptable entries for these fields are controlled by GlobalLists. So they may not be recognized as text strings as I initially thought that they would.

The Jira side is not reporting any errors or problems. The Jira work item (Bug type) has a Sync Status of “Waiting for Remote”.

Below is a sample error message on the ADO side of the connection:

Error Detail Message:

Bad response when creating work item - 400 - response body: TF401320: Rule Error for field Product Version. Error code: Required, HasValues, LimitedToValues, InvalidEmpty. One additional error occurred during validation of the work item. Please correct all errors and try again.

Work item sync flow is from Jira to ADO.

Here are the Incoming Sync rules on the ADO side:

if(firstSync){
   // Set type name from source entity, if not found set a default
   workItem.typeName = nodeHelper.getIssueType(replica.type?.name)?.name ?: "Task";
}

workItem.summary      = replica.summary
workItem.description  = replica.description
workItem.priority     = replica.priority
workItem.labels       = replica.labels
workItem.attachments  = attachmentHelper.mergeAttachments(workItem, replica)
workItem.comments     = commentHelper.mergeComments(workItem, replica)


//Set Custom Fields for Bugs, this is not working
workItem.customFields."Product Version" ="Nexus"
workItem.customFields."Found In Version" = "7.4.1.0"
2

Answer by Mike Bonfiglio on 05 November 2020

Resolution required reviewing the JSON fields for the impacted work Item type (the Bug Type in this case) to determine the correct field name that ADO was using.

To view the JSON details for an ADO Work Item, edit a work item in a web browser.

Copy and paste the URL to a text editor.

Replacing /_workitems/edit/ in the URL path with /_apis/wit/workItems/

Sample edit work item URL:

https://dev.azure.com/ name>/<project name>/_workitems/edit/<work item number>

JSON details URL

https://dev.azure.com/\<organization name>/<project name>/_apis/wit/workItems/<work item number>

Locate the customized fields in the JSON page, and update the incoming Sync Rule with the correct custom field name.

workitem.“CustomFieldName” = “text string”

if(firstSync){
// Set type name from source entity, if not found set a default
workItem.typeName = nodeHelper.getIssueType(replica.type?.name)?.name ?: "Task";
}
workItem.summary = replica.summary
workItem.description = replica.description
workItem.priority = replica.priority
workItem.labels = replica.labels
workItem.attachments = attachmentHelper.mergeAttachments(workItem, replica)
workItem.comments = commentHelper.mergeComments(workItem, replica)

//Set Custom Fields for Bugs 
workItem."ExampleCompany.ProductVersion" = "Nexus"
workItem."ExampleCompany.FoundIn" = "7.4.1.0"
3

Answer by Howard Kenny on 20 November 2020

I’m having a similar challenge (source is a Jira ticket). The Azure field in the JSON is…

"Custom.OrderNumber": "1234"

…but when my receiving rules have any of the below (tested separately!), none seem to work:

 workItem.customFields."Custom.OrderNumber" = replica.customFields."Order Number".value

 workItem."Custom.OrderNumber" = replica.customFields."Order Number".value

 workItem.customKeys."Custom.OrderNumber" = replica.customFields."Order Number".value

Comments:

Juan Grases commented on 20 November 2020

I would expect

 workItem."Custom.OrderNumber" = replica.customFields."Order Number".value

to work. Are you sure you are getting a value from replica.customFields."Order Number" ? You can use the “Entity sync status” menu to check the remote replica (incoming replica) for the work item you are syncing.

Howard Kenny commented on 21 November 2020

And you would be right! I’d put it in the ‘create’ section, but not the ‘change’ section (which is how I was testing it) - my mistake.

Cheers Juan.

4

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.