Return a single role with its granted permissions in plain language and the resources shared to it, so you can explain what a user may see and do — and why.
Return a single role with the permissions behind it, in plain language.This is how you explain what someone can and cannot do, and why: reach for it
when a user does not see something they expect, or to answer who is allowed to
perform an action. Feed it the id from any user row’s role (list_users,
get_user, get_identity), or from list_roles.The permissions are rendered as grants, not as the raw matrix — a category
the role is denied is left out, and inside an allowed one a yes-or-no
permission the role does not hold is left out too. An absence is therefore
meaningful: a category missing from the result is one the role cannot reach,
which is often the answer to “why can’t this user see X”. The org-chart scope
on statements, requests and commission letters is what decides whose records
the role sees, independently of those grants.shared_resources is the other half of the picture: resources shared with the
role individually, which reach past its category permissions. A role denied a
whole category can still read specific resources through a share, so read the
two together. Sharing is a live-environment concept, so those are the live
ones.
This tool needs the company-settings roles permission (READ on the Role
company setting).
The role’s permissions, one entry per category it is allowed at all. A
denied category is omitted entirely, so a category absent from this list is
one the role cannot reach — that absence is the answer to “why can’t this
user see X”.
Coded permission category — one section of the role’s matrix, matching a
section of the Qobra app. One of: statement, request, report,
commission_letter, plan, quota, user, data_table,
company_setting, audit_trail, sandbox.
How far the category reaches across the org chart, for the categories
that have such a setting (statements, requests, commission letters):
all every user’s, users_below the holder’s own plus their reports’,
me their own only, no_access none at all — the category page opens
but shows nothing. Null for a category with no org-chart scope. One of:
all, users_below, me, no_access.
What the role is granted inside this category. Only grants are listed:
a yes-or-no permission the role does not hold is absent, so an empty
list on a category that has sub-permissions means access to the page
and nothing more. The request category has no sub-permissions at all —
its scope is the whole grant.
Coded sub-permission. A value repeats across categories with a
different meaning (role is the Roles settings page under
company_setting, a user’s assigned role under user), so read it
together with the category it sits in.
What the role may do, in the web app’s own wording — ‘Can view’ /
‘Can edit’ / ‘Can edit and delete’ for a graded permission, an
action phrase such as ‘Can lock’ for a yes-or-no one.
Resources shared with this role individually, on top of what permissions
grants by category. This is the other half of the answer to ‘why can this
user see X’: a role denied a category can still reach specific resources
through a share. Empty when nothing is shared with the role. Live
environment only.
The level this share grants the role on this resource specifically —
read (view it), write (edit and re-share it) or delete (also
remove it), each level including the ones before it. One of: read,
write, delete.
Was this page helpful?
Assistant
Responses are generated using AI and may contain mistakes.
