Terraform Version

terraform: 1.0.2
provider: 0.4.0

Affected Resource(s)

• googleworkspace_user

Terraform Configuration Files

resource "googleworkspace_user" "foo" {
  custom_schemas {
    schema_name = "bar"
    schema_values = jsonencode("Bar")
  }

  custom_schemas {
    schema_name = "baz"
    schema_values = jsonencode("Baz")
  }
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

Stable terraform plan after terraform apply, showing no changes.

Actual Behavior

Sometimes (not always) I get a terraform plan that looks like this:
(roughly paraphrased from terraform plan output)

     ~ custom_schemas {                                                                                                                                                           
         ~ schema_name   = "bar" -> "baz"                                                                                          
         ~ schema_values = jsonencode("Bar") -> jsonencode("Baz")                                                                                                                                                                  
      }
     ~ custom_schemas {                                                                                                                                                           
         ~ schema_name   = "baz" -> "bar"                                                                                  
         ~ schema_values = jsonencode("Baz") -> jsonencode("Bar")                                                                                                                                                                  
       }

Steps to Reproduce

Create a user with multiple custom_schemas blocks. See note below

Important Factoids

The bug is at

The underlying Google API only guarantees that customSchemas is a map, and does not guarantee any order. The terraform-provider-googleworkspace needs to sort the responses in order to prevent this sort of terraform plan output.

Hi there,

I could use some help with the googleworkspace_role that is keep throwing 400 while accessing it via a data source.

Terraform Version

Tested in below Terraform versions:
v0.13.7 and v1.0.9
on darwin_amd64

• provider registry.terraform.io/hashicorp/googleworkspace v0.5.0

Affected Resource(s)

googleworkspace_role (Data Source)
googleworkspace_role_assignment (resource)

Terraform code

data "googleworkspace_user" "newuser" {
  primary_email = "[email protected]"
}

 data "googleworkspace_role" "mail_admin" {
   name = "MailAdmin"
 }

resource "googleworkspace_role_assignment" "mail_user_role_assignment" {
   role_id     = data.googleworkspace_role.mail_admin.id
   assigned_to = data.googleworkspace_user.newuser.id
}

Debug Output

https://gist.github.com/gwtfuser/c83cd861463e466b9dde909498581bad

Expected Behavior

data source should have fetched the manually created role via the code.

Actual Behavior

The code is throwing 400 / bad request error.
however the other data source code like googleworkspace_user and googleworkspace_group are working fine.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan

Add functionality to manage organizational units (resource and data source)

resource "googleworkspace_org_unit" "ou" {
  name = "sales"
  description = "corporate sale"
  parent_org_unit_path = "corp"
}

OrgUnits: https://developers.google.com/admin-sdk/directory/reference/rest/v1/orgunits

Terraform Version

provider version 0.4.1

Affected Resource(s)

googleworkspace_user

Terraform Configuration Files

default googleworkspace_user, with minimal fields defined

Expected Behavior

No permadiff

Actual Behavior

Permadiff in terraform plan:

      - emails {

          - address = "[email protected]" -> null

          - primary = true -> null

        }

      - emails {

          - address = "[email protected]" -> null

          - primary = false -> null

        }

      - emails {

          - address = "[email protected]" -> null

          - primary = false -> null

        }

Running terraform apply succeeds, but does not actually delete the email addresses (the provider can't - these are the default addresses that belong to the user), and does not result in future plans no longer including the intention to delete these fields -> a permadiff.

Attempting to get rid of the permadiff by adding the fields manually, i.e.

resource "googleworkspace_user" "example" {
  ...

  emails {
    address = "[email protected]"
    primary = true
  }

  emails {
    address = "[email protected]"
    primary = false
  }

  emails {
    address = "[email protected]"
    primary = false
  }
}

Results in the following error message:

│ Error: Missing required argument

│ 

│   on provider_googleworkspace_users.tf line 47, in resource "googleworkspace_user" "example":

│   47:   emails {

│ 

│ The argument "type" is required, but no definition was found.

since 83b8fd3 added "type" as a required field. However, it does not seem to be defined in the underlying API for these default fields.

Currently we are running into api quota limits (requests per IP address) when using the resource googleworkspace_group_member for big groups during the state refresh as every single member has its own state. Besides that we also want to remove members from a groups which are not managed by terraform.

Example:

resource "googleworkspace_group_members" "manager" {
  group_id = googleworkspace_group.sales.id

  members {
    email = googleworkspace_user.michael.primary_email
    role  = "MANAGER"
  }
  
  members {
    email = googleworkspace_user.scott.primary_email
    role  = "MEMBER"
  }
}

instead of

resource "googleworkspace_group_member" "manager" {
  group_id = googleworkspace_group.sales.id
  email    = googleworkspace_user.michael.primary_email

  role = "MANAGER"
}

resource "googleworkspace_group_member" "manager" {
  group_id = googleworkspace_group.sales.id
  email    = googleworkspace_user.scott.primary_email

  role = "MEMBER"
}

Hi thanks for the great provider

A issue I'm having within a chairty domains I manage on Google Worksapce (previously Gapps for charity) is to manage Gmail features, the things I would like to able to setup is Aliases in the "Send mail as" setting with ability to set a default as as a admin in the dashboard you can give people a Alias but doing the setup of the "Send mail as" means logging into their account/ or screensharing which is difficult for the audiance of people I am working with.

Seems this is covered within the Worksapce for developers help documenation

https://developers.google.com/gmail/api/guides/alias_and_signature_settings

Other things are forwarding, vacation messages and other things that the user manage themselves.

Not sure if this API is in scope as I've never actually done any API integrations myself with this Google API but have used a Trail of a dashboard which gave this support but became prehibitivly expensive for the charity to actually subscribe to it.

Keep up the fantastic work.

(Watched the "Community Office Hours: Terraform" video)

Terraform Version

Terraform v1.0.11 on darwin_amd64

Affected Resource(s)

• googleworkspace_user

Terraform Configuration Files

Lock file
Main.tf

Debug Output

Output

Expected Behavior

A new user to be created in our google workspace.

Actual Behavior

Error as copied into the debug output: no user created.

Steps to Reproduce

1. Apply ALL auths from googleapis.com settings to the google workspace admin.

2. terraform apply
   -> Get correct outcome.

3. Remove auths to provide only those that the docs say are required (i.e. https://www.googleapis.com/auth/admin.directory.user only - see https://registry.terraform.io/providers/hashicorp/googleworkspace/latest/docs/resources/user)

4. terraform apply
   -> Not correct authorization. See output.

Important Factoids

We have gone through systematically to work out which auths from googleapis.com to add to our project in order for this terraform to have the correct permissions. There is no clear combination of auths that allow the terraform to be applied and there is no documentation setting out which you need to enable in order to give terraform access to the workspace. Through testing, we have determined that:

• terraform apply works with all of the auths enabled.
• There is no single auth that allows terraform apply to work.
• Required auths include:
  https://www.googleapis.com/auth/apps.groups.settings, https://www.googleapis.com/auth/chrome.management.policy, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.userschema, https://www.googleapis.com/auth/gmail.settings.sharing, https://www.googleapis.com/auth/gmail.settings.basic, https://www.googleapis.com/auth/admin.directory.customer, https://www.googleapis.com/auth/admin.directory.domain, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.orgunit, https://www.googleapis.com/auth/admin.directory.rolemanagement

Our fundamental concern is that leaving all of the auths enabled is a security risk, giving more power to a service/admin account than is necessary to carry out the task of creating a new user.

Can documentation please be updated to identify precisely which security settings we need to enable?

Expected Behavior

The link in this section should work.

https://github.com/hashicorp/terraform-provider-googleworkspace#using-the-provider

Actual Behavior

https://registry.terraform.io/docs/providers/googleworkspace leads to a 404.

Feature request:

The possibility to use Access tokens instead of service account keys to authenticate with Google Workspace.

Why:

1. Can generate infinite number of tokens per roleset, service account keys have a maximum of 10 keys per account.
2. Service account keys have infinite lifetime in GCP (i.e. if they are not managed properly, leaked keys can live forever)

References

The old terraform-provider-gsuite provider had the same unsolved issue:
DeviaVir/terraform-provider-gsuite#70

Versions

Terraform: 1.0.0
provider: 0.2.0

Affected Resource(s)

• googleworkspace_schema

Terraform Configuration Files

resource "googleworkspace_schema" "aws_session_duration" {
  schema_name = "Amazon SessionDuration"

  fields {
    field_name       = "SessionDuration"
    field_type       = "INT64"
    multi_valued     = false
    read_access_type = "ADMINS_AND_SELF"
  }
}

Panic Output

Stack trace from the terraform-provider-googleworkspace_v0.2.0_x5 plugin:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xdefc00]

goroutine 61 [running]:
github.com/hashicorp/terraform-provider-googleworkspace/internal/provider.flattenFields(0xc0006b0160, 0x1, 0x4, 0xe9b3e0, 0xc0004642b0)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/hashicorp/terraform-provider-googleworkspace/internal/provider/resource_schema.go:400 +0x320
github.com/hashicorp/terraform-provider-googleworkspace/internal/provider.resourceSchemaRead(0x11bf958, 0xc0000ad2c0, 0xc000313f80, 0xf0cd40, 0xc0000ac540, 0xc000299d40, 0xc00064f908, 0x40e0f8)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/hashicorp/terraform-provider-googleworkspace/internal/provider/resource_schema.go:237 +0x471
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0xc000319dc0, 0x11bf8e8, 0xc000311c80, 0xc000313f80, 0xf0cd40, 0xc0000ac540, 0x0, 0x0, 0x0)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:347 +0x17f
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0xc000319dc0, 0x11bf8e8, 0xc000311c80, 0xc000392380, 0xf0cd40, 0xc0000ac540, 0xc00000e380, 0x0, 0x0, 0x0)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:624 +0x1cb
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0xc00000c078, 0x11bf8e8, 0xc000311c80, 0xc000311cc0, 0xc000311c80, 0x40b965, 0xf90880)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:575 +0x43b
github.com/hashicorp/terraform-plugin-go/tfprotov5/server.(*server).ReadResource(0xc0002dfb00, 0x11bf990, 0xc000311c80, 0xc0000ac8a0, 0xc0002dfb00, 0xc0002f4d20, 0xc000430ba0)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/github.com/hashicorp/[email protected]/tfprotov5/server/server.go:298 +0x105
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler(0xfd7ae0, 0xc0002dfb00, 0x11bf990, 0xc0002f4d20, 0xc0000ac840, 0x0, 0x11bf990, 0xc0002f4d20, 0xc0004fc240, 0x114)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:344 +0x214
google.golang.org/grpc.(*Server).processUnaryRPC(0xc00027e540, 0x11ca878, 0xc0005a8780, 0xc000360480, 0xc000223c80, 0x1723cd0, 0x0, 0x0, 0x0)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/google.golang.org/[email protected]/server.go:1217 +0x52b
google.golang.org/grpc.(*Server).handleStream(0xc00027e540, 0x11ca878, 0xc0005a8780, 0xc000360480, 0x0)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/google.golang.org/[email protected]/server.go:1540 +0xd0c
google.golang.org/grpc.(*Server).serveStreams.func1.2(0xc000182510, 0xc00027e540, 0x11ca878, 0xc0005a8780, 0xc000360480)
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/google.golang.org/[email protected]/server.go:878 +0xab
created by google.golang.org/grpc.(*Server).serveStreams.func1
        /opt/teamcity-agent/work/5d79fe75d4460a2f/pkg/mod/google.golang.org/[email protected]/server.go:876 +0x1fd

Error: The terraform-provider-googleworkspace_v0.2.0_x5 plugin crashed!

Steps to Reproduce

terraform import googleworkspace_schema.aws_session_duration XXX==, where XXX== is the schema ID which I found with the API Explorer: https://developers.google.com/admin-sdk/directory/reference/rest/v1/schemas/list

Terraform Version

My terraform version is v1.0.8

Affected Resource(s)

• googleworkspace_group_settings

Terraform Configuration Files

resource "googleworkspace_group_settings" "my_group" {
  email                            = "[email protected]
  allow_external_members           = true
  allow_web_posting                = false
  archive_only                     = true
  who_can_join                     = "INVITED_CAN_JOIN"
  who_can_discover_group           = "ALL_MEMBERS_CAN_DISCOVER"
  who_can_moderate_members         = "NONE"
  who_can_post_message             = "NONE_CAN_POST"
  who_can_contact_owner            = "ALL_OWNERS_CAN_CONTACT"
  who_can_view_group               = "ALL_OWNERS_CAN_VIEW" 
  who_can_view_membership          = "ALL_OWNERS_CAN_VIEW"
}

Expected Behavior

This configuration should work.

Actual Behavior

This configuration fails because ALL_OWNERS_CAN_CONTACT and ALL_OWNERS_CAN_VIEW are not expected values in the provider. However these are the values that are seen when importing a this resource after configuring the group via the Workspace UI like the following image:

Steps to Reproduce

1. terraform apply

Hi, what scopes are required for the data resource googleworkspace_user? I've tried:

oauth_scopes = [
    "https://www.googleapis.com/auth/admin.directory.group",
    "https://www.googleapis.com/auth/admin.directory.user",
    "https://www.googleapis.com/auth/admin.directory.userschema.readonly",
    "https://www.googleapis.com/auth/apps.groups.settings"
  ]

but still get an insufficient scopes error. Thanks!

Terraform Version

0.14.7

Affected Resource(s)

• googleworkspace_group_settings

Debug Output

https://gist.github.com/dwilliams782/41074546edeeb5a989446d6d122f1d34

Code

The following is a module:

// ----------- Group -----------

resource "googleworkspace_group" "group" {
  description = "Managed by Terraform."
  email       = var.email
  name        = var.name

  aliases = var.aliases

  timeouts {
    create = "1m"
    update = "1m"
  }
}

// ----------- Group Members -----------

resource "googleworkspace_group_member" "user" {
  for_each = var.users != null ? var.users : []
  group_id = googleworkspace_group.group.id
  email    = each.value

  delivery_settings = "DISABLED"
  role              = "MEMBER"
  type              = "USER"

  depends_on = [
    googleworkspace_group.group,
    googleworkspace_group_settings.group-settings
  ]
}

resource "googleworkspace_group_member" "group" {
  for_each = var.groups != null ? var.groups : []
  group_id = googleworkspace_group.group.id
  email    = each.value

  delivery_settings = "DISABLED"
  role              = "MEMBER"
  type              = "GROUP"

  depends_on = [
    googleworkspace_group.group,
    googleworkspace_group_settings.group-settings
  ]
}

// ----------- Group Settings -----------

resource "googleworkspace_group_settings" "group-settings" {
  email = googleworkspace_group.group.email

  allow_external_members         = var.allow_external_members
  allow_web_posting              = var.allow_web_posting
  enable_collaborative_inbox     = var.enable_collaborative_inbox
  include_in_global_address_list = var.include_in_global_address_list
  members_can_post_as_the_group  = var.members_can_post_as_the_group
  who_can_contact_owner          = var.who_can_contact_owner
  who_can_join                   = var.who_can_join
  who_can_leave_group            = var.who_can_leave_group
  who_can_view_membership        = var.who_can_view_membership
  who_can_post_message           = var.who_can_post_message

  depends_on = [googleworkspace_group.group]

  timeouts {
    create = "1m"
    update = "1m"
  }
}

Actual Behavior

This request to create a group settings resource is timing out, but the debug logs are showing 200 OK on each request.

Error: timed out while waiting for group settings to be updated

  on modules/_components/iam/google-group/group.tf line 44, in resource "googleworkspace_group_settings" "group-settings":
  44: resource "googleworkspace_group_settings" "group-settings" {

This is inconsistent but has been very repeatable for me, and is breaking my use of this provider through our ci/cd systems.

Terraform Version

1.0.0

Affected Resource(s)

• googleworkspace_group_settings

Terraform Configuration Files

provider "googleworkspace" {
  credentials = "X.json"
  impersonated_user_email = "X"
  oauth_scopes = [
    "https://www.googleapis.com/auth/admin.directory.group",
    "https://www.googleapis.com/auth/admin.directory.user",
  ]
  customer_id = "X"
}


resource "googleworkspace_group" "X" {
  email         = "X"
  description   = "Managed by TF | X"
}

resource "googleworkspace_group_settings" "X" {
  email = googleworkspace_group.X.email

  allow_external_members = false

  who_can_join            = "INVITED_CAN_JOIN"
  who_can_view_membership = "ALL_MANAGERS_CAN_VIEW"
  who_can_post_message    = "ALL_MEMBERS_CAN_POST"
}

Expected Behavior

to run

Actual Behavior

Request had insufficient authentication scopes

Steps to Reproduce

1. terraform apply

Important Factoids

BTW I can create groups and add members to groups using the service account

Add posix_accounts back to the full user #67

Waiting to hear back from the workspace team the best way to fix it. The code there was wrong, but this code should fix it, and it had the same problem

posix_accounts {
    account_id = "dwightschrute"
    gecos = "dwightschrute,1,5551230987,5551237890"
    gid = 1001
    home_directory = "/home/dwightschrute"
    operating_system_type = "linux"
    primary = true
    shell = "/bin/bash"
    system_id = "uid"
    uid = 1010
    username = "dwightschrute"
}

Add functionality to retrieve mobile devices (datasource)

datasource "googleworkspace_mobile_devices" "unencrypted" {
  filter = "encryption_status:not_encrypted"
}

ChromeMobileDevices: https://developers.google.com/admin-sdk/directory/reference/rest/v1/mobiledevices/list
Other Info/Examples: https://developers.google.com/admin-sdk/directory/v1/guides/manage-mobile-devices

Configuration can be found here: https://admin.google.com/ac/apps/gmail/authenticateemail

Suggested configuration:

resource "googleworkspace_dkim_authentication_key" "example" {
  domain_name = "example.com"
  prefix = "google" // default
  key_size = 2048 // default
}

// Example usage in Cloudflare DNS config
resource "cloudflare_record" "google_dkim_example" {
  zone_id = cloudflare_zone.example.id
  name    = googleworkspace_dkim_authentication_key.example.record_name // "google._domainkey"
  type    = googleworkspace_dkim_authentication_key.example.record_type // "TXT"
  value    = googleworkspace_dkim_authentication_key.example.record_value // "v=DKIM1; k=rsa; p=…"
}

Add who_can_approve_members and who_can_ban_users to googleworkspace_group_settings. These fields were left off as they will be deprecated when their functionality is moved into who_can_moderate_members. Looks like we got ahead of ourselves and didn't include them in the resource.

#94 (comment)

Terraform Version

Terraform v0.15.3

Affected Resource(s)

• googleworkspace_chrome_policy

Terraform Configuration Files

resource "googleworkspace_chrome_policy" "bookmarks" {
  org_unit_id = googleworkspace_org_unit.experiment.id
  policies {
    schema_name = "chrome.users.ManagedBookmarksSetting"
    schema_values = {
        managedBookmarks = "{\"toplevelName\":\"Stuff\"}"
    }
  }
}

Debug Output

googleworkspace_chrome_policy.bookmarks: Creating...
2021-07-12T12:48:06.310Z [INFO]  Starting apply for googleworkspace_chrome_policy.bookmarks
2021-07-12T12:48:06.310Z [DEBUG] googleworkspace_chrome_policy.bookmarks: applying the planned Create change
2021-07-12T12:48:06.310Z [INFO]  provider.terraform-provider-googleworkspace_v0.3.0_x5: 2021/07/12 12:48:06 [INFO] Instantiating Google Admin Chrome Policy service: timestamp=2021-07-12T12:48:06.310Z
2021-07-12T12:48:06.310Z [INFO]  provider.terraform-provider-googleworkspace_v0.3.0_x5: 2021/07/12 12:48:06 [INFO] Instantiating Google Admin Chrome Policies service: timestamp=2021-07-12T12:48:06.310Z
2021-07-12T12:48:06.310Z [INFO]  provider.terraform-provider-googleworkspace_v0.3.0_x5: 2021/07/12 12:48:06 [DEBUG] Creating Chrome Policy for org:03ph8a2z1pyp2na: timestamp=2021-07-12T12:48:06.310Z
2021-07-12T12:48:06.310Z [INFO]  provider.terraform-provider-googleworkspace_v0.3.0_x5: 2021/07/12 12:48:06 [INFO] Instantiating Google Admin Chrome Policy service: timestamp=2021-07-12T12:48:06.310Z
2021-07-12T12:48:06.310Z [INFO]  provider.terraform-provider-googleworkspace_v0.3.0_x5: 2021/07/12 12:48:06 [INFO] Instantiating Google Admin Chrome Policy Schemas service: timestamp=2021-07-12T12:48:06.310Z
╷
│ Error: value provided for managedBookmarks is of incorrect type (expected type: TYPE_MESSAGE)
│
│   with googleworkspace_chrome_policy.bookmarks,
│   on chrome_policy.tf line 1, in resource "googleworkspace_chrome_policy" "bookmarks":
│    1: resource "googleworkspace_chrome_policy" "bookmarks" {
│

Expected Behavior

The resource managed bookmarks policy should be created

Actual Behavior

error with the formatting of the request

Steps to Reproduce

1. terraform apply

Important Factoids

I tried a lot of different permutations of configs because it wasn't obvious what should be the payload for this config. None of them worked. It's possible that I just don't understand what the format for the payload should be.

Thanks for releasing this! We're somewhat interested in exploring using this provider while we wait for some updates in the Cloud Identity APIs, but we noticed that it currently uses a different set of environment variables for credentials from the google provider.

Is there any chance this provider could support the use of the GOOGLE_CREDENTIALS environment variable? Our Terraform Cloud workspaces are already configured with this environment variable, and doing so would allow us to use this provider with no further changes.

Hello Community!

We're working on a tool that will migrate the old GSuite provider configurations/state to the Google Workspace provider. We have tested this provider with a basic configuration, but would love the community to help with testing it further. We want to make sure we're covering different use cases and Terraform configurations that will be migrated. If this will help you, please comment and attach the configurations you'd like us to test so we can run them through our tool!

Thanks!

Terraform Version

Terraform v1.0.8
on linux_amd64

• provider registry.terraform.io/hashicorp/googleworkspace v0.5.0

Affected Resource(s)

googleworkspace_group_members

Terraform Configuration Files

data "googleworkspace_group" "testgroup" {
  email = "[email protected]"
}

resource "googleworkspace_group_members" "add" {
  group_id = data.googleworkspace_group.testgroup.id
  members {
    email = "[email protected]"
  }
}

Expected Behavior

Since googleworkspace_group_members is authorative if an existing member is specified in a member block this shouldn't be a problem

Actual Behavior

Error is thrown

│ Error: googleapi: Error 409: Member already exists., duplicate
│
│ with googleworkspace_group_members.add,
│ on main.tf line 35, in resource "googleworkspace_group_members" "add":
│ 35: resource "googleworkspace_group_members" "add" {
│

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Create a workspace group
2. add a user
3. terraform apply with code to add the same user as under step 2

Terraform Version

1.0.2
provider version: latest master (I built a fake "0.3.1" release for myself)

Affected Resource(s)

Please list the resources as a list, for example:

• googleworkspace_user

Terraform Configuration Files

resource "googleworkspace_user" "me" {
  password = <anything>
}

Debug Output

N/A

Expected Behavior

The Google API only requires a password when the user does not exist previously, or when intentionally deciding to update a user's password. When importing a pre-existing user, the statefile should set the password field to some kind of documented placeholder value, or else not require the password field on a provider / resource level.

Actual Behavior

Because the password field is marked as required, it's impossible to import a pre-existing Google Workspace user without setting the user's password at the same time, or manually altering the Terraform state file. This makes it nigh impossible to bring an organization's pre-existing userbase under Terraform's control.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Create a user in Google Workspace, outside Terraform
2. Create a googleworkspace_user resource to symbolize that user
3. Import it - terraform import googleworkspace_user.foo 1234567890
4. Run terraform plan - which either fails because password is not provided, or proposes setting the user's password to the provided string

Follows #94

I'd like to discuss writing a script to help users migrate from the GSuite community provider to the Google Workspace provider. For users who have many resources, bulk import is very painful, it'd be nice if we can contribute to helping them write the script, or creating a tool that will nicely do it for them. This issue is a placeholder for that discussion and will be updated after the team has come up with a clear path forward.

Add support for additionalTargetKeys which will allow practitioners to configure more policies (currently the chrome.printers.* namespace)

Affected Resource(s)

Please list the resources as a list, for example:

• googleworkspace_chrome_policy

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-97

Terraform Version

0.15.3
hashicorp/googleworkspace v0.2.0

Affected Resource(s)

GOOGLEWORKSPACE_CREDENTIALS environment variable.

Terraform Configuration Files

GCP service account key located at ~/.gcloud/keys/googleworkspace.key on my filesystem and GOOGLEWORKSPACE_CREDENTIALS=~/.gcloud/keys/googleworkspace.key set in the environment

Expected Behavior

Per https://registry.terraform.io/providers/hashicorp/googleworkspace/latest/docs#creating-a-service-account-and-credentials saying "set the GOOGLEWORKSPACE_CREDENTIALS environment variable to the path of the service account key.", I expected that the provider would read in the key that exists at that file path and use it for authentication.

Actual Behavior

│ Error: JSON credentials in "~/.gcloud/keys/googleworkspace.key" are not valid: invalid character '~' looking for beginning of value
│ 
│   with provider["registry.terraform.io/hashicorp/googleworkspace"],
│   on terraform.tf line 33, in provider "googleworkspace":
│   33: provider "googleworkspace" {

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Put the service account key at ~/.gcloud/keys/googleworkspace.key
2. export GOOGLEWORKSPACE_CREDENTIALS="~/.gcloud/keys/googleworkspace.key"
3. terraform plan

Terraform Version

Terraform v1.0.8
on linux_amd64

• provider registry.terraform.io/hashicorp/googleworkspace v0.5.0

Affected Resource(s)

googleworkspace_group_members

Terraform Configuration Files

data "googleworkspace_group" "testgroup" {
  email = "[email protected]"
}
resource "googleworkspace_group_members" "empty" {
  group_id = data.googleworkspace_group.testgroup.id
}

Expected Behavior

Since googleworkspace_group_members is authorative all members should be removed from group

In a real scenario we use dynamic member blocks based on a list.
The list can be empty and all members should be removed from the group.

Actual Behavior

Error is thrown
│ Error: Insufficient members blocks
│
│ on main.tf line 24, in resource "googleworkspace_group_members" "empty":
│ 24: resource "googleworkspace_group_members" "empty" {
│
│ At least 1 "members" blocks are required.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Add functionality to manage chrome policies (resource)

resource "googleworkspace_chrome_policy" "device-enrollment" {
  org_unit = 1234321

  policy {
    policy_schema = "chrome.users.DeviceEnrollment"
    policy_values = {
      "autoDevicePlacementEnabled" = jsonencode(true)
    }
  }

  policy {
    policy_schema = "chrome.users.EnrollPermission"
    policy_values = {
      "deviceEnrollPermission" = jsonencode("ALLOW_TO_ENROLL_DEVICES_ENUM_ALLOW_ENROLL_RE_ENROLL")
    }
  }
}

ChromePolicy: https://developers.google.com/chrome/policy/reference/rest
More Information:

• https://developers.google.com/chrome/policy/guides/policy-schemas
• https://developers.google.com/chrome/policy/guides/samples_policyapi

From my understanding:
Create/Update - https://developers.google.com/chrome/policy/reference/rest/v1/customers.policies.orgunits/batchModify
Read - https://developers.google.com/chrome/policy/reference/rest/v1/customers.policies/resolve
Delete - https://developers.google.com/chrome/policy/reference/rest/v1/customers.policies.orgunits/batchInherit

Terraform Version

$ terraform version
Terraform v1.0.4
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v3.74.0
+ provider registry.terraform.io/hashicorp/googleworkspace v0.4.0

Affected Resource(s)

• googleworkspace_group

Terraform Configuration Files

resource "googleworkspace_group" "iam" {
  email       = var.email
  name        = var.name
  description = var.description
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

Running terraform import works.

Actual Behavior

╷
│ Error: googleapi: Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the admin.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters., accessNotConfigured
│
│
╵

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. gcloud auth application-default login --scopes "https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/admin.directory.group.readonly"
2. terraform import

Important Factoids

I believe there are two separate ways this issue could be solved: one, the provider could respect the impersonated_user_email setting when used with application default credentials (currently it only does when an explicit JWT is passed, see [1]); or two, the provider could implement a billing_project setting (similar to the google provider: https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference#billing_project).

[1]

References

None that I could find.

Terraform Version

Terraform v1.0.7
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v3.74.0
+ provider registry.terraform.io/hashicorp/googleworkspace v0.4.1
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/tfe v0.26.1

Affected Resource(s)

• googleworkspace_group_member

Terraform Configuration Files

N/A

Debug Output

Error: googleapi: Error 404: Resource Not Found, notFound
with googleworkspace_group_member.workspace_agent_subnet_network_user["primary"]
on modules/google-shared-vpc-access/main.tf line 59, in resource "googleworkspace_group_member" "workspace_agent_subnet_network_user":
resource "googleworkspace_group_member" "workspace_agent_subnet_network_user" {

Panic Output

N/A

Expected Behavior

The user should have been added to the group successfully, and Terraform should have exited successfully.

Actual Behavior

The user was added to the group, but Terraform failed due to a 404. We had to manually import the resource afterwards.

Steps to Reproduce

Not consistent, so probably hard to reproduce.

1. terraform apply

Important Factoids

Perhaps the code should retry on a 404 after the resource has been created? This seems to be an eventual consistency bug.

I took a quick glance and it seems that there is precedent for this in the google provider with the PollCheckForExistence function [1]. For example, the google_pubsub_topic resource uses this to wait for the resource to exist:

https://github.com/hashicorp/terraform-provider-google/blob/82a1c96e5a4aa7146a6a1b0d4653caa1103bcbe3/google/resource_pubsub_topic.go#L206

References

[1] https://github.com/hashicorp/terraform-provider-google/blob/82a1c96e5a4aa7146a6a1b0d4653caa1103bcbe3/google/common_polling.go#L110

Thanks for the work so far on this provider!

Terraform Version

N/A

Affected Resource(s)

googleworkspace_group_*

Terraform Configuration Files

provider "googleworkspace" {
  customer_id = "some-customer-id"
}

(GOOGLE_CREDENTIALS environment variable is set)

Debug Output

N/A

Panic Output

N/A

Expected Behavior

The provider should work without impersonated_user_email when interacting only with googleworkspace_group_* resources, even if credentials are specified in an environment variable.

Actual Behavior

Received the following

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. GOOGLE_CREDENTIALS=$(cat /path/to/key) terraform plan

Important Factoids

I've heard from a PM (and confirmed with local testing) that you do not need to impersonate a user via Domain Wide Delegation when interacting with the Group API, so long as you have Group Admin (similar to https://cloud.google.com/identity/docs/how-to/setup#auth-no-dwd, though this is for Cloud Identity). Unfortunately the provider requires that we pass in a impersonated_user_email value, even if we're only planning on making googleworkspace_group_* resources.

You can test that this works (without impersonating a user) with the following workaround:

provider "googleworkspace" {
  customer_id             = "some-customer-id"
  impersonated_user_email = "exact-same-email-address-as-the-service-account-credentials"
}

resource "googleworkspace_group" "test_group" {
  email       = "[email protected]"
  name        = "Test Group"

  aliases = []
}

References

N/A

Support Google Sheets

https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets.values

Add something like a privileges datasource. This will require some design work to see how we best want to utilize it.

ChromePolicy: https://developers.google.com/admin-sdk/directory/reference/rest/v1/privileges/list

Terraform Version

$ terraform version
Terraform v1.0.5
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v3.74.0
+ provider registry.terraform.io/hashicorp/googleworkspace v0.4.1
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/tfe v0.26.1

Affected Resource(s)

• googleworkspace_group_member

Terraform Configuration Files

resource "googleworkspace_group_member" "member" {
  group_id = "a-group-id"
  email    = "some-email"

  role              = "MEMBER"
  delivery_settings = "NONE"
  type              = "USER"
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

Updating the email field would remove the previous member, and add the new member.

Actual Behavior

Nothing.

Steps to Reproduce

1. terraform apply
2. Change the email field to another email
3. terraform apply

The update doesn't actually happen, and if you look at the group in Google groups you'll see the members stay the same.

Important Factoids

I'd suggest adding ForceNew to

References

None that I could find.

Terraform Version

Terraform v1.0.7
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v3.74.0
+ provider registry.terraform.io/hashicorp/googleworkspace v0.4.1
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/tfe v0.26.1

Affected Resource(s)

• googleworkspace_group_member

Terraform Configuration Files

N/A

Debug Output

Error: Error when reading or editing groups/<group-id>/members/<member-id>: googleapi: Error 403: Request rate higher than configured., quotaExceeded
with googleworkspace_group_member.workspace_agent_subnet_network_user["primary"]
on modules/google-shared-vpc-access/main.tf line 59, in resource "googleworkspace_group_member" "workspace_agent_subnet_network_user":
resource "googleworkspace_group_member" "workspace_agent_subnet_network_user" {

Panic Output

N/A

Expected Behavior

The provider should have retried with an exponential backoff per the Directory API docs.

Actual Behavior

The error above occurred when a number of concurrent plans were run.

Steps to Reproduce

Probably not super straightforward to reproduce, but:

1. Have a large number of googleworkspace_group_member
2. terraform apply
3. terraform plan a couple times in parallel?

Important Factoids

I'm not sure whether to file this as a bug or a feature request, but since it directly results in an error, I went with bug.

Our Terraform configuration is written to be as loosely-coupled as possible, which prevents us from using [1] in this particular case.

The google provider has a retryTransport [2] that they use for retrying when API errors occur, and they have predicates for deciding when to retry, e.g. this predicate retries on certain quota exceeded errors:

https://github.com/hashicorp/terraform-provider-google/blob/45c08236ce7c0f2a09a6af989952a13e54a604ca/google/error_retry_predicates.go#L220-L229

Perhaps that could be used here, to retry on quota issues with API calls to admin.googleapis.com?

The google provider also implements batching [3], which can reduce the number of API calls being made. Could that also be used here when many googleworkspace_group_member resources (or other applicable resources in this provider) exist?

References

[1] #147
[2] https://github.com/hashicorp/terraform-provider-google/blob/b72600acfb51e3e278eb2558c98608c7d16fbf2c/google/retry_transport.go
[3] https://github.com/hashicorp/terraform-provider-google/blob/45c08236ce7c0f2a09a6af989952a13e54a604ca/google/batcher.go

Hi,

When a user has been deleted, our entire plan fails due to the group_member resource still being in state:

Error: googleapi: Error 404: Resource Not Found: 1040763465893, notFound

I understand why, but until these groups are fully adopted into our JML process, this breaks the terraform plan for all other groups / users. It's not easy to identify which user this is, either.

We have identified the failed user, however the plan still errors due to that user being in state, and it attempts to refresh the resource. This breaks our whole pipeline, for cases where the user is removed prior to the group being updated. We cannot manage users in this same workflow. Is there a way to prevent this? I've had to remove the group member resource from state to fix this.

Expected Behavior

https://registry.terraform.io/providers/hashicorp/googleworkspace/latest/docs should contain an upgrade guide with instructions on how to upgrade from DeviaVir/gsuite now that https://github.com/DeviaVir/terraform-provider-gsuite is deprecated and tells people to migrate to this new provider.

Actual Behavior

Unable to find any such instructions or tips on the old or new provider pages.

Thanks for the awesome repository.
I would like to request a support for Google Drive sharing setting described in the following link.
I understand this is new provider; but is the request going to be part of the scope in this repository?

https://support.google.com/a/answer/6085538?hl=ja&ref_topic=2498056&visit_id=637610376070912723-257858886&rd=1

Hi, thanks for all the work on this provider, I am just starting out a POC to get this enrolled and it's already a big improvement over the previous unofficial provider.

Security groups are currently in beta, and are set by applying labels to the group:

https://workspaceupdates.googleblog.com/2020/09/security-groups-beta.html

Can this provider be extended to allow group labels?

Add functionality to manage domain aliases (resource and data source)

resource "googleworkspace_domain_alias" "alias" {
  parent_domain_name = "my-domain.com"
  domain_alias_name = "my-alias.com"
}

DomainAliases: https://developers.google.com/admin-sdk/directory/reference/rest/v1/domainAliases

It'd be nice to create RoleAssignments so we can add admin roles to service accounts as explained here: hashicorp/terraform-provider-google#6704 (comment)

This would likely require a data source for roles as well.

Something like

data "googleworkspace_roles" "roles" {
  customer_id = "Cust0123id"
  filter {
    name = "items.role_name"
    value = "_GROUPS_ADMIN_ROLE"
  }
}

data "google_service_account" "my-sa" {
  account_id = "my-service-account"
}

resource "googleworkspace_role_assignment" "group_admin" {
  customer_id = "Cust0123id"
  assigned_to  = google_service_account.my-sa.unique_id
  role_id = gsuite_roles.0.role_id
  scope_type = "customer" 
}

Roles: https://developers.google.com/admin-sdk/directory/reference/rest/v1/roles
RoleAssignements: https://developers.google.com/admin-sdk/directory/reference/rest/v1/roleAssignments

Terraform Version

$ terraform version
Terraform v1.0.10
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v3.90.0
+ provider registry.terraform.io/hashicorp/googleworkspace v0.5.1
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/tfe v0.26.1

Affected Resource(s)

Please list the resources as a list, for example:

• googleworkspace_group_member

Terraform Configuration Files

terraform.tf:

terraform {
  # ...

  required_providers {
    # ...

    googleworkspace = {
      source  = "hashicorp/googleworkspace"
      version = "~> 0.5.1"
    }

    # ...
  }

  # ...
}

.terraform.lock.hcl:

# ...

provider "registry.terraform.io/hashicorp/googleworkspace" {
  version     = "0.5.1"
  constraints = "~> 0.5.1"
  hashes = [
    "h1:belNSaJyP+pdsV9KLdAaJREpd593rqH20E0rD0dAqjU=",
    "zh:057243cacca422ccafe8b6655a756533ece84cce36d6f0ecf630ca6687b7bfff",
    "zh:3afd8f46b10efa73b0b03156f0e1e3c45d2e61b45ca10ba4d6c7232ca382e38f",
    "zh:3be5066848e7dc98ba65134b6c3d94d3e756cde94c874d1ede70f8ce7378cc1f",
    "zh:457ba88ec2a931b1be6e8f09da60be6cb3cb2c430ecbfc7148a16245c8cdb4bf",
    "zh:4a8293a70788eeccbedc9a1185203079239ff7afdde5fcf2b672e7fe42cb5ce4",
    "zh:610486fe93e582a2d07574c275ee6b265030fc980b0c2128e49bf5f626d4bc5e",
    "zh:b211c32212c1bd2c4ff428a24e87ef708d21ce5affd6d9de3de1e598203c8dd0",
    "zh:babee5ceb865208e747e4ae95905ef6e3c7b8102cf9cacf2c2abbfe881bca0d2",
    "zh:d644524f2e80dbaef9c135b36ddba98ab82cad81c7ac9a1435ca89e20102dbb7",
    "zh:db19c927f9b55520e61ad97f03cb7059466603de28e0794297e3b88926de075a",
    "zh:fb0af5e8252227875c92216106f3b8000452d891dec02ce18d898733f2a603e6",
  ]
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

• When creating a googleworkspace_group_member, it won't fail due to eventual consistency (#186)
• When re-creating a googleworkspace_group_member after an eventual consistency error, it won't fail because the member already exists (#194)

Actual Behavior

• Error: googleapi: Error 404: Resource Not Found, notFound
  with googleworkspace_group_member.workspace_agent_shared_vpc_network_viewer
  on modules/google-shared-vpc-access/main.tf line 44, in resource "googleworkspace_group_member" "workspace_agent_shared_vpc_network_viewer":
  

• Error: googleapi: Error 409: Member already exists., duplicate
  with googleworkspace_group_member.workspace_agent_shared_vpc_network_viewer
  on modules/google-shared-vpc-access/main.tf line 44, in resource "googleworkspace_group_member" "workspace_agent_shared_vpc_network_viewer":
  

Steps to Reproduce

1. terraform apply
2. Get 404 error.
3. Run terraform apply again
4. Get 409 error.

Important Factoids

I've pasted the .terraform.lock.hcl and terraform.tf files in the Terraform Configuration Files section, so I'm relatively confident that this is using the latest version (0.5.1), barring some bug in Terraform Cloud. Is it possible the binary uploaded to the Terraform Registry does not include the fixes noted in the changelog?

References

Hi!

With Dynamic groups being GA - we'd love to be able to use them, but that would require us to be able to automate them properly.

Are there plans to support dynamic groups and their CEL queries in this TF provider?

Thanks

Hi there,

I'm new to Terraform, I'm trying to figure out a way to update/modify resources (googleworkspace_user) that were created before Terraform was configured, but couldn't find any way to do that. And although I believe what I'm trying to do is either incorrect or not supported at this moment (give the provider was released recently, I decided to try it anyway. Hoping I would get some insight by subsequent error messages. But I ended up with this rather generic error message that doesn't tell me what's going on.

│ Error: Get "https://admin.googleapis.com/admin/directory/v1/users/meeseeks%40grozer.in?alt=json&prettyPrint=false": dial tcp: lookup admin.googleapis.com on 0.0.0.0:53: read udp 127.0.0.1:55005->127.0.0.1:53: read: connection refused
│
│   with data.googleworkspace_user.mee,
│   on gipl-offboard.tf line 28, in data "googleworkspace_user" "mee":
│   28: data "googleworkspace_user" "mee" {
│
╵

Terraform Version

Terraform v1.0.1
on darwin_amd64
+ provider registry.terraform.io/hashicorp/googleworkspace v0.2.0

Your version of Terraform is out of date! The latest version
is 1.0.2. You can update by downloading from https://www.terraform.io/downloads.html

What I tried to do

• Tried to change the field suspended from true to false for a user

Expected Behavior

User status should have been deactivated in Workplace

Actual Behavior

│ Error: Get "https://admin.googleapis.com/admin/directory/v1/users/meeseeks%40grozer.in?alt=json&prettyPrint=false": dial tcp: lookup admin.googleapis.com on 0.0.0.0:53: read udp 127.0.0.1:55005->127.0.0.1:53: read: connection refused
│
│   with data.googleworkspace_user.mee,
│   on gipl-offboard.tf line 28, in data "googleworkspace_user" "mee":
│   28: data "googleworkspace_user" "mee" {
│
╵

FYI the response from the api endpoint for group membership https://developers.google.com/admin-sdk/directory/v1/guides/manage-group-members#get_all_members, is paged. You seem to be retrieving only the first page.

Add functionality to retrieve chrome policy schema/s (datasource/s) / (GET|LIST)

resource "googleworkspace_chrome_policy_schema" "device-enrollment" {
  name = "chrome.user.DeviceEnrollment"
}

resource "googleworkspace_chrome_policies" "enrollment-schemas" {
  filter = "enrollment"
}

ChromePolicy: https://developers.google.com/chrome/policy/reference/rest/v1/customers.policySchemas
More Information:

• https://developers.google.com/chrome/policy/guides/policy-schemas
• https://developers.google.com/chrome/policy/guides/samples_policyapi

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

terraform 1.0.0
provider version 0.4.0

Affected Resource(s)

• google_workspace.user

Debug Output

(irrelevant and sensitive bits removed)

2021-08-08T12:19:00.920+0300 [INFO]  provider.terraform-provider-googleworkspace_v0.4.0_x5: 2021/08/08 12:19:00 [DEBUG] Google Workspace API Request Details:                   
---[ REQUEST ]---------------------------------------                                                                                                                           
POST /admin/directory/v1/users?alt=json&prettyPrint=false HTTP/1.1

...
 "emails": [                                        
  {                                                 
   "address": "[email protected]",              
   "primary": false,                                
   "type": "work"                                   
  },                                                
  {                                                 
   "address": "[email protected]",                  
   "primary": true,                                 
   "type": ""                                       
  },                                                
  {                                                 
   "address": "[email protected]",
   "primary": false,                                
   "type": ""                                       
  }                                                 
 ],                                                 
...
"organizations": [                    
 {                                    
  "department": "",                   
  "description": "censored",
  "domain": "",                       
  "fullTimeEquivalent": 0,            
  "location": "",                     
  "name": "",                         
  "primary": true,                    
  "symbol": "",                       
  "title": "censored",
  "type": ""                          
 }                                    
],
...

Expected Behavior

User created successfully

Actual Behavior

│ Error: googleapi: Error 400: Invalid value for:  is not a valid value, invalid
│ 
│   with googleworkspace_user.example,
│   on provider_googleworkspace_users.tf line 11, in resource "googleworkspace_user" "example":
│   11: resource "googleworkspace_user" "example" {

which, to me, seems like the API is complaining about an empty string.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Attempt to create a new user, leaving fields null
2. The provider substitutes an empty string instead of removing the fields from the request

Hi Google Workspace terraform team,

I love your provider and I'm happy to have it.

I'm using googleworkspace_group_members to add a google Service Account to a group.

• GOOD : The adding works well. We can find the SA in the group (IAM --> Groups --> group details)
• BUG : However, the field "type" seem blank in group description (IAM --> Groups --> group details)
• BUG : Using policy troubleshooter (IAM --> Policy troublehsooter) the SA doesn't have permission of the gorup

Expected behavior

• Adding a Service Acount to a group should give it the permissions of the group. Exactly the way it is in the web interface.

Hi there,

It would be nice to be able to get the all users from the directory optionally based on search criterions. It's necessary to make provisioning of related systems based on Google Workspace user directory.
At the moment data googleworkspace_group_members might considered to be used but it returns only membership related info, without any user details e.g. name, custom schemas fields etc.

BTW: This provider is awesome! Great job 👍 .

Cheers!
W