Skip to main content
This guide provides practical code snippets demonstrating the permission system in action. These snippets show how to create users, tenants, roles, and datasets, and how to manage permissions effectively.
Complete snippets — All code snippets are complete and runnable, showing the full workflow from setup to permission management.
Users are the foundation of the permission system. Here’s how to create a new user:
Tenants group users together and can receive permissions. Create a tenant with an owner:
Add existing users to a tenant. Only the tenant owner can add users:
Roles provide permission groups within a tenant. Create a role for the tenant:
Datasets are the core data containers. Create a dataset with automatic permissions for the creator:
Grant specific permissions to principals. Give read access to a user:
Each call grants exactly one permission name, so write a separate call per permission. Give comprehensive access:
The four valid permission_name values are "read", "write", "delete", and "share". Passing any other value raises PermissionNotFoundError.
The most common pattern: the creator gets full control, a teammate gets read-only access.create_authorized_dataset automatically grants the creator all four permissions (read, write, delete, share) on the new dataset — no extra calls are needed for the owner. To share with another user, call give_permission_on_dataset once per permission you want to grant.
To upgrade the collaborator to read + write later, grant "write" as a separate call — it does not replace the existing "read" grant:
Use revoke_permission_on_dataset to remove a specific permission later.
give_permission_on_dataset is insert-only and idempotent. Calling it again with the same (principal, dataset_id, permission_name) does not create a duplicate ACL row, does not bump updated_at, and does not raise — the existing row is left as-is.
This means it is safe to re-run grant logic on startup or in setup scripts. It also means it cannot be used to “change” a permission — if user2 already has read and you want them to have write instead, you must explicitly revoke read and grant write. See the revoke_permission_on_dataset function in ACL.
Query what datasets a user can access. Check permissions by type:
Set up a complete permission scenario from scratch. This example shows the full workflow:
Demonstrate how permissions flow through the hierarchy. Show tenant and role inheritance:
Create organization with multiple teams:
Grant temporary access to external contractor:
Allow teams to collaborate on shared datasets:
Follow these best practices for permission management:
  • Start simple — Begin with basic user and dataset creation
  • Use roles for teams — Create roles for different job functions
  • Grant tenant permissions — Use tenant-level permissions for organization-wide access
  • Regular audits — Periodically review and update permissions
  • Document access patterns — Keep clear records of who has access to what
  • Test permission changes — Verify permissions work as expected after changes

Setup Configuration

Learn how to configure the permission system

API Reference

Explore permission system API endpoints