We configured the connection and now it works. We have a problem though. When we copy a comment from Jira to DevOps, Exalate sets the author of the comment to a proxy user on the DevOps side. We would like to change this behavior. We have found a code snippet but it has a hard-coded email address and we would like to have this work dynamically. Can you help us with how we should modify this snippet to work so it would use the actual user who made a comment?
Comments:
Syed Majid Hassan commented on 30 March 2022
Sure Darek
Can you please share the code snippet you are using please?
Also, are all users replicated between Jira and DevOps? Do they have the same usernames/ email addresses?
Can you help me to get value from single group picker Jira custom field?
When I used issue.customFields.âSupport Groupâ?.value?.valuelike for select list the result is ânullâ
Comments:
Syed Majid Hassan commented on 21 March 2022
Hi Darek,
I would need more information than that to be able to resolve this issue.
However, on the face of it here are my observations:
issue.customFields.âSupport Groupâ?.value?.value looks ok, but depends on where you are using it.
If it is giving null, the value selected is probably null.
Assuming that you are trying to send this field from Jira to Azure Devops (ADO), the recommendations would be the following:
Outgoing on Jira: replica**.customFields.âSupport Groupâ =** issue.customFields.âSupport Groupâ
Incoming on ADO: debug.error(replica.customFields.âSupport Groupâ?.value.value)
Once the above scripts have been added, please trigger a change from Jira ticket and monitor the errors screen in ADO Exalate panel. You should receive the value of the Jira field in the errors screen.
Once you do step 4 successfully, then you can assign the received data to any ADO field of your liking.
Thank you for taking the time on our call earlier today. I have finalized the testing and come up with the cleanest way to do this. Here are my final scripts:
This is in line with my approach of sending the Support Group over, but you could change that to send the static value of parent ticket on ADO side as well (like you were doing originally):
replica.customKeys.âXâ = â125718â
Incoming on 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â; if (replica.customKeys.âSupport Groupâ == âHRâ) { workItem.parentId = âhttps://dev.azure.com/exalatedemo/Some%20Project/_workitems/edit/{parent workItem of HR group}â workItem.comments = commentHelper.addComment(âAdded this to parentâ, false, workItem.comments) } else if (replica.customKeys.âSupport Groupâ == âITâ) { workItem.parentId = âhttps://dev.azure.com/exalatedemo/Some%20Project/_workitems/edit/{parent workItem for IT group}â workItem.comments = commentHelper.addComment(âAdded this to parentâ, false, workItem.comments)
In the above approach, I pick the value of Support Group and then assign this newly created ticket to be a child of the workItem (based on your mappings). We conclude by adding a small comment to the ticket as well.
Here is a short video showing this approach in action: