jdamata / terraform-provider-sonarqube

Terraform provider for managing Sonarqube configuration
GNU General Public License v3.0
62 stars 54 forks source link

BUG: sonarqube_permissions for groups #97

Closed tbutler-qontigo closed 1 year ago

tbutler-qontigo commented 1 year ago

The stripPermissions method in resource_sonarqube_permissions_go explicitly removes applicationcreator and portfoliocreator.

This causes a problem when trying to set group permissions that include them.

Terraform Version

1.3.2

Affected Resource(s)

sonarqube_permissions

Terraform Configuration Files


resource "sonarqube_group" "my_admin_group" {
  name        = "MyAdministrators"
  description = "My Administrators."
}

resource "sonarqube_permissions" "my_admin_group_permissions" {
  group_name  = sonarqube_group.my_admin_group.name
 permissions =  ["admin","applicationcreator", "gateadmin", "portfoliocreator", "profileadmin", "provisioning"]
}

Expected Behavior

The permissions are set on first terraform apply and are unchanged on subsequent calls

Actual Behavior

Every call to terraform plan or terraform apply after the initial setup decides that my_admin_group_permissions needs to be updated.

Terraform will perform the following actions:

  # sonarqube_permissions.my_admin_group_permissions must be replaced
-/+ resource "sonarqube_permissions" "my_admin_group_permissions" {
      ~ id          = "37fa3e90-b42e-4e3e-8485-d81f6e7f1c66" -> (known after apply)
      ~ permissions = [ # forces replacement
            "admin",
          + "applicationcreator",
            "gateadmin",
          + "portfoliocreator",
            "profileadmin",
            # (1 unchanged element hidden)
        ]
        # (1 unchanged attribute hidden)
    }

Steps to Reproduce

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

  1. terraform apply using the two resources I listed earlier
  2. terraform apply again

I believe this is because when terraform comes to check if the resource needs to be updated or not, because stripPermissions strips out some permissions, it thinks that the permission list is 2 shorter than it actually is...which does not match with the .tf file => the resource needs to be updated. And this will happen evey time because the two permissions are always removed.

I am unsure of the circumstance under which it makes sense to remove those two permissions but it seems not to be appropriate in the case where the caller is supplying only the group_name and permissions list

fhusson commented 1 year ago

There is a comment in the code : // The endpoint api/permissions/groups return also the non template permissions this messes with state of the permissions // To make sure these don't interfere the extra permissions are ignored

Maybe it was a mistake because Application are available with the Developer Edition and the Portofolio in the Enterprise Edition.

jdamata commented 1 year ago

@fhusson thank you for the pr!! I will push out v0.15.1 with this change