User mapping towards azure devops

General Questions
, ,
1

Originally asked by Francis Martens (Exalate) on 27 March 2021 (original question)

(From a user)

There is an issue with getting users synced from Service Now to Azure DevOps.

I initially had issue with nodeHelper.getUserByEmail however, I figured out that the email address is case sensitive. Once that was resolved.

I am not hitting the following error:
Bad response when Updating work item - 400 - response body: The value ‘Patrick Hutcherson’ for field ‘Assigned To’ is ambiguous with ‘John Doe ;John Doe <john.doe@acme.com>’. Provide a unique name for this field.

It is correct that there are two users with the same name however, they are different emails, ID’s etc. Is there a way around this so that the users can be added.

Not really sure this is a configuration things as I am getting the info just how the tool is syncing it to user is not working (I think)

2

Answer by Francis Martens (Exalate) on 27 March 2021

Can you elaborate how you are setting the userfield?

Comments:

Patrick Hutcherson commented on 29 March 2021

workItem.assignee = nodeHelper.getUserByEmail(replica.assigneeMail)
if(!workItem.assignee)
{
//try in lowercase
workItem.assignee = nodeHelper.getUserByEmail(replica.assigneeMail.toLowerCase())

}

All of the values for the assignee are being updated correctly ( Key, active, email, displyName, username). Because in our AD there are two accounts for the user with different keys and emails I would have expected there to not be a conflict.

In azure we just assign the users by searching AAD using the identity field.

Francis Martens (Exalate) commented on 31 March 2021

Is it now resolved Patrick Hutcherson?

Francis Martens (Exalate) commented on 31 March 2021

Thanks for your time today.
The solution is contained in
https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/update?view=azure-devops-rest-6.0#update-an-identity-field-by-display-name

What needs to be sent is

[
  {
    "op": "test",
    "path": "/rev",
    "value": 6
  },
  {
    "op": "add",
    "path": "/fields/System.AssignedTo",
    "value": "Jamal Hartnett"
  }
]

Exalate is currently sending

[
  {
    "op": "test",
    "path": "/rev",
    "value": 6
  },
  {
    "op": "add",
    "path": "/fields/System.AssignedTo",
    "value": "Jamal Hartnett"
  }
]

We’ll be fixing the problem.
In the mean time, can you change the name of the admin user?

Francis Martens (Exalate) commented on 31 March 2021

Apparently I’m wrong. Exalate is sending

{"op":"add","path":"/fields/System.AssignedTo","value":{"id":"xxxx","displayName":"John Doe","uniqueName":"John.doe@acme.com"}}

We need to understand why ADO is not applying it that way :-/

Patrick Hutcherson commented on 31 March 2021

So I am having trouble getting it to accept the <> portion of the script.

For instance if I had this

def assigneePat = "first last "

When I debug I only see first last and it skips the rest of the string.

Any thoughts on how to avoid that?

Patrick Hutcherson commented on 31 March 2021

also in our case unique name is first lastacme.com>

That is what it is looking for.

Francis Martens (Exalate) commented on 31 March 2021

The reason why there is an issue, is because applying the change on the workitem fails because the name is not uniquely identified.

I’m not sure about what you want to achieve here with the parsing of the name …

Patrick Hutcherson commented on 01 April 2021

I am not able to test this on our end as the name change did not transition through. I do not have another user to test with right now however, I did try the api and found the issue but when using the distinct display name there was no issue.

Francis Martens (Exalate) commented on 02 April 2021

Well - it is something we have to fix.
Did you try the behaviour with a user that has a unique displayname?