Get User Roles
Reads every permission role a user is currently in, from inside a cloud function. Cloud-only and read-only — nothing is written.
Get User Roles answers 'what is this account allowed to do' without making a change to find out. Roles comes from the same resolver a permission rule's role: check evaluates, so this cannot answer member while a rule disagrees — it is the actual check, not a second opinion on it. unchanged fires (rather than done with an empty array) when the user is in no roles at all, because that is the branch a membership check actually wants to take, and an empty array arriving on a done wire is easy to mistake for a port nobody connected.
When to use it
Whenever a cloud function needs to decide something based on what a user is allowed to do — gating a branch on role:staff, showing a different response to a pro subscriber, or verifying a role grant actually took before reporting success to the caller. Also the honest way to check 'did Add User To Role actually work' without trusting its own report.
At a glance
| Category | Cloud |
| Type name | noodl.cloud.getuserroles |
| Available in | cloud |
| SSR compatibility | — |
| Provided by | noodl-viewer-cloud |
Inputs
Values
| Name | Type | Default | Description |
|---|---|---|---|
treatUnchangedAs | Enum (unchanged, done, failure) | unchanged | What this node reports when the action was valid and there was nothing to do. Unchanged (the default) keeps it a third outcome of its own. Done suits a project whose chains should carry on either way; Failure suits one whose idiom is that a no-op is a bug. Completed fires whatever this is set to. |
userId | String | — | Object id of the account to act on, usually wired from Create User or a Request parameter; blank is a Failure rather than a fallback to whoever called the function |
Signals
| Name | Type | Default | Description |
|---|---|---|---|
read | Signal | — | Reads the roles this user is in |
Outputs
Values
| Name | Type | Default | Description |
|---|---|---|---|
roles | Array | — | Every role this user is in once the operation has finished, read back through the same resolver the access check itself uses |
Signals
| Name | Type | Default | Description |
|---|---|---|---|
completed | Signal | — | Fires after every invocation, whatever the outcome — wire this to carry on regardless. Failure still fires and still carries its reason, so this cannot hide an error |
done | Signal | — | Fires once Roles holds every role this user is in |
unchanged | Signal | — | Fires when the user is in no roles at all, which is the branch a membership check wants |
Failure outputs
| Name | Type | Default | Description |
|---|---|---|---|
error | String | — | Why the last operation could not be performed |
failure | Signal | — | Fires when the roles could not be read — a blank User Id, or a user id nothing resolves |
Patterns
- Read this after Add User To Role or Remove User From Role to confirm the membership actually changed, rather than trusting the mutation's own Done — useful when a function's response needs to report the account's current role set, not just that one operation succeeded.
Watch out for
- Re-deriving 'is this user staff' from a cached copy of Roles taken earlier in a long-running function instead of reading it fresh — roles can change between the start of a function and a later branch inside it.
Related nodes
Add User To Role, Remove User From Role
This page is generated from node-catalog-enriched.json. Do not edit it by hand — run npm run docs:nodes to regenerate, and fix the source enrichment instead.