The `unifi_settings_mgmt` resource fails for me with the following error:
```
Error: unable to decode body: GET s/default/get/setting/mgmt unable to unmarshal alias: json: cannot unmarshal object into Go struct field .x_ssh_keys of type string
```
My `x_ssh_keys` looks like this:
```
[
{
"name": "Laptop",
"type": "ssh-rsa",
"key": "REDACTED",
"comment": "REDACTED",
"date": "2021-02-25T08:26:04Z",
"fingerprint": "REDACTED"
}
]
```
New unmarshalling rules for fields which could be numeric or string
values were not properly typecasted upon being deserialized.
Cleaned up the api template file and moved custom unmarshalling type
logic into go code out of the template.
the status enpoint requires auth, at least in my Cloud Key Firmware 2.X
(UniFi OS) setup.
Presumably there are benefits to checking status before logging in; in
which case I expect this PR will need to be edited.
This commit changes the code generator to generate a `UnmarshalJSON` for each
struct, so that if unmarshalled it properly handles UniFis varying integer values
via the `emptyStringInt` type.
Structs not including a field of `int` type will still have the function generated,
but it will effectively do nothing.
Fixes#18
* Allows for specifying more customizations per field in each type.
Previously, the switch clause didn't allow sub-types to be modified, but
that became a problem with some of the more complex types.
* Fixed several problematic fields in the Device resource
* Removed the underscore separator from generated type names
This allows callers to create complex payloads; for example, to create a
Device type for a Unifi Switch with PortOverrides, the caller needs to
create these sub-types, which is not possible when it's purely embedded.
* Allows for generating top-level types for any embedded struct so
that sub-types can be properly instantiated from calling code
* Specifying `-no-embedded-types` will generate top-level types
rather than embedding the struct
* Refactored "Device" API
* All fields set to `omitempty` because it describes all possible
device types, so effectively any field could be omitted any time
* Fixed `get` call for "Device" API; replacing `rest` with `stat`
* Generated `get` and `update` calls for `Setting*` APIs
* Added `5.14.23` JSON files
Joshua Spence