Set Up Role-Based Access

This tutorial walks through creating a Contributor role that can create and edit their own content but cannot delete or manage users.

Concepts

Concept	Description
Role	A named group assigned to users
Policy	A permission rule set attached to a role
Permissions	Collection-level + field-level access rules

Create the Contributor role

Go to Roles under the Access section in the sidebar and click Add Role:

Name: Contributor
Description: Can read all content and create/edit their own posts

Create a policy for the role

Navigate to Policies and click Add Policy:

Name: Contributor Policy

Then open the Contributor role detail page, go to its Policies tab, and attach the Contributor Policy.

Set collection permissions

On the Contributor Policy detail page, scroll to the permissions table (inline — there is no separate tab). For the posts collection:

Action	Setting
Read	All items
Create	Allowed
Update	Filter: `{ "user_created": { "_eq": "$CURRENT_USER" } }`
Delete	Not allowed

This lets contributors update only posts they created.

Restrict field access

Still in the permissions table, click the R badge on the posts Read permission row to open its detail modal, then go to the Fields tab and deselect sensitive fields:

Uncheck user_created if you don’t want contributors to see creator IDs of other items

Next, add a separate Read permission row for the daas_users collection on the same policy. In its Fields tab, expose only id, first_name, last_name, avatar — not email or password fields.

Assign the role to a user

Go to Roles, open the Contributor role’s detail page, switch to the Users tab, and add the user there.

Testing Permissions

Create a second user with the Contributor role and test the API:


# Login as Contributor
curl -X POST https://your-domain.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"contributor@example.com","password":"password"}'
 
# Try to delete another user's post — should return 403
curl -X DELETE https://your-domain.com/api/items/posts/1 \
  -H "Authorization: Bearer <token>"

Next Steps

Attach multiple policies to one role — field access merges with OR logic, so users gain the union of all allowed fields across their policies
Use $CURRENT_ROLES or $CURRENT_POLICIES as dynamic variables in item filters to scope access based on a user’s assigned roles or policies
Enable Delegate Access on a policy to allow server-to-server requests that act on behalf of a user via the X-On-Behalf-Of header