This adds support for a desired_metadata field to Frontegg Tenant Resource. This is named as-so because this field is merged into the upstream metadata on the Tenant to avoid overwriting any other metadata set on the Tenant by other tools (a use-case we have at Materialize).
It also deserializes the json-ified metadata string returned from the Get Tenant API but only stores values for the specific keys already present in desired_metadata in the terraform state. Therefore the provider only reports changes to those specific keys, and not any others managed outside of terraform.
I tested this using the basic example and validating the Create, Update, Delete of various keys in the metadata, as well as ensuring that separate metadata keys introduced via the Frontegg UI were left alone by the provider.
This adds support for a
desired_metadatafield to Frontegg Tenant Resource. This is named as-so because this field is merged into the upstreammetadataon the Tenant to avoid overwriting any other metadata set on the Tenant by other tools (a use-case we have at Materialize).This uses the Set Tenant Metadata and Delete Tenant Metadata APIs to set and remove metadata fields by key: https://docs.frontegg.com/reference/tenantcontrollerv1_settenantmetadata https://docs.frontegg.com/reference/tenantcontrollerv1_deletetenantmetadata
It also deserializes the json-ified
metadatastring returned from the Get Tenant API but only stores values for the specific keys already present indesired_metadatain the terraform state. Therefore the provider only reports changes to those specific keys, and not any others managed outside of terraform.I tested this using the basic example and validating the Create, Update, Delete of various keys in the metadata, as well as ensuring that separate metadata keys introduced via the Frontegg UI were left alone by the provider.