Open exitcode0 opened 1 month ago
@exitcode0 so this is related to the OIN app? Similar to #1805? Or you just want to expose the schema through datasource? I am a bit confused?
This issue is stale because it has been open 60 days with no activity. Comment or this will be closed in 35 days
@exitcode0 so this is related to the OIN app? Similar to #1805? Or you just want to expose the schema through datasource? I am a bit confused?
@duytiennguyen-okta It is related, but I guess this is for a slightly different ask If I can't create the application in its final state, it would be good to be able to determine if the application is in the pre or post schema mutation
OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-795169
Community Note
Preamble
There is an existing issue for this that was a victim of the old stalebot - #1195 I decided to create this issue rather than commenting on the now closed issue as a comment on the now closed issue relies on people not missing the Github Notification for the comment
Prior Context
Provisioning applications can mutate their base or custom schema when provisioning is enabled for the first time This leads to a few problems for the provider (more details in #1805):
Current Behaviour
Currently to work around the state of an application's schema being unknowable I must use
terraform.workspace
orokta_app_saml.features
to infer the state of schrodinger's app schema in bodgy workaroundsCurrent Workarounds
Click to expand
```hcl locals { exampleApp-to_app = flatten([ { id = "username", expression = "user.login" }, { id = "email", expression = "user.email" }, ( terraform.workspace != "production" ? [] : [ { id = "firstName", expression = "user.firstName" }, { id = "lastName", expression = "user.lastName" } ] ) ]) } resource "okta_profile_mapping" "exampleApp-to_app" { source_id = data.okta_user_profile_mapping_source.user.id target_id = okta_app_saml.exampleApp.id delete_when_absent = false dynamic "mappings" { for_each = local.exampleApp-to_app content { id = mappings.value.id expression = mappings.value.expression # push_status = (contains(okta_app_saml.exampleApp.features, "PUSH_PROFILE_UPDATES") ? "PUSH" : "DONT_PUSH") # push_status = terraform.workspace == "production" ? "PUSH" : "DONT_PUSH" } } } ```Alternative solutions
Importing the Attributes
Importing the attributes is a non-starter because while this will work for the application at hand. If a colleague ever duplicates your configuration to create another app instance, their deployment will fail due to the attempted modification of the application base schema
Proposed Solution
To work around this behaviour of OIN applications, the provider should include a DataSource that facilitates checking the application schema during a
Terraform plan
orTerraform apply
New or Affected Resource(s)
okta_app_user_base_schema
okta_app_user_custom_schema
okta_app_user_schema
Potential Terraform Configuration
Click to expand
```hcl data "okta_app_user_base_schema" "exampleApp" { app_id = "1234" } data "okta_app_user_custom_schema" "exampleApp" { app_id = "1234" } locals { exampleApp-to_app = [ { id = "username", expression = "user.login" }, { id = "email", expression = "user.email" }, { id = "firstName", expression = "user.firstName" }, { id = "lastName", expression = "user.lastName" }, ] } resource "okta_profile_mapping" "exampleApp-to_app" { source_id = data.okta_user_profile_mapping_source.user.id target_id = okta_app_saml.exampleApp.id delete_when_absent = false dynamic "mappings" { for_each = [ for attr in local.exampleApp-to_app : attr if contains(data.okta_app_user_base_schema.attributes, attr.id) || contains(data.okta_app_user_custom_schema.attributes, attr.id) ] content { id = mappings.value.id expression = mappings.value.expression # push_status = (contains(okta_app_saml.exampleApp.features, "PUSH_PROFILE_UPDATES") ? "PUSH" : "DONT_PUSH") # push_status = terraform.workspace == "production" ? "PUSH" : "DONT_PUSH" } } } ```References
1195