DXCDT-20: Client data source #511
Conversation
|
|
||
| func newDataClient() *schema.Resource { | ||
| clientSchema := datasourceSchemaFromResourceSchema(newClient().Schema) | ||
| delete(clientSchema, "client_secret_rotation_trigger") |
There was a problem hiding this comment.
We're currently excluding the client_secret_rotation_trigger property when building from the client resource schema. This was proposed in #363 and I'm assuming that the exclusion is still valid but need to verify that no other properties should also be excluded.
| Check: resource.ComposeTestCheckFunc( | ||
| resource.TestCheckResourceAttrSet("data.auth0_client.test", "client_id"), | ||
| resource.TestCheckResourceAttr("data.auth0_client.test", "name", fmt.Sprintf("Acceptance Test - %v", rand)), | ||
| resource.TestCheckResourceAttr("data.auth0_client.test", "app_type", "non_interactive"), |
There was a problem hiding this comment.
The check for against the app_type property is only arbitrary and a naive way of checking that properties outside the ID and name exist on the schema.
PR #363 introduced a more comprehensive method of comparing the data source against the resource configuration, but I think that functionality needs to be looked at closer before we fully integrate.
| Check: resource.ComposeTestCheckFunc( | ||
| resource.TestCheckResourceAttrSet("data.auth0_client.test", "id"), | ||
| resource.TestCheckResourceAttrSet("data.auth0_client.test", "name"), | ||
| resource.TestCheckNoResourceAttr("data.auth0_client.test", "client_secret_rotation_trigger"), |
There was a problem hiding this comment.
Just checking for the absence of this particular property because we explicitly excluded it from the schema definition.
|
|
||
| ## Attribute Reference | ||
|
|
||
| The client data source possesses the same attributes as the `auth0_client` resource, with the exception of `client_secret_rotation_trigger`. Refer to the [auth0_client resource documentation](../resources/client.md) for a list of returned attributes. |
There was a problem hiding this comment.
This seems more reasonable than just duplicating the properties again, it'll just become more of a maintenance liability. However, I'm unsure if this will interfere with other documentation, for example the TF registry docs.
Proposed Changes
Reintroducing the client data source that was originally introduced by #363 by @yinzara. This PR however, it more focused in that it only pertains to the client data source. This PR can serve as a template for future data source contributions.
I've identified a couple points of interest below, mostly around the exclusion of certain properties and the testing inefficiencies.
Acceptance Test Output
Community Note