terraform-provider-gsuite icon indicating copy to clipboard operation
terraform-provider-gsuite copied to clipboard

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

Open joshk0 opened this issue 4 years ago • 2 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: [email protected]
  2. Create a Google group to which we will add this user: [email protected]
  3. Add them into the list as: [email protected] 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 = "[email protected]"
        id          = "[email protected]"

      - member {
          - email  = "[email protected]" -> null
          - etag   = "\"LwI0XH0sFVdeadbeefUv_0TbaKBpVcsYR6pzE/Xk-RUDdeadbeef9suz-DpD1q4\"" -> null
          - kind   = "admin#directory#member" -> null
          - role   = "MEMBER" -> null
          - status = "ACTIVE" -> null
          - type   = "USER" -> null
        }
      + member {
          + email  = "[email protected]"
          + 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!

joshk0 avatar Mar 05 '20 18:03 joshk0

Might be related to #26

DeviaVir avatar Mar 06 '20 09:03 DeviaVir

What do you think about the proposed workaround @DeviaVir ?

joshk0 avatar Mar 10 '20 16:03 joshk0