import AppUserBaseSchemaProperty fails on 4.11.0 due to "permissions", "user_type" and "union"

[notdodo]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v1.9.7
on darwin_arm64
+ provider registry.terraform.io/okta/okta v4.11.0

Your version of Terraform is out of date! The latest version
is 1.9.8. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

• okta_app_user_schema_property
• okta_app_user_base_schema_property (probably)

Terraform Configuration Files

terraform {
  required_providers {
    okta = {
      source = "okta/okta"
      version = "~> 4.11.0"
    }
  }
}

provider "okta" {
  org_name = "mytenant"
  base_url = "okta.com"
}

import {
  to = okta_app_user_schema_property.employee_info_subcompany
  id = "<applicationId>/EmployeeInfoSubcompany"
}

resource "okta_app_user_schema_property" "employee_info_subcompany" {
  app_id        = "<applicationId>"
  index         = "EmployeeInfoSubcompany"
  title         = "EmployeeInfoSubcompany"
  external_name = "EmployeeInfoSubcompany"
  type          = "string"
  description   = "string"
  master        = "PROFILE_MASTER"
  scope         = "NONE"
  permissions   = "READ_ONLY"
}

Debug Output

https://gist.github.com/notdodo/cf091e762bdaa39a5a59fa50cfe63f74

Panic Output

Expected Behavior

When using the above main.tf my expectations are:

• import the resource and use automatically the default values for user_type and union
• import the resource and do not show + or changes for the permissions valua, already present in the main.tf

Can this be done in the Admin UI?

No

Can this be done in the actual API call?

I don't know

Actual Behavior

  # okta_app_user_schema_property.employee_info_subcompany will be updated in-place
  # (imported from "<applicationId>/employee_info_subcompany")
  ~ resource "okta_app_user_schema_property" "employee_info_subcompany" {
        app_id             = "<applicationId>"
        description        = "string"
        external_name      = "EmployeeInfoSubcompany"
        external_namespace = null
        id                 = "<applicationId>/EmployeeInfoSubcompany"
        index              = "EmployeeInfoSubcompany"
        master             = "PROFILE_MASTER"
      + permissions        = "READ_ONLY"
        required           = false
        scope              = "NONE"
        title              = "EmployeeInfoSubcompany"
        type               = "string"
      + union              = false
        unique             = null
      + user_type          = "default"
    }

Terraform wants to add again the permissions attribute even if already present in the code.

Steps to Reproduce

1. terraform apply

Important Factoids

I'm coming from the pulumi okta provider and I noticed that when importing that kind of resources (AppUserBaseSchemaProperty and AppBaseSchemaProperty) the import fails since union, userType and permissions attributes do not match the one coming the API. This issue could also affects other resources

[duytiennguyen-okta]

OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-822266

[duytiennguyen-okta]

This is expected behavior. All the fields you mentioned is terraform exclusive. These field related to how you want to manipulate the resource and does not come the API, therefore it will not be set during import

[VenelinMartinov]

@duytiennguyen-okta The terraform provider has an opportunity to fill in these terraform-exclusive properties when importing.

In the SDKv2 the Importer method can fill in defaults for these properties, so that the plan after does not show a diff. In the Plugin Framework the ImportState function can do the same.

Can we consider reopening this issue? It isn't working as intended as the user experience here is suboptimal.