Somehow in the last days the behavior of creating a customer changed. Earlier the username was automatically the email-address after creating a new customer. However now by creating the customer it’s username is set to some art of a hash, e.g. “qm:2d7b973f-…”.
As an example there is the case with old customers where everything is created with there email-addresses, e.g. Username: example@test.test, Emailaddress: example@test.test, Name: John Smith. So I could get users to organizations by there email-addresses (usernames) but now with this change I cannnot do this. I only get the error with “Usernames not found”, which is correct because the new customers do not have email-addresses as usernames.
Unfortunately I could not found any information about any changes or new releases.
You’re right - a recent internal change has surfaced those new accountIDs onto the API.
I would have sworn that the add-customer-to-organisation would simply accept those new account IDs (despite the inconsistent name of the “usernames” property), but that doesn’t seem to be the case. I’ve created a bug report for you to follow: [JSDECO-91] - Ecosystem Jira
Hi @maarten, that was my assumption as well but it was explained to me that it was a change to get JSD customer accounts inline with an Atlassian Account and was a separate planned change outside of GDPR.
As for other things related to GDPR we are working on multiple comms and hope to be able to share soon.
I jumped to conclusions a bit too fast. I thought for a moment that the JSD Customer’s default Full name would be hashed. But this is not the case as there seems to be a difference between ‘Account details’ and ‘Jira profile’.
I’m looking forward to any news regarding GDPR though. Not just for our apps, but also as a JSD user.
@Maarten indeed unrelated to GDPR but rather to a change on how internal user IDs are represented.
I understand the pain - it was an easy assumption to make that the “username” would remain the same as the email; we should have documented that change, but didn’t realise it would already be visible in APIs.
The breakage that @y.sentuerk mentioned, which is that using those new IDs in e.g organizations APIs was not working, is now fixed. Apologies for the inconvenience!
@gjoseph That’s unfortunate… Are there any plans on making the user creation API for non-admin users? Because in our scenario, agents will open requests for customers from Outlook (an email). It’s possible for them to create the customer user in ServiceDesk directly, so I guess it should be allowed for them as well via API?
Thanks for the information and for the quick response!
Are there some plans for a new function for getting the information of the customer in future? As some customer now have the email-address and some the new qm-hash as key, it could help to first ask for an existing customer‘s key for later on moving him to another organization with the correct key.
@y.sentuerk@tobias.viehweger both yes to your questions. Re permissions, either we’ll open up the customer creation API, or we’ll add support for emails to the “request on behalf of” API. Re “getting” a customer, I think we’ll cover this at [JSDECO-9] - Ecosystem Jira