Invalid char in role name

[mbelang]

Provider Version 0.25.12

Terraform Version

v0.15.5

Describe the bug

When granting a role that to a role that is managed (provisioned through SCIM) outside of Snowflake, the terraform provider complains about invalid char. The role that I want to grant role is managed by Okta and we have a naming convention that contains chars that are not allowed by the terraform provider. Changing the convention is impossible without a lot of work on our side and I do not think that the provider should block certain char if the user wants to have certain chars that are accepted by the Snowflake API.

Expected behavior

The role grant or creation should work from terraform managed resources with spaces and hyphens

Code samples and commands

resource "snowflake_role_grants" "okta_admin_role_grant" {
  role_name = "APP - SNOWFLAKE ADMIN"
  roles     = ["ACCOUNTADMIN"]
}

Additional context

I do see that the validation is somewhat generic but if spaces and hyphens is accepted by the snowflake api, why would one limit it?

If the limitation apply to other apis, I suggest a specific validation char set for affected resources.

[gliptak]

The only reference to above validation function is at https://github.com/chanzuckerberg/terraform-provider-snowflake/blob/main/pkg/resources/role_grants.go#L27

name isn't even validated when role is configured https://github.com/chanzuckerberg/terraform-provider-snowflake/blob/main/pkg/resources/role.go#L15

The simple update here might be to remove above validation and let this fail in the Snowflake layer making this consistent with processing of other identifiers

[mbelang]

That makes sense to me

[bburner]

We're replicating our role names over from azure active directory. Because we have many existing groups that are already managed and governed, we cannot simply change the names of the roles to avoid these characters. This has been open for over a year now. Is it on the backlog?

[sfc-gh-asawicki]

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.