sonarqube permissions issue

[hamid-rsh]

Hi, I have some issues using the sonarqube_permissions. On the first run, everything seems to be OK and working, but after removing the resource (and also when changing permissions), the provider throw error. It seems that group with permissions API returns global permissions

• applicationcreator
• portfoliocreator

Even in the sonar dashboard, the return result for the API includes these 2 permissions, I think it's better to hard code the available options for the permissions. This is the API that being called in the SonarQube: api/permissions/groups?projectKey=sample_project&ps=100 And the result is:

{
    "paging": {
        "pageIndex": 1,
        "pageSize": 100,
        "total": 10
    },
    "groups": [
        {
            "id": "Anyone",
            "name": "Anyone",
            "permissions": [],
            "managed": false
        },
        {
            "id": "..........",
            "name": "sonar-administrators",
            "description": "System administrators",
            "permissions": [
                "applicationcreator",
                "codeviewer",
                "issueadmin",
                "portfoliocreator",
                "scan",
                "securityhotspotadmin",
                "user"
            ],
            "managed": false
        },
    ]
}

Terraform Version

Version 1.4.5

Provider Version

Version 0.16.8

SonarQube Version

Docker image tag 10.2.1-community

Affected Resource(s)

Please list the resources as a list, for example:

• sonarqube_permissions

Terraform Configuration Files

resource "sonarqube_permissions" "sonar_permission_for_admins" {
    group_name  = "sonar-administrators"
    project_key = "sample_project"
    permissions = sort(["admin", "codeviewer", "issueadmin", "securityhotspotadmin" , "scan", "user"])
}

Expected Behavior

Successfully remove permissions

Actual Behavior

Error:

│ Error: error creating Sonarqube permission: API returned an error: Invalid project permission 'applicationcreator'. Valid values are [admin, codeviewer, issueadmin, securityhotspotadmin, scan, user]

Changes detected:

-/+ resource "sonarqube_permissions" "sonar_permission_for_admins" {
      ~ id          = "e123744d-8f57-4659-e043-e45zz7zz3z9z" -> (known after apply)
      ~ permissions = [ # forces replacement
          - "applicationcreator",
          + "admin",
            "codeviewer",
            "issueadmin",
          - "portfoliocreator",
            "scan",
            # (2 unchanged elements hidden)
        ]
        # (2 unchanged attributes hidden)
    }

State data:

    {
      "module": "............",
      "mode": "managed",
      "type": "sonarqube_permissions",
      "name": "sonar_permission_for_admins",
      "provider": "provider[\"registry.terraform.io/jdamata/sonarqube\"]",
      "instances": [
        {
          "index_key": 0,
          "schema_version": 0,
          "attributes": {
            "group_name": "sonar-administrators",
            "id": "e123744d-8f57-4659-e043-e45zz7zz3z9z",
            "login_name": null,
            "permissions": [
              "admin",
              "applicationcreator",
              "codeviewer",
              "issueadmin",
              "portfoliocreator",
              "scan",
              "securityhotspotadmin",
              "user"
            ],
            "project_key": "sample_project",
            "template_id": null,
            "template_name": null
          },
        }
      ]
    },

Steps to Reproduce

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

1. terraform apply

[tbutler-qontigo]

Hi @hamid-rsh What version of SonarQube are you using? I'm pretty sure applications and portfolios are not available in the Community edition so it may well be that you are using a version that does not support such features. If that is the case then hardcoding permissions would not be a good solution IMO since it would affect users with those features. Or am I missing something?

[hamid-rsh]

Hi @hamid-rsh What version of SonarQube are you using? I'm pretty sure applications and portfolios are not available in the Community edition so it may well be that you are using a version that does not support such features. If that is the case then hardcoding permissions would not be a good solution IMO since it would affect users with those features. Or am I missing something?

Thanks for reply, I mentioned the versions, I'm using the 10.2.1-community version. the problem is that the API api/permissions/groups?projectKey=sample_project&ps=100 response includes the features that are not in the community version, and they're not being displayed in the panel itself. As you can see in the terraform code, these are the permissions that I put in the code: sort(["admin", "codeviewer", "issueadmin", "securityhotspotadmin" , "scan", "user"]) but after terraform apply, the permissions in the state are:

        "permissions": [
          "admin",
          "applicationcreator",
          "codeviewer",
          "issueadmin",
          "portfoliocreator",
          "scan",
          "securityhotspotadmin",
          "user"
        ],

[tbutler-qontigo]

Sorry I didn't see that you had mentioned the version. Ok so as I mentioned earlier, hard coding permissions does not seem like a good solution because it would probably affect people on other editions...and of course if Sonar changed the permissions then the provider would need a different hard coded list to accomodate. Can you think of a solution that does not involve hard coding and indeed perhaps submit a PR for the repo maintainer to review?

[nimdeveloper]

@tbutler-qontigo, please check the PR and tell me what you think. this is the way that SonarQube Frontend handles the permissions list in the UI

[tbutler-qontigo]

Hi @nimdeveloper - it is not up to me as @jdamata is the repo maintainer. Personally I think hard coded permissions make the provider more fragile and if you are relying on the order then that doubles down on fragility... And I would prefer to see some tests that this will actually work for all versions of Sonar But as I say, it is up to the repo maintainer to approve or otherwise - I am just an occasional contributor with opinions :}

[nimdeveloper]

Hi @nimdeveloper - it is not up to me as @jdamata is the repo maintainer. Personally I think hard coded permissions make the provider more fragile and if you are relying on the order then that doubles down on fragility... And I would prefer to see some tests that this will actually work for all versions of Sonar But as I say, it is up to the repo maintainer to approve or otherwise - I am just an occasional contributor with opinions :}

I understand, but this is how SonarQube handles it on the front. I couldn't find the API endpoints that return the permissions based on the conditions. Also, I think this is a sonar issue, as this endpoint shouldn't return those permissions on that endpoint (based on the API documentation).

[jdamata]

I agree with @tbutler-qontigo that we should try not to hardcode these lists to prevent having to be in sync with sonarqube. It would be a headache to maintain in the future.

Im trying to think of something we can do to get around sonarqubes weirdness here.

[nimdeveloper]

I agree with @tbutler-qontigo that we should try not to hardcode these lists to prevent having to be in sync with sonarqube. It would be a headache to maintain in the future.

Im trying to think of something we can do to get around sonarqubes weirdness here.

This is so weird. It seems to be a problem with the Sonarqube itself. The problem is that the Default Permission template itself includes wrong permissions.