sprasad Posted March 23, 2018 Share Posted March 23, 2018 Good morning @Daniel Dekel Many thanks for that. I have disabled the feature and we are now able to add these contacts successfully. Cheers. 1 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry @Daniel Dekel The patch and setting to disable the check, provides a work around, but there is still the issue that if you want a contact to have an individual primary email address, but use a common (alternate) email address for email notification purposes. Are they any plans to provide this sort of functionality? As this way the contacts could still use their individual primary email addresses as their login id, but emails are sent to the common one. Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted March 23, 2018 Share Posted March 23, 2018 @Martyn Houghton In my previous comments above I said Quote So we are going to look at changing this such that the LoginID WILL BE unique and is the only thing you can use to log in with, this Login ID field can in fact hold an email address so if you want the convenience of being able to login with an email address which is a good option for most people, but you will be stuck with the fact that login ids have to be unique. The current email address WILL NOT BE unique, that will be what is used for email communications for contacts. which will deliver what you are asking for? Gerry Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry I was referring more to your the other comment (below), where the user primary email address would be unique, but the contact one is not. "From what you are saying I think the best option would be to allow a contact to have a notify email address which would allow duplicates, that is distinct from their primary email address which would not allow duplicates. Does that make sense?" Ideally we would want the contact primary email address and the login ID to be the same and unique, but the option for the alternate email field which is already present to be enabled as the email address used in notifications etc, where enabled on a contact by contact basis. Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted March 23, 2018 Share Posted March 23, 2018 @Martyn Houghton Thats what I am saying. The Login ID would be unique, and it should be an email address, that would be the contacts primary email address. The current email_1 address would be the notify email address, that would (as it currently does) allow for duplicates, but that would also no longer allow the email address in that field to be used as a login ID. Are we saying the same thing? Gerry Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry Not quite, we would want is h_email1 and the Login ID to be the same personal identifiable email address and the h_email2 (Alternate Email Address) field to be used when email is sent via connections or BPM notification nodes. In essence you have a radio button on the contacts profile for them/us to set which of the two email addresses they want emails to be sent to. This way email matching in the mailbox to contact will still continue to work when the customer send an email, from there personal email address, but the customer common email address is the one emails are sent too. Using the common email address in h_emial1 will mean you cannot match incoming emails to individuals. Appreciate this is a more involved change due to the different touch points, but in essence would mean you can use both approaches depending on the business requirements. Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted March 23, 2018 Share Posted March 23, 2018 @Martyn Houghton I can see what you are saying but I don't quite understand why it makes sense. What would you want to have in the "Login ID" field thats not an email? Gerry Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry Historic basically, we migrated are large number of login id from our previous system into Support Works and then on to Hornbill, which are not email address based. We currently have 10,876 contacts with a defined value in h_logon_id and of those 10,801 do not contain a '@' symbol in the value. Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted March 23, 2018 Share Posted March 23, 2018 @Martyn Houghton The table is h_sys_contact and the column is h_login_id. Ideally we (you) could migrate the data to fall in line with the change we would like to make if that is possible? Do your customers login with their email address or the legacy login ID you have? Gerry Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry Customer login with the Legacy ID held in h_logon_id column at the moment, but we would like to move people to using their personal email address, but this is where we fall foul of the issue where sites what to use a generic email address for a number of individual accounts for notification/emails. Also as we cannot uses Sites for contact/organisations, we have to have separate contact records for the same person with the same email address but a different logon_id for the each site they support in their shared services setup. Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted March 23, 2018 Share Posted March 23, 2018 @Martyn Houghton Thats exactly the problem though, you cannot have shared login ids, even if they are emails. So every contact has to have a unique login ID, so that can be their personal email address, if they do not have a personal email address then that can be anything else you like so long as its unique in the database. Then the notification email address h_email_1 does not have to be unique. So in your case, you would update login id with the email address, except for where its a shared email address, in which case you would leave what is already present in the login id field? Thats a relatively simple data migration I would have thought? Gerry Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry The main issue I see with this is by having the h_email1 as the shared/non unique email address, email sent into the shared mailbox from the individual's personal email address, would no longer match, so you would not be as easy to log a new request from email without having to search manually for the individual contact. Unless you are are saying the email matching in the shared mailbox also takes into account their alternate email address h_emial2? Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted March 23, 2018 Share Posted March 23, 2018 @Martyn Houghton Yes thats a good point, and I think the email matching would have to match against both fields. Of course this its self presents a challenge because if it matches where there are non-unique emails, you then need to add a whole new UI just to deal with selecting the right one - I expect this is probably already implemented though... Gerry Link to comment Share on other sites More sharing options...
Martyn Houghton Posted March 23, 2018 Share Posted March 23, 2018 @Gerry Indeed, if you can check with the team on the matching algorithm. Cheers Martyn Link to comment Share on other sites More sharing options...
Claire Holtham Posted May 22, 2018 Share Posted May 22, 2018 Hi @Daniel Dekel, I saw on it said "Added a new System Setting api.xmlmc.uniqueUserHandle.enable, setting this option to false allows duplicate handle/display name for the user(s)." Is this same as the patch you were offering back in March? Our setting for api.xmlmc.uniqqueUserHandle.enable is 'on' and I presume to allow duplicate name import we should set that to off? Thanks Claire Link to comment Share on other sites More sharing options...
Daniel Dekel Posted June 11, 2018 Share Posted June 11, 2018 @Claire Holtham, sorry I did not see your message before. To the answer, no. The setting "api.xmlmc.uniqqueUserHandle.enable" was not the one set in the patch. This setting would allow when importing from LDAP to add duplicated handle names in users. To disable the unique handles, you need to set this to OFF (disable). Hope this answers your question. Regards, Daniel. Link to comment Share on other sites More sharing options...
nasimg Posted June 21, 2018 Share Posted June 21, 2018 Is there a negative impact to setting this off (api.xmlmc.uniqqueUserHandle.enable) - when we started with Service Manager I don't think this setting existed or was enabled. I'm now finding issues with our LDAP import where new customers didn't get created (due to having a duplicate handle). I'm also seeing errors were existing staff (with duplicate handles) are having issues raising tickets via the customer portal eg. if there are two Nasim Gani handles (with different login id's) one of the accounts can create request, but the other can not. I think disabling this setting will solve both issues but wanted to make sure I'm not introducing something new. Nasim Link to comment Share on other sites More sharing options...
nasimg Posted June 22, 2018 Share Posted June 22, 2018 A bump in case anyone else has notices issues with duplicate handles.... Nasim Link to comment Share on other sites More sharing options...
Harry Shah Posted June 22, 2018 Share Posted June 22, 2018 @nasimg This setting was introduced few months back which allows customer to allow/disallow duplicate display name. But disabling this setting has no negative impact, other than someone else having the same display name. Thanks, Harry Link to comment Share on other sites More sharing options...
nasimg Posted June 22, 2018 Share Posted June 22, 2018 Thanks @Harry Shah I'll disable the setting - but may raise an incident as it sounds like we shouldn't be getting an error with duplicate handles (unique log in id's). Nasim Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now