Changing the display_name of an azuread_group forces replacement when it should instead update the existing group's name

[hingst]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureAD Provider) Version

Terraform v1.0.5
on linux_amd64
+ provider registry.terraform.io/hashicorp/azuread v1.6.0

Affected Resource(s)

• azuread_group

Terraform Configuration Files

Step 1:

terraform {
  required_providers {
    azuread = {
      source = "hashicorp/azuread"
      version = "1.6.0"
    }
  }
}

resource "azuread_group" "test" {
  display_name = "test1"
}

Step 2:

terraform {
  required_providers {
    azuread = {
      source = "hashicorp/azuread"
      version = "1.6.0"
    }
  }
}

resource "azuread_group" "test" {
  display_name = "test2" # changed only the display_name
}

Expected Behavior

When changing the display_name of an azuread_group, the name of the existing group should be updated.

Actual Behavior

The provider forces the group to be destroyed and a new one to be created.

Steps to Reproduce

1. Use config from step 1
2. terraform apply
3. Update config to step 2
4. terraform apply

References

I'm aware that this behavior is documented, but it makes no sense to me. The Graph API allows changing group names, so why does the provider force replacement? I'm not sure about the legacy AAD API, but use_microsoft_graph = true does not change the behavior, so I assume it's by design.

• Is this considered a bug?
• If not, why not?
• Would a PR to change this behavior be accepted?

[manicminer]

Hi @hingst, thanks for reporting this. You are correct, displayName is not immutable with the MS Graph API. However, when supporting both MS Graph and AAD Graph, as is the case with v1.5 through v1.6 of the provider, the schema has to represent the most restrictive scenario - this is a Terraform semantic as the schema cannot be dynamic depending on the upstream API in use.

This is actually fixed in v2.0 (release pending, see #476) as is the description property (see #240). As such I'm going to close this for now since the correct behavior is already implemented, it just hasn't been released yet. For the reason above, we will unfortunately be unable to backport this to v1.x.

[github-actions]

This functionality has been released in v2.0.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.