terraform-provider-okta: Cannot set the okta_policy_password password_history_count to 0

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 -v                                                        
Terraform v1.2.1
on darwin_amd64
+ provider registry.terraform.io/okta/okta v3.28.0

Affected Resource(s)

  • okta_policy_password

Terraform Configuration Files

data "okta_group" "all" {
  name = "Everyone"
}

resource "okta_policy_password" "test" {
  name                   = "testAcc_replace_with_uuid"
  status                 = "ACTIVE"
  description            = "Terraform Acceptance Test Password Policy"
  password_history_count = 0
  groups_included        = [data.okta_group.all.id]
}

Debug Output

Terraform will perform the following actions:

  # okta_policy_password.test will be updated in-place
  ~ resource "okta_policy_password" "test" {
        id                                     = "00p18j8u01q3eQ7dQ0h8"
        name                                   = "testAcc_replace_with_uuid"
      ~ password_history_count                 = 4 -> 0
        # (26 unchanged attributes hidden)
    }

Panic Output

Expected Behavior

After running apply I would expect to see the password_history_count set to 0 instead of 4 inside of okta. When I run plan again it see that the value is still 4.

Actual Behavior

password_history_count is set to 0

Steps to Reproduce

  1. terraform apply
  2. terraform plan

Important Factoids

References

I think its related to this PR https://github.com/okta/terraform-provider-okta/pull/1108

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 8
  • Comments: 15 (1 by maintainers)

Most upvoted comments

Okta internal reference: https://oktainc.atlassian.net/browse/OKTA-547413 Schedule for work in our next sprint, fyi.

Any update here? We’re also experiencing this issue, seems like it should be an easy fix right?

I would assume the issue is that 0 is also the default for an integer, and so the property is assumed to not be set and thus the default behavior (which is to set password history to 4) is performed. You just need to add someway of distinguishing between setting the property to 0 and not setting it at all. If there’s a way to make the property a nullable integer that would probably do the trick.