Add http endpoint to list permissions

[butonic]

This PR adds an http endpoint to list permission names.

Can be tested with curl:

curl -X POST 'https://cloud.ocis.test/api/v0/settings/permissions-list' -u admin:admin -k --data '{"account_uuid":"some-admin-user-id-0000-000000000000"}' | jq

will return a 200 Ok:

{
  "permissions": [
    "create-space",
    "delete-all-spaces",
    "settings-management",
    "account-management",
    "group-management",
    "set-space-quota",
    "change-logo",
    "role-management",
    "language-readwrite",
    "list-all-spaces",
    "delete-all-home-spaces"
  ]
}

curl -X POST 'https://cloud.ocis.test/api/v0/settings/permissions-list' -u marie:radioactivity -k --data '{"account_uuid":"f7fbf8c8-139b-4376-b307-cf0a8c2d0d9c"}' | jq

will return a 200 Ok like:

{
  "permissions": [
    "language-readwrite",
    "self-management",
    "create-space"
  ]
}

Trying to look up the permissons of a user other than the currently logged in user:

curl -X POST 'https://cloud.ocis.test/api/v0/settings/permissions-list' -u marie:radioactivity -k --data '{"account_uuid":"some-admin-user-id-0000-000000000000"}' | jq

will give a 404 with json body

{
  "code": 404,
  "detail": "user not found: some-admin-user-id-0000-000000000000",
  "status": "Not Found"
}

even for administrators, as I want to keep this minimal.

Now, we could polish this, eg:

• return a parseable json error ... but none of the settings apis seem to do that anyway ...
• allow admins to look up othe users permissions, but currently there is no reason to do that not needed
• return permissions as {"permissionid": "name"} map, but I think that does not any value, especially since permissions might be added dynamically not needed
• extract the handler into the permissions package
• tests?

Good so far?

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[butonic]

we agreed to implement listing permissions instead ...

[kulmann]

{
  "permissions": [
    "create-space",
    "delete-all-spaces",
    "settings-management",
    "account-management",
    "group-management",
    "set-space-quota",
    "change-logo",
    "role-management",
    "language-readwrite",
    "list-all-spaces",
    "delete-all-home-spaces"
  ]
}

Perfect! That's exactly what we need for web.

Regarding some of your optional todos:

• allow admins to look up othe users permissions, but currently there is no reason to do that

Agree to not do this. Web ui needs the role in the admin settings app. Permissions are only needed for the authenticated user to do permission checks. No need to do more at the moment.

• return permissions as {"permissionid": "name"} map, but I think that does not any value, especially since permissions might be added dynamically

Permission ids are not relevant for web. Checking permissions by name is sufficient and also provides better developer experience (code readability wise).

Good so far?

YES! Thank you! ❤️

cc @JammingBen

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
6 Code Smells

66.7% Coverage
0.8% Duplication