Users name changes each day after import

[Emily Patrick]

I have a user who's name keeps getting overridden in Hornbill each night after the import is done.  

The name is Glück and Hornbill will resolve it to Gluck, which is incorrect.  I am able to manually change it to Glueck which they are happy with, but each day it changes back to Gluck.  

Is there a way that Hornbill can show the name as Glück or, if a change is made, it can remain? Below is a screen shot of how it is now, after I've made the change again to the spelling of the name: 

 

This is how it shows in a job that they have raised too: 

 

Any ideas please?

[James Ainsworth]

Hi Emily,

Thanks for your post.  There are a few different import tools that are available for adding and updating users.  Could you let me know which one you are using?

[Emily Patrick]

Hi @James Ainsworth, 

We use scripting server meteor, and have a job in at the moment to get it updated to the newer version before the end of this month. 

 

Not sure if that helps at all!

[James Ainsworth]

Hi Emily,

Sorry, I was interested in the Hornbill tool that you use to do the import.  Or have you built something in Meteor using Hornbill APIs to update the users in Hornbill?

[Emily Patrick]

I think using an API to update the users.  I wasn't involved with that part of our setup I'm afraid, so not fully sure. 

[Emily Patrick]

Hi @James Ainsworth, 

Do you or anyone else have any idea on what can be done for our user? She's still complaining about the spelling of her name, and manually changing it each working day isn't a viable solution for us.  

We have no issues with our other systems with her name, just Hornbill now.  

Is there a way that our import method, that's run each morning, can understand the ü markup and bring it into the handle for her name, automatically? 

[Steve Giller]

@Emily Patrick If you're using one of our Import tools then we may be able to assist, but if you're using the API then it will inject whatever it's presented with and that would be down to your code, so something that whoever wrote or maintains it would have to address.

[Emily Patrick]

We've just updated our LDAP import tool to version 3.12.0 or 3.9.4 as requested by yourselves back at the end of January this year. It's on the Scripting Server Meteor if that helps

[Steve Giller]

@Emily Patrick Just so I'm clear - is the Last Name successfully resolving to Glück and the Handle to Gluck?

If yes, check what is populating the Handle field.

If the standard AD/Azure fields are used (givenName for First Name and sn for Last Name) and Last Name is successfully resolving to Glück, then I would expect Handle to work as well, unless it's not set to [givenName] [sn]

If it's not set to that it's worth looking at the value in AD/Azure to check that it's set as you require.

[James Ainsworth]

@Emily Patrick

For reference, if you are not familiar with the LDAP import configurations with administration, this can be found under Platform Configuration and then under Data select Data Import Configurations.  Select your LDAP configuration and navigate to the User Account tab.

[Emily Patrick]

@Steve Giller @James Ainsworth

Thanks both for your responses, this is what we have as our Data Import Configurations for staff: 

We're using the [givenName] for the First Name instead of [cn].  I will ask our AD guys to check the values in that field, as it still brings through the name as Gluck:

[Steve Giller]

@Emily Patrick If [sn] is populated (in AD) with Glück and [cn] with Gluck you can use [givenName] [sn] as the Handle value which should populate the correct name.

You would, of course, need to bear in mind that this could affect other Users, e.g. where a person's given name is populated in the [givenName] field but their preferred name is used in the [cn]