realm_attributes is not updating when terraform config changes

[richardmcsong]

Describe the bug When the LDAP realm_attributes string is updated on the artifactory_group resource, the plan reports that the realm string will be updated, but the realm string is not actually updated.

resource "artifactory_group" "example" {
  name = "example"
  realm = "ldap"
  realm_attributes = "ldapGroupName=example_team;groupsStrategy=DYNAMIC;groupDn=CN=EXAMPLE_TEAM,OU=some,OU=organizational,OU=unit,DC=example,DC=com"
}

Apply, then edit the realm_attribute string.

Expected behavior Th edit should be persisted on the end server. Instead, the edit is not completed, and then it calculates the same edit on the next run.

Additional context Artifactory version: 7.90.8 provider version = "~> 11.0" terraform version = terraform 1.8.4

Findings When trying to PATCH an LDAP group, it doesn't actually allow for you to update realm_attributes, despite what the documentation says: Updates an Access group's external ID, realm, or realm attributes.

$ curl -vvv -H "Authorization: Bearer $(jf atc | jq -r .access_token)" -XPATCH -d '{"realm_attributes": "<new-string>"}' https://artifactory.example.com/access/api/v2/groups/example_group
{
  "name" : "example_group",
  "auto_join" : false,
  "admin_privileges" : false,
  "realm" : "ldap",
  "realm_attributes" : "<original-string>",
  "members" : [ ]
}

A GET request after confirms that the realm_attributes was not edited.

[richardmcsong]

I thought about destroy then recreate, but this actually can't work for me. deleting the group will invalidate:

• group scoped access tokens (not a huge deal)
• group membership will start from empty again, and as users sign in, they get added to the group.
  • this is huge because LDAP sync only happens on user login, and there is no custom API call to trigger an LDAP sync on demand (feature request here: https://jfrog.atlassian.net/browse/RTFACT-30616). For many of our automation cases, we have an admin account generate access tokens on their behalf.
  • As a workaround, we login once during provisioning to trigger an initial sync. To recreate these groups would mean a mass login event over all users to trigger the sync per each user, which is an untenable solution in our environment.