Ben_Carroll | 2017-09-22 13:51:37 UTC | #1
Hi,
As the title suggests, I am attempting to stop campaigns via the API but cannot complete the process. The complete error message is below:
{"status":400,"code":"invalid.update.bad.status.transition","message":"An attempt was made to update a Campaign in an invalid way. Details: Cannot directly change the campaign status from <STOPPING> to <OFF>","messageWithParams":"An attempt was made to update a {entity} in an invalid way. Details: {INVALIDUPDATEBADSTATUSTRANSITION}","messageParams":{"INVALIDUPDATEBADSTATUSTRANSITION":"Cannot directly change the campaign status from <STOPPING> to <OFF>","entity":"Campaign"},"contextId":"328b8e9c-1f5b-4142-b3cb-1938c80bb578","details":[],"errors":[]}
It's my understanding that this is happening because one or more calls are still "active" in the campaign. These calls are not from active agents. I am attempting to end these conversations using the API but am unsure of how to accomplish this.
tim.smith | 2017-09-22 16:00:07 UTC | #2
Ben_Carroll, post:1, topic:1851
I am attempting to end these conversations using the API but am unsure of how to accomplish this.
You can use PATCH /api/v2/conversations/calls/{conversationId} to set the state to disconnected. Your user needs the disconnect conversation permission to do this.
Ben_Carroll | 2017-10-05 17:38:44 UTC | #3
Looking through the Analytics conversation queries, both detail and aggregate, I cannot seem to find any predicate that would filter conversations by "state". Am I missing something or does this predicate not exist?
tim.smith | 2017-10-05 19:38:49 UTC | #4
"state" isn't really a concept in analytics data; it's something that you would derive from other data points. What are you trying to filter for?
Ben_Carroll | 2017-10-09 16:07:58 UTC | #5
Our nightly mainenance procedures are now requiring that I turn off all campaigns before my processing can begin. This is stopped by any conversations not being handled properly and I need to program a way to end these conversations through the API. To do that, I need to know which conversations to end and how to do so in a timely manner.
tim.smith | 2017-10-09 16:22:57 UTC | #6
You can use an analytics query with a conversation filter to find conversations that don't have a value for conversationEnd. You could also filter for the campaign in question via a segment filter for outboundCampaignId.
Ben_Carroll | 2017-11-03 20:46:24 UTC | #7
So now I'm at a point where I'm starting testing and i get the following error:
Error calling PatchConversationsCall: {"status":400,"code":"not.a.user","message":"This request requires a user context. Client credentials cannot be used for requests to this resource."}
My entire setup is based on the OAuth 2.0 Auth Bearer Token using client id and secret. What am I doing wrong?
Ben_Carroll | 2017-11-06 18:57:53 UTC | #8
For a little more information I looked at the documentation here, https://developer.mypurecloud.com/api/rest/v2/conversations/index.html, it states the following:
PATCH /api/v2/conversations/calls/{conversationId} Update a conversation by setting it's recording state, merging in other conversations to create a conference, or disconnecting all of the participants Required Permissions
User making this call must have ANY of these permissions: conversation:communication:disconnect
I checked the permissions assigned to the role my client is assigned to and this permission is set.
tim.smith | 2017-11-07 17:27:17 UTC | #9
The majority of the conversations resources require a user context to work (i.e. you can't use client credentials). The error you're getting is correct.
To accomplish this functionality, your application must be authorized by a user. Specifically, the user must complete one of the implicit, token, or saml OAuth flows to provide your application an auth token for that user. Any users that your application will make API requests for must complete this step daily (or whenever the auth token expires).
Ben_Carroll | 2017-11-07 19:59:57 UTC | #10
Please correct me if I'm wrong, but what you're stating is that any process using one of these API endpoints, specifically any endpoint that requires a user context like that of PatchConversationsCall, cannot be automated without daily human intervention?
tim.smith | 2017-11-07 20:03:25 UTC | #11
Ben_Carroll, post:10, topic:1851
any process using one of these API endpoints, specifically any endpoint that requires a user context like that of PatchConversationsCall, cannot be automated without daily human intervention?
Yes, that is correct.
Ben_Carroll | 2017-11-07 20:04:55 UTC | #12
Would you be able to explain why it is that some api endpoints would require a user context while others don't? Is it to track the user making the changes?
tim.smith | 2017-11-07 20:18:19 UTC | #13
The decision to require a user context is made on a per-resource basis, so there's not a blanket explanation for all cases. With that said, the most common reason is that there aren't entity-level permissions in PureCloud, so many APIs restrict access to the scope of a single user, determined by inferring the user from the auth token used to make the request.
For example, there are no permissions to restrict which conversations can manipulated (record, transfer, etc.). This means that there are only two methods to determine which conversations can be manipulated by a given auth token: 1) assume no restrictions and allow all auth tokens to manipulate all conversations. Side effect: Billy the call center agent can transfer the CEO's conversations to himself and join in on the conversation. 2) assume that a user can only access their own conversations. Side effect: client credentials grants don't have a user context, so those auth tokens can't manipulate any user's conversations.
PureCloud wouldn't be suitable for general use if the first approach was taken, so the second has been implemented as an intermediate solution until entity-based permissions are added to the product. There are ongoing efforts on that front, but I don't believe there will be anything available in the near future.
Ben_Carroll | 2017-11-07 20:40:22 UTC | #14
Then would I be correct in inferring, based on your statement, that the only user allowed to make this api call would be the user associated with the call itself? As in would I be able to authenticate a single user and have that user's token update other user's conversations?
tim.smith | 2017-11-07 20:43:51 UTC | #15
the only user allowed to make this api call would be the user associate with the call itself?
Correct.
As in would I be able to authenticate a single user and have that user's token update other user's conversations?
No, a user cannot update* another user's conversations.
*caveat: update, in this context, applies to telephony actions such as pickup, record, transfer, etc. You can get the conversation object and can do some things like update participant attributes. These caveats aren't well documented, so don't make too many positive assumptions about what cross-user access is allowed.
Ben_Carroll | 2017-11-07 20:44:51 UTC | #16
Using the endpoint referenced here would any user be able to set the state of a conversation to "disconnected" or is that a user specific thing?
tim.smith | 2017-11-07 20:50:37 UTC | #17
With the correct permission, any user (and maybe even client creds, don't recall off the top of my head) can use PATCH /api/v2/conversations/calls/{conversationId} to set the state of any conversation to disconnected (use the correct media route if not a call). This API will disconnect all participants and end the conversation.
Take note that PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId} only works for the user making the request to disconnect themselves from a conversation and leave the remaining participants alone.
Ben_Carroll | 2017-11-07 20:56:12 UTC | #18
Ben_Carroll, post:7, topic:1851
Error calling PatchConversationsCall: {"status":400,"code":"not.a.user","message":"This request requires a user context. Client credentials cannot be used for requests to this resource."}
Based on this error message I received from the API, I'll assume it wont.
This is an entirely after the fact process, most likely run the following day, wherein I am trying to stop all campaigns. This is a requirement due to other API endpoints being unable to modify campaigns while they are running.
Is this the only method available via the API to clear unended conversations from a campaign?
tim.smith | 2017-11-07 20:58:15 UTC | #19
Ben_Carroll, post:18, topic:1851
Is this the only method available via the API to clear unended conversations from a campaign?
As far as I'm aware, yes.
rob.gevers | 2017-11-08 15:30:41 UTC | #20
This particular case has stirred some discussion internally. There are definitely some limits to what we can allow for client-credentials. That said, automating cleanup like this is probably one of the lower-risk categories. It's possible we may be able to provide some utility endpoints to solve this case without conflicting with the rest of the things we are trying to avoid.
That said, what API to provide is a little unclear. We would like to make sure we provide the most direct solution which in this case is related to the campaign status, not just the individual conversations. We need to do a little more research on our end but will try to provide an update soon on what we can do to help with this. To aid with that, are there any details you can provide on what's causing these interactions to stay open?
Ben_Carroll | 2017-11-08 19:50:07 UTC | #21
I will do some deeper digging in the next few days. Once I've gathered more information I will post it here.Thank you for the update.
system | 2017-12-09 19:50:35 UTC | #22
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 1851