gitlab_user: Do not set skip_confirmation on read #491
Conversation
armsnyder
changed the title
|
If we do not set it on read, it means that it will always be flapping if a user sets it to true. We might need a suppressdiff function? |
|
Hmm, I thought if we don't |
It will not change the user input on import, would it? |
|
The correct behaviour would be: set it to computed + force_new |
|
Updated. That seemed to work. |
|
Let's not merge this until #493 is resolved, since I did not run these tests myself locally. |
armsnyder
force-pushed
the
bugfix/user-npe-2
branch
from
80a156c
to
99a79d7
Compare
armsnyder
force-pushed
the
bugfix/user-npe-2
branch
from
99a79d7
to
56cbf6d
Compare
There was a problem hiding this comment.
Needs a rebase, but I think otherwise LGTM. The referenced blocker has also been resolved some time ago.
What do you think @armsnyder ?
gitlab_user tests refactor: Remove Password and SkipConfirmation fields from testAccGitlabUserExpectedAttributes struct These fields were not being checked in testAccCheckGitlabUserAttributes because they cannot be read. gitlab_user: Make skip_confirmation ForceNew, and more tests
armsnyder
force-pushed
the
bugfix/user-npe-2
branch
from
56cbf6d
to
c5ad040
Compare
|
This functionality has been released in 3.9.0 of the Terraform GitLab Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue. Thank you! |
Follow-up on #490 @roidelapluie
I looked at it again, and I don't think
skip_confirmationshould ever be set during reads or imports, since it is an attribute that only has effect during initial creation. (API ref)This change should fix an issue where, if the resource is created with
skip_confirmation=false, then when the user confirms their email, it would result in an unnecessary resource diff ofskip_confirmation=true.