Hi fml2,

thanks for raising this!

We will have a look at it as soon as possible and update the ticket with any feedback we have.

Best,
Tobias

Hi fml2,

thanks again for bringing this up.

Please note that we have derived from using one general class holding all possible permissions for all resources with https://jira.camunda.com/browse/CAM-9548 and all of its related tickets.
Instead, each resource now holds its own set of permissions.
Therefore, fetching the permissions in your last step should also happen with the specific set of permissions of that resource.

Specifically, you would have to replace

var permList = List.of(auth.getPermissions(Permissions.values()));

with

var permList = List.of(auth.getPermissions(UserOperationLogCategoryPermissions.values()));

Doing so will consider all permissions available for the OPERATION_LOG_CATEGORY when checking which of those the specific authorization contains.

Using the Permissions values for the PROCESS_DEFINITION works (at least for the READ permission) because the PROCESS_DEFINITION is listed in the supported resources in the Permissions#READ enum value.
The OPERATION_LOG_CATEGORY is not, therefore, it doesn't return that permission in your case.
Those resource lists are not maintained anymore. Specific resources can and do define specific permissions (like SET in SystemPermissions) that are not covered in the general Permissions at all.
Therefore, using the Permissions values can yield incomplete results here and there, no matter if the resource lists are maintained or not.

Thus, using the resource-specific set of permissions is the way to go here.

Hope that helps,
Tobias

Hello Tobias,

thank you for the good explanation! Could you then explain why there is the method with this signature and not just a getter {{authorization.getPermission() }}(without parameters)?

The way it is now one has to know what Enum type represents the possible permission values for the authorization (effectively, the resource type). Why was the existing method created in such a weird (IMO) way?

Thank you!

Hi fml2,

Why is the method signature as it is?
The authorization itself doesn't store all possible permissions the related resource has. It just stores a set of given permissions.
An authorization instance might basically come from anywhere, so we'd want to check against our backend's known permissions for the related resource to verify which permissions in our system the authorization enables.
Therefore, we need to hand in our known set of all permissions we want to check against.

How has it become a bit more inconvenient to use?
At the time this method was created, it was fairly simple to use since we usually used our Permissions class that held all known permissions for all resources.
When we changed the permissions to be defined per resource, this became a bit more inconvenient to use.

What can you do about it?
There is an internal helper with ResourceTypeUtil::getPermissionsByResourceType that you can use here.
We use it as well to determine which permissions a user has at a certain point in time in combination with an authorization entity.

Let me know if that helps here.

Best,
Tobias

Hello Tobias,

thank you for the detailed explanation! In the meantime, I've come up with something like the ResourceTypeUtil class and created a helper method getPermission(authorization). It first finds out the permission type (and all its values) for the auth object and then calls auth.getPermission(...). Had I known about the ResourceTypeUtil class...

The ticket can be closed. Thank you again for your support.

Hey fml2,

sorry for not pointing that class out earlier.
Happy you have a working solution though

Best,
Tobias