add datasource tfe_organization_members

[Uk1288]

Description

Add datasource tfe_organization_members which returns a list of active members and members with pending invite in an organization.

Testing plan

1. Use config with:

resource "tfe_organization" "bar" {
   name = "org-bar"
   email = "user@hashicorp.com"
}

data "tfe_organization_members" "foo" {
  organization = tfe_organization.bar.name
}

1. a list of members and members_waiting in the org should be returned

{
  "id" = "my-org"
  "members" = tolist([
    {
      "organization_membership_id" = "ou-id"
      "user_id" = "user-id"
    },
  ])
  "members_waiting" = tolist([
    {
      "organization_membership_id" = "ou-id"
      "user_id" = "user-id"
    }
  ])
  "organization" = "my-org"
}

External links

Include any links here that might be helpful for people reviewing your PR. If there are none, feel free to delete this section.

• go-tfe documentation
• API documentation

Output from acceptance tests

Please run applicable acceptance tests locally and include the output here. See TESTS.md to learn how to run acceptance tests.

If you are an external contributor, your contribution(s) will first be reviewed before running them against the project's CI pipeline.

$ TESTARGS="-run TestAccTFEWorkspace" make testacc

...

[sebasslash]

All in all, phenomenal work 🚀 ! I've requested some minor changes, but we can discuss them if you have other thoughts! Excited for this change 😁

Smoke tested ✅

[sebasslash]

I love that you sort this distinction in membership status 👍

[sebasslash]

I think options should be defined locally here rather than as a parameter. Suppose the caller of fetchOrganizationMembers() mutates options ... could lead to some wonky behavior here. Alternatively, if you do want the caller to be able to define options, it should be passed by value.

[Uk1288]

right, to make it flexible for callers of this function to pass in respective options, I will update the option to pass by value.

[sebasslash]

I'm curious if we can get away with registering the cleanup function inside the helper rather than returning it:

t.Cleanup(func() {
    // delete orgMembership
})
return orgMembership

[Uk1288]

yes, this should work as well

[sebasslash]

💅 Typically in our examples we also include defining the resources our documented resource would depend on:

resource "tfe_organization" "deathstar" {
   name = "deathstar"
   email = "sheev.palpatine@hashicorp.com"
}

data "tfe_organization_members" "stormtroopers" {
  organization = tfe_organization.deathstar.name
}

😄

[Uk1288]

good point!

[sebasslash]

I would like this to be released in conjunction with #617 💜

[brandonc]

Elsewhere in the provider, we call this the organization_membership_id (tfe_team_organization_member resource) and colloquially "organization membership id" in other places (tfe_organization_membership resource and data source)

I think we should reuse this long name so we don't risk id confusion. WDYT?

[Uk1288]

this sounds reasonable to me, I will update the name to match.

[brandonc]

Since we require only the user ID, there is no need to include users because the normal result only returns the ID. This should make fetching them faster since no extra user data has to be transmitted unnecessarily.

[Uk1288]

Nice, I didn't realize user ID comes by default. 🎉

[brandonc]

I'm feeling like this function shouldn't accept an arbitrary ListOptions parameter. Reason being, you always want to start at page 1 and return all pages, plus the shape of the return value determines which include params you need in the first place.

[Uk1288]

I don't have a strong opinion about this one so I'll update it