We automated service tickets generation. We are generating service tickets on behalf of some customers when our monitoring detects a fail on their instance. This worked for over a year.
Since about 2 days, the JSD ticket generation fails with a message saying that the raiseOnBehalf field must be fixed. It contains a valid email address of that customer.
The ānameā field of the customer the request is being raised on behalf of.
which doesnāt mean much. For these customers the āFull Nameā is the same as the email address.
One thing I tried is to use the Username which is something like qm:31fā¦ with a very long hex code.
Then it worked.
Can someone tell me if the REST API behavior changed and we are now supposed to add a step to retrieve that Username field from the user to use this āraiseOnBehalfā function?
Iāve replicated your issue on my end, testing both username and email address, it would look like the raiseOnBehalf parameter requires the username for creation. Iāve also asked our team for any changes regarding this. But using the username is a workaround.
{
"name": "qm:9156ac36-2dd5-4541-9efb-596ddf9942c6:5acdd20e9727312a6eacb731", <-- this used to be "joe@example.com"
"key": "qm:9156ac36-2dd5-4541-9efb-596ddf9942c6:5acdd20e9727312a6eacb731", <-- ditto
"emailAddress": "joe@example.com",
"displayName": "Joe Example",<...>
}
The documentation for raiseOnBehalfOf mention, as you quoted:
The ānameā field of the customer the request is being raised on behalf of.
This literally means the name field of the above account object. It is confusing, because that property used to have what looks like an email as its value. The internal representation of accounts changed, and the generated value of ānameā is thus now different.
However, you can now use this ānameā with other APIs like raiseOnBehalfOf but also organisations, participants.
Updates to the REST documentation of JSD are coming to better reflect the above; weāll also try and clarify the naming of some of those properties. Thanks for your feedback!
You have to understand that this breaks completely our automation.
The feature that is now missing is that the customer account was created by this call if it didnāt exist, if you just put the email address in the raiseOnBehalfOf.
Now it would mean 2 other round trips: one to check if the user exists to retrieve itās ānameā, another one to create it if it doesnāt etcā¦
Understood. The thing isā¦ youāve been relying on an undocumented piece of API: the fact that using an āemailā in the āraiseOnBehalfOfā field actually created a customer account; because such accounts were created with the email as the āusernameā, they were also found the same when the account already existed.
@omniengage - I remember you Andā¦ this is bizarre, that should really work. Would help if you could share the payloads you sent and errors you got back.
This happened today as well
Response from jsd was {"errorMessage":"Your request could not be created. Please check the fields have been correctly filled in. Please provide a valid value for field 'Raise this request on behalf of'","i18nErrorMessage":{"i18nKey":"sd.validation.request.creation.failure.required.field","parameters":["Please provide a valid value for field 'Raise this request on behalf of'"]}}
The payload was
{'requestTypeId': u'2', 'raiseOnBehalfOf': u'qm:1cff0dae-7e2e-4dee-84f9-ca3a97833bbf:5ad247092bb3112b34c54b73', 'serviceDeskId': u'1', 'requestFieldValues': {u'description': u"Apr 13 2018 12:42AM OmniEngageStaging: Hola amigo\nApr 13 2018 12:42AM Nishad Musthafa: hi there mr pepe\nApr 13 2018 12:43AM OmniEngageStaging: hi, what's wrong with this box\nApr 13 2018 12:43AM OmniEngageStaging: ?\nApr 13 2018 12:43AM Nishad Musthafa: I have no clue. Lets create a ticket first and figure it out\n", u'summary': u'comprende'}}
I think this may have been some sort of race. I created the issue almost immediately after creating the user. I added a small delay after creating the user and then creating the ticket and things seem to be working fine. Iāll hit you guys up if Iām still seeing issues but this no longer seems to be a problem for me.
Got a similar problem but for SERVER JSD. I have to use āemailā the first time, and āusernameā after thatā¦ in other words, if no request exists for that āreporterā, I have to use emailā¦ if there is any already, I have to use āusernameāā¦
Is this ok???
thanks!
We want the Modify Reporter field to be enabled on some request types, but not on others. Is there a way to set this granularly, or is it only possible as a per-project setting?
Andā¦ this is bizarre, that should really work. Would help if you could share the payloads you sent and errors you got back.