JIRA-Server to ADO; Repro Steps does not sync

[xl8bot]

Originally asked by Robert Kirsten on 23 November 2020 (original question)

---

Hi all,

we have successfully created a connection between JIRA Server and ADO. Everything went well so far.

However we discovered an issue that the Repro Steps in ADO will be only snyced from the JIRA, if the comment field has a value. If the comment has no value, no Repro Steps will be synced.

Here is the incoming sync code:

workItem.summary = replica.summary
workItem.customKeys.“Repro Steps” = replica.description
workItem.description = replica.description
workItem.priority = replica.priority
workItem.labels = replica.labels
workItem.attachments = attachmentHelper.mergeAttachments(workItem, replica)
workItem.comments = commentHelper.mergeComments(workItem, replica)

Has anyone an idea why this happens that way?

Thank you very much in advance.

Have a great day

Robert

---

[xl8bot]

Answer by Francis Martens (Exalate) on 24 November 2020

The incoming sync will only be processed if there is an incoming message.
A message will be sent only if there is a change on the jira.
Can you check if a message is processed whenever changing/adding something else than a comment.

---

Comments:

Robert Kirsten commented on 24 November 2020

Yes, there is a incoming message. All fields are synchronised, except Repro Steps.

Repro steps will only be synced if we drop at least one character at the comments field

Francis Martens (Exalate) commented on 24 November 2020

Hi Robert Kirsten

The case is puzzling (especially dropping at least one character at the comment field)
Can you provide in more detail a step by step approach?

Robert Kirsten commented on 24 November 2020

Hi there, sure thing:

1. First step, we create a bug on the JIRA side:
2. This is the state how the bug is sync to ADO. As you can see, there is no value in the field “Repro Steps”
3. 
4. By changing the title or the adding a comment on the JIRA side, the fields will be synced (by no obviously reason). No special rules added in the incoming sync section
5. 
6. 

Are these informations helpful? We can provide further informations. For now, we have no clue where to check further settings. Also checked the error logs, there is no error so far shown.

Francis Martens (Exalate) commented on 24 November 2020

Can you provide the full incoming sync processor?

Robert Kirsten commented on 25 November 2020

Hi Francis Martens (Exalate)

yes, here you are:

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.customKeys.“Repro Steps” = replica.description
workItem.description = replica.description
workItem.priority = replica.priority
workItem.labels = replica.labels
workItem.attachments = attachmentHelper.mergeAttachments(workItem, replica)
workItem.comments = commentHelper.mergeComments(workItem, replica)
workItem.areaPath = “LALA\\BLABLA”
workItem.iterationPath = “LALA”

Francis Martens (Exalate) commented on 27 November 2020

Following works

workItem."Microsoft.VSTS.TCM.ReproSteps" = "Hello there"

What I did.

• Added the existing field ‘Repro Steps’ to the configuration of an issue
• Accessed the documentation page Azure DevOps: fields and entities available for synchronization
• Found about the link to check on the field names
  https:``//[dev.azure.com/francisidalko/BugsRus/_apis/wit/fields?$expand=ExtensionFields&api-version=6.0](http://dev.azure.com/francisidalko/BugsRus/_apis/wit/fields?$expand=ExtensionFields&api-version=6.0)
• Found about repro steps
  
• Added the line of code to the incoming sync

Would this work for you?

Robert Kirsten commented on 02 December 2020

Hi Francis Martens (Exalate)

thank you very much. That works for us as well.

Have a great day

Best regards

Robert

Francis Martens (Exalate) commented on 04 December 2020

Great - can you mark this question answered - thanks.