Raise on Behalf of - API change?

#1

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.

I read in the latest doc here https://developer.atlassian.com/cloud/jira/service-desk/rest/#api-request-post that this field is now supposed to contain

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?

Thanks
Yves

#2

I noticed on the Latest updates page that there was a recent update to /rest/servicedeskapi/request that added a couple of parameters:

Added the approvalStatus parameter and the requestOwnership=APPROVER value to /servicedeskapi/request

I also brought this thread to the attention of the JSD team for further clarification of changes that may have occured in the past few days.

#3

Hi @yves,

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.

Cheers,
Anne Calantog

#4

When you create a customer account, it looks like this:

{
  "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!

#5

@gjoseph thanks for the answer.

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ā€¦

Yves

#6

@gjoseph

I agree with @yves . This can break a bunch of implementations.

However, I made a couple of API calls today even with the format for raiseOnBehalfOf that you suggested and I got back the same error

Details here
JSD url: https://cactussolid.atlassian.net
Time: 2018-04-12 17:12:10.899 PDT
Username: qm:1cff0dae-7e2e-4dee-84f9-ca3a97833bbf:5acff4a12dc58f2b3a94b954

Looks like this isnā€™t working.

This is Nishad btw Greg. We met at App week, Miami. Pardon the weird username. I used it for demoes :slight_smile:

#7

Hey @yves, @omniengage,

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.

Weā€™ll fix this shortly to unblock you folks. For the longer term solution, please see and follow https://ecosystem.atlassian.net/browse/JSDECO-92

@omniengage - I remember you :wink: Andā€¦ this is bizarre, that should really work. Would help if you could share the payloads you sent and errors you got back.

#8

Thanks @gjoseph - appreciated the detailed proposition to fix this.
Yves

#9

Hi @gjoseph,

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'}}

#10

@gjoseph

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.

#11

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!