Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-10237

Permissions are returned by the REST API in an inconsistent way

    • Icon: Bug Report Bug Report
    • Resolution: Won't Fix
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • engine, webapp
    • None

      *Given*
      A GRANT authorization with only NONE permission is created (via REST API or Admin).

      *When*
      I request the authorization via REST API.

      *Then*
      I receive an authorization with an empty permission array.

      Background:

      • In the AuthorizationEntity we always set NONE as the baseline default for permissions via resetPermissions() when we create/update an authorization. If NONE or an empty array is passed to the Java API for the authorization's permissions, we save the NONE's value (=0) to the database.
      • On request from the REST API we always translate the permission bit mask to names, removing NONE from the list of permissions in the org.camunda.bpm.engine.impl.util.PermissionConverter.getNamesForPermissions().
      • In the Webapps, we interpret an empty permission array of the AuthorizationDto as a NONE permission.
      • In the user operation log, we interpret an empty permission array as a NONE permission (see CAM-10188).

      Expected behavior:

      • If NONE is provided as a permission, I should receive it as well when I request it (if no permission is provided and we treat this as NONE in the backend, we could make that transparent by returning NONE as well).
      • If NONE is chosen by a user in Admin, send it to the backend as well (an empty array of permissions is sent right now).
      • If all permissions are chosen, ALL is sent to the backend (not every single permission) and received upon request, the same should happen for NONE respectively.

        This is the controller panel for Smart Panels app

            [CAM-10237] Permissions are returned by the REST API in an inconsistent way

            We are closing this ticket as part of our backlog grooming. Reasons:

            • We did not receive sufficient evidence that this ticket is important

            Thorben Lindhauer added a comment - We are closing this ticket as part of our backlog grooming. Reasons: We did not receive sufficient evidence that this ticket is important

              Unassigned Unassigned
              tobias.metzke Tobias Metzke-Bernstein
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: