add all_users_data_source.go and tests

[Threpio]

For issue: #512

This datasource is to be used to retrieve all users within the AAD (not restricted to groups) and so is a catchall.

The datasource does not currently return the mail_nicknames like some of the other generalised data_sources.

The tests are minimal and I understand if other tests need to be put into place but I am not sure of the scenarios that could be explored. Without more input params or config I do not believe that there is more to tests.

Please let me know if anything needs to be changed/refactored as this is my first PR against this repo.

[manicminer]

Hi @Threpio, thanks for this PR!

Quoting your comment on the issue (#512 (comment)):

@manicminer - We did consider developing it as an extension as the azuread_users datasource but figured that the majority of the times that we use that datasource we DO NOT want a result that is not queried/filtered to be returned. So for us it means that if we mis-configure the datasource then it can look to be correct even when not filtered. (Happy to be overrule in this for the greater project)

It could be deigned as a all_users flag against the azuread_users datasource but I can't see how the ExactlyOneOf functionality for those inputs would work additionally with a boolean flag?

I do think this would be better implemented in the existing azuread_users data source, assuming no blockers arise from trying that. I agree it would be sensible to gate this with a boolean field. For the schema, I think we can add ExactlyOneOf to the boolean field as well and include it in the set of mutually exclusive fields? In the event that it is set to false, and the other fields are not specified, we'd likely have to check this in a CustomizeDiff function, e.g. if show_all_users is false and mail_nicknames, object_ids, user_principal_names are all empty then raise an error

[Threpio]

@manicminer Thanks for the input. I will endeavour to implement it as that flag instead.

Would you like me to abandon this PR and branch or implement it here?

[manicminer]

Keeping it in the same PR is better, don't worry too much about your commit history as we can squash that at merge time :)

[Threpio]

@manicminer - Changes have been pushed and I believe this works. I cannot work out how to test for if an error is thrown. Do you have any examples/documentation for what I could do to test that an error is thrown?

(more specifically with this framework for the showAllusers and ignoreMissing flags both being set to true.

[Threpio]

@manicminer - Sorry for the ping. I have attempted to fix the formatting and pass the linting stage but are still failing.

Any chance you could take a quick look and point out where I have mucked up? I have run the different fmt'ing commands with no changes. Feel free to push to the branch.

[manicminer]

@Threpio No problem at all, it looks like the linter is complaining about line 222 of users_data_source_test.go - it looks like there's a tab indenting this line however Terraform configs should be indented by 2 spaces.

I'm going to queue this for v2.1.0 since we're currently working on some outstanding bugs and getting v2.0.0 ready for release. As it's possible the same files could change in the meantime, once 2.0.0 is out I'll circle back and give a proper review.

[Threpio]

@manicminer I have fixed the merge conflicts - Apologies for the delay.

[manicminer]

Thanks @Threpio, this is looking good. I pushed some small changes:

• I renamed show_all_users to return_all
• We can use ConflictsWith between ignore_missing and return_all, and move the block that makes the API call to the if-else block, and then there's no need to do any apply-time validation :)

Many thanks for the contribution!

Test results:

[github-actions]

This functionality has been released in v2.1.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!

[github-actions]

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.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.