DeviaVir / terraform-provider-gsuite

A @HashiCorp Terraform provider for managing G Suite resources.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

gsuite_group_members resource is case sensitive in places where the Admin API isn't

joshk0 opened this issue · comments

Hi all, first of all thanks for this provider. It's very useful and helps plug a gap in my organization's ACL management strategy. I will soon link an interesting open source project that uses your provider heavily, once it is approved by my company to release. :)

In my tool, I use the gsuite_group_members resource to bulk set the entire membership of a group. However, I find that this resource is case-sensitive when I don't think G Suite actually cares.

To reproduce,

  1. Create a G Suite user with some special casing: John.Doe@yourcompany.com
  2. Create a Google group to which we will add this user: group@yourcompanby.com
  3. Add them into the list as: john.doe@yourcompany.com using the gsuite_group_members provider. (note the modified case)

At this moment, the user will actually be a member of the group. However, once you terraform plan again, we detect the case difference and the provider will want to remove the cased membership, and re-add the lowercased membership (even though it all washes out to the same thing.)

Example output:

  # gsuite_group_members.test will be updated in-place
  ~ resource "gsuite_group_members" "test" {
        group_email = "group@yourcompany.com"
        id          = "group@yourcompany.com"

      - member {
          - email  = "John.Doe@yourcompany.com" -> null
          - etag   = "\"LwI0XH0sFVdeadbeefUv_0TbaKBpVcsYR6pzE/Xk-RUDdeadbeef9suz-DpD1q4\"" -> null
          - kind   = "admin#directory#member" -> null
          - role   = "MEMBER" -> null
          - status = "ACTIVE" -> null
          - type   = "USER" -> null
        }
      + member {
          + email  = "john.doe@yourcompany.com"
          + etag   = (known after apply)
          + kind   = (known after apply)
          + role   = "MEMBER"
          + status = (known after apply)
          + type   = (known after apply)
        }
        member {

While I'm not sure what consequences this would have, it would seem that making the provider insensitive to differences in member email casing would fix this problem. That could be done by taking the lowercase value of emails in both state and remote configuration pulls. If that seems reasonable, I'm happy to submit a PR, but first want to check with the geniuses of G Suite in this community to see if that's the right idea first.

Thanks!

commented

Might be related to #26

What do you think about the proposed workaround @DeviaVir ?