Open exitcode0 opened 1 year ago
Thanks @exitcode0, I'll look into this. Your research notes seems logical to me so far. Okta internal reference: https://oktainc.atlassian.net/browse/OKTA-585640
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days
Seems related to #1491
Community Note
Description
Currently it appears that
okta_admin_role_custom_assignments
uses<resource_set_id>/<custom_role_id>
as the ID in the state file the result is that if twookta_admin_role_custom_assignments
attempt to reference the same resource set and custom role ID they will conflict with one another Should we instead use the binding ID for this resource? this would allow twookta_admin_role_custom_assignments
to re-use the same resource set and custom role but specify different membersThis is useful if you want to define your Okta admin permissions in seperate files - we do this to attempt to keep all related resources within the same TF file, this makes for easier deprecation when the time comes as you don't need to go searching for references elsewhere (e.g Business Unit "XYZ" no longer needs admin permissions to okta, just delete
okta_admin_xyz.tf
)New or Affected Resource(s)
Potential Terraform Configuration
resource_sets.tf
okta_admin_example1.tf
okta_admin_example2.tf
References