Retrieving and setting custom_quicksupport_id

Hi all,

I've had a look through the API documentation, and I can't seem to find any API to get a list of the custom QuickSupport modules I've created. Not a huge issue, as I can assign them to a user and get the QuickSupport ID.

However, when I try to create a new user with that field set, or update that field on a user after creation, I get "internal_error" and error code 3. Can anyone tell me what I'm doing wrong?

$updateBody = @{
"custom_quicksupport_id" = "<myId>"
} | ConvertTo-Json

$updateResponse = Invoke-RestMethod -Method 'PUT' -Headers $postHeader -Uri "$baseUri/api/v1/users/$($response.id)" -Body $updateBody
Invoke-RestMethod : { "error":"internal_error", "error_code":3, "error_signature":"8bEWb8/54de6a10/070318" }
At line:1 char:19
+ .. . eResponse = Invoke-RestMethod -Method 'PUT' -Headers $postHeader -Uri ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException, Microsoft.PowerShell.Commands.InvokeRestMethodCommand

Find more posts tagged with

Comments

DomLan

Hi @JohnMoe

Try to assign "auto" as value for custom_quicksupport_id: if it work it's a problem related with your QS id.

Otherwise it will be necessary to investigate further. Snippets you provided aren't enough. You need to retrieve the web traffic generated by your call: you can use Fiddler or WireShark and post the content of your PUT here, obviously obfuscating the authorization elements that represent your account.

Regards

JohnMoe

That has failed as well, with the same error.

DomLan

Hi @JohnMoe

well, remains the problem initially indicated: "I think the anomaly can be traced back to the same problem that you faced in your previous post."

Try to remove quotes:

from

$updateBody = @{
"custom_quicksupport_id" = "<myId>"
} | ConvertTo-Json

$updateBody = @{
 custom_quicksupport_id = "<myId>"
} | ConvertTo-Json

Regards

JohnMoe

I've just tested now against PowerShell v6, using the Authentication, Token, and ContentType parameters, and I get the same error:

PS C:\Program Files\PowerShell\6.0.0> Invoke-RestMethod -Method 'PUT' -Authentication 'Bearer' -Token $secToken -ContentType 'application/json' -Uri "$baseUri/api/v1/users/<userid>" -Body $updateBody
Invoke-RestMethod : {"error":"internal_error","error_code":3,"error_signature":"8bEWb8/7de3d8e2/090318"}
At line:1 char:1
+ Invoke-RestMethod -Method 'PUT' -Authentication 'Bearer' -Token $secT ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: PUT, Re...ication/json
}:HttpRequestMessage) [Invoke-RestMethod], HttpResponseException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

JohnMoe

Hi Dom,

The Authentication and Token parameters seem to be new parameters in PS v6; I have it on my PS Core installation, but not the PS v5 that I use day to day. I can't use PS v6 yet for this, because the Active Directory cmdlets don't work with the newly re-architected v6; AD (and lots of other PS modules) need to be updated to work with this new cross-platform version of PowerShell. And that documentation you linked, it mentions that all this does is set the header for you; if you supply an Authentication option in your header, setting the Authentication parameter will overwrite it. Two means to the same end.

When I define my body, I create a hashtabe of names and values; I pipe this through ConvertTo-Json to convert it from a PowerShell hashtable to a JSON string. The hashtable notation looks similar to JSON, but it's quite different in memory.

And I understand that a "unkown_error" means the server received something that the programmer didn't expect. I'm just not sure what's unexpected, given that I've passed the parameters the documentation says are needed.

DomLan

Hi @JohnMoe

I think the anomaly can be traced back to the same problem that you faced in your previous post.

Compared to what Microsoft documented for the Invoke-RestMethod function, the parameters -Authentication and -Token (given that the authorization is of Bearer type) are not present in your example.

I guess you forced the values all together in the -Headers parameter, but since there are specific ones you should use these. Again, you should also define the -ContentType, moving it from -Headers to this parameter. Finally, it makes no sense to use the CONVERT-JSON function if you have already defined a variable that is itself a JSON payload.

Non-speaking anomaly messages: take a look at my previous answer on this thread. In general, API services are usually not very generous in providing detailed information. The two errors you have reported are still described, in general, in the appendix to the reference document that describes the TeamViewer APIs. A 500 error occurred on the server: often it is symptomatic of a situation not foreseen by the programmer who wrote the service, which perhaps did not expect to deal with a malformed request.

Regards