Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating an existing azuread_privileged_access_group_eligibility_schedule fails #1431

Closed
EwanNoble opened this issue Jul 10, 2024 · 1 comment

Comments

@EwanNoble
Copy link

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: 1.8.5
Azure AD Provider: 2.53.1

Affected Resource(s)

  • azuread_privileged_access_group_eligibility_schedule

Terraform Configuration Files

Before:

resource "azuread_privileged_access_group_eligibility_schedule" "group_eligibility" {
  group_id             = var.group_id
  principal_id         = var.principal_id
  assignment_type      = "member"
  permanent_assignment = false
  expiration_date      = var.expiration_date
}

After:

resource "azuread_privileged_access_group_eligibility_schedule" "group_eligibility" {
  group_id             = var.group_id
  principal_id         = var.principal_id
  assignment_type      = "member"
  permanent_assignment = true
}

Expected Behavior

Properties are updated on existing resource.

Actual Behavior

Plan correctly states resource "will be updated in-place".
On apply this errors:

Error: Could not create assignment schedule request, PrivilegedAccessGroupEligibilityScheduleRequestsClient.BaseClient.Post(): unexpected status 400 with OData error: RoleAssignmentExists: The Role assignment already exists

Steps to Reproduce

Given the two HCL configurations above, first apply 'before' and then attempt to update the resource by applying the 'after' configuration.

References

I've had a brief look at the provider code and Graph documentation and I believe the issue may stem from this line:

On an update operation it is using Action = msgraph.PrivilegedAccessGroupActionAdminAssign which is the same as the Create() operation. Based on the Graph documentation here I believe this should instead be using Action = msgraph.PrivilegedAccessGroupActionAdminUpdate however I've not yet been able to test this.

@EwanNoble
Copy link
Author

I've just seen this is a duplicate of #1412 , apologies!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant