User mapping towards azure devops

 
1
0
-1

(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)

    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      Can you elaborate how you are setting the userfield?

      1. Patrick Hutcherson

        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.

      2. Francis Martens (Exalate)

        Is it now resolved Patrick Hutcherson?

      3. Francis Martens (Exalate)

        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<fabrikamfiber4@hotmail.com>"
  }
]


        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?


      4. Francis Martens (Exalate)

        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 :-/

      5. Patrick Hutcherson

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

        For instance if I had this 

        def assigneePat = "first last <first.last@acme.com>"

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

        Any thoughts on how to avoid that?

      6. Patrick Hutcherson

        also in our case unique name is first last<first.last@acme.com> 

        That is what it is looking for.

      7. Francis Martens (Exalate)


        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 ...


      8. Patrick Hutcherson

        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.

      9. Francis Martens (Exalate)

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

      CommentAdd your comment...