search

SCRT-HQ / PSGSuite

Powershell module for Google / G Suite API calls wrapped in handy functions. Authentication is established using a service account via P12 key to negate the consent popup and allow for greater handsoff automation capabilities
https://psgsuite.io/
Apache License 2.0
234 stars 68 forks source link

Added Get-GSChromeDeviceTelemetry #365

Open Foggy2 opened 2 years ago

Foggy2 commented 2 years ago

Added Get-GSChromeDeviceTelemetry Added ChromeMamnagement API to NuGetDependencies.json Updated Newtonsoft.Json version in NuGetDependencies.json to support the ChromeManagement API

This will allow use of the customers.telemetry.devices method of the Chrome Management API.

Haven't done anything on this level before so let me know of any feedback.

FISHMANPET commented 2 years ago

Hey @Foggy2 this looks really good. I assume you've been able to test this yourself in your Org? I don't have access to Chrome devices in mine so I can't test it myself.

Foggy2 commented 2 years ago

Hey @FISHMANPET. Yes, I have been using this for the last couple weeks without issue.

In the interests of consistency I would like your thoughts on the naming? I was unsure if I should call it Get-GSChromeDeviceTelemetry or Get-GSChromeTelemetry. Ultimately I ended up with specifying Device in the name as this one appears to relate only to Chrome hardware devices. However, the Chrome Management API where this request is serviced from does include methods that cover both Chrome browser and Chrome devices at the same time.

We also already have a function `Get-GSChromeOSDevice' as an example too which is another variation on the naming convention.

FISHMANPET commented 2 years ago

Naming can be tricky, especially with some of Google's APIs, but my opinion is that you've made the right choice here. While this is in the "Chrome" API, you're right this particular endpoint only applies to devices, so I think it makes sense to include it in the name.

The other function uses the admin directory API and specifically returns an object of type ChromeOSDevice so that name makes sense there. In both cases, the name is basically going off the actual API that Google provides, so any inconsistency is there. Here it wouldn't be wrong to call it, say, Get-GSChromeOSDeviceTelemetry but now you've made this command inconsistent with the API it uses (OS doesn't appear anywhere in the API names) to keep it consistent with some other basically unrelated API.

As an example of the inconsistencies that appear in something as large as Google's APIs, here's something I came across a few years ago: The enums for two separate endpoints are different in .Net even though they're the same in the REST documentation: https://github.com/googleapis/google-api-dotnet-client/issues/1593

So, I'd say what you've done is fine. If anything, there could be an argument that there should be an alias of Get-GSChromeOSDeviceTelemetry pointing to this function, and Get-GSChromeDevice pointing to Get-GSChromeOSDevice but I don't feel like I'd know enough about Chrome Devices and their management to make that call.