-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bugfix CA Policies #569
Bugfix CA Policies #569
Conversation
Nice catch, do you think we need a bunch of tests to make sure we've got 100% coverage or this will be good? |
@kaovd I'm not sure really, there are so many different combinations we could produce tests for there has to be a balance and the real world will always produce something we didn't plan for. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @alexwilcox9 thanks for picking this up. This seems to be down to API bugs where it won't allow boolean values to be false, but insists they be omitted entirely to unset them!
The approach you've taken is good, my only suggestion would be for the flatten funcs, that they always set values even when those values are the default. Suggested approach inline below :)
We also seem to have missed some nil checks in the initial implementation which would account for the crashes you saw. I added nil checks for all nested pointers in my below suggestion.
In terms of tests, I think we're OK for these (API bug causing) cases to not litter the tests with all the different permutations as that will explode exponentially.
internal/services/conditionalaccess/conditional_access_policy_resource.go
Outdated
Show resolved
Hide resolved
internal/services/conditionalaccess/conditional_access_policy_resource.go
Outdated
Show resolved
Hide resolved
internal/services/conditionalaccess/conditional_access_policy_resource.go
Outdated
Show resolved
Hide resolved
internal/services/conditionalaccess/conditional_access_policy_resource.go
Outdated
Show resolved
Hide resolved
Thanks for the feedback @manicminer I've now added the requested changes |
Note to reviewer: This change is technically breaking since some Optional fields are now Required, but those fields were required by the API anyway and omitting them would have failed to apply. The updated Adjust the behaviour of the
|
- Make some properties Required where required by the API - Adjust the behaviour of the `sessionControls` field - The API is very fussy about the field in POST requests - Where it has no features enabled, it must be omitted - Where a feature in this section is disabled, that feature must be omitted - This does not apply to PATCH requests, where `sessionControls` can be omitted when no contained features are enabled, but if any are enabled, all the features must be specified with their respective `isEnabled` field.
- Change the API version for conditional access p[olicies to v1.0 (was beta) - Add a conditional forcenew on session_controls.0.sign_in_frequency and sign_in_frequency_period - Additional test coverage for different change scenarios - Ensure that: - On create, session_controls properties all false yields an empty object in the API request - On create, session_controls properties that are false are omitted entirely - On update, session_controls properties are explicitly disabled if not defined in config
e1aee36
to
de4d93e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM 🚀
internal/services/conditionalaccess/conditional_access_policy_resource.go
Outdated
Show resolved
Hide resolved
This functionality has been released in v2.3.0 of the Terraform 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 following the template. Thank you! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Fixes #568
Whilst testing this I initially started by commenting out the setting of
ApplicationEnforcedRestrictions
andCloudAppSecurity
inexpandConditionalAccessSessionControls
which bizarrely started causing panics inflattenConditionalAccessSessionControls
I believe I've solved this by adding some nil checks in that function
I found that not setting
ApplicationEnforcedRestrictions
andCloudAppSecurity
at all inexpandConditionalAccessSessionControls
even if they weren't set in the terraform configuration got it working so I've now rearranged the logic in that function so that if the attributes aren't set in the terraform we don't instantiate those structsI've tried updating the
session_controls
block in the complete test to the following and all are now passingAlso when running all these tests I did hit the update issue that named locations were getting (and were solved by the refresh func) but I wasn't sure how best to go about adding this as I see in named locations you just compare each value in turn and there's a lot of values to check in this resource! If that is the way I'm happy to crack on, just wanted to check first