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
terraform applyterraform 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)
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.