Control each operation
Reading a record, changing it, deleting it, executing an action, and linking it can carry different permission bits.
Permissions and tenancy
Make access rules part of the application.
Decide who can read, create, update, delete, execute, or refer to data. Apply those decisions to tables, individual records, relationships, and actions.
- Guest
- Owner
- Group
One access model
Rules follow the data.
Daptin evaluates operation-specific permissions for guests, authenticated users, owners, and groups. That gives a product room for public content, private records, team spaces, and administrator-only operations without scattering checks across handlers.
Start broad, narrow where needed
Use table defaults, then assign record-level ownership or group access for the cases that differ.
Build team and workspace boundaries
Ownership, groups, and checked relationships support common multi-user product structures.
Changes take effect in the running system
Permission-cache invalidation prevents old decisions from living indefinitely after access is changed.
Product access patterns
Move from public content to private workspaces without changing authorization systems.
Public catalogue
Let guests discover and read published records while only operators create, change, or remove them.
Private account data
Open the table to signed-in users while owner bits keep each person's rows inaccessible to unrelated accounts.
Shared workspace
Use group membership for team records and Refer permission to stop users linking objects they cannot legitimately use.
Privileged operation
Allow people to read an object without automatically granting execution of every backend action attached to it.
The important distinction
Table access and row access solve different problems.
A group may need permission to reach a resource type while individual rows remain owner-only. Daptin keeps the table gate, record permission, relationship permission, and action permission distinct so opening one layer does not silently open the others.
Changing a default affects newly created records; existing rows retain their stored permission until migrated. Test the matrix with ordinary users, not only an administrator.
Open the permission test guide →Product evidence
Inspect rules, then test them with real accounts.
The dashboard makes the configured permission surface visible, but configuration alone is not proof. Test every relevant operation as guest, owner, group member, unrelated user, and administrator, and preserve expected denials as regression tests.
Configure and test access →