Policy
Policy says who may do what to which stored records. Each entity, a kind of stored record such as a todo, lists who may create, read, change and delete its records. The compiler applies those lists to every read and write your code makes, so you never write a permission check yourself.
This todo may be created, read, changed and deleted only by its owner:
// domains/todos/entities/todo.jadpoentity Todo { id: Uuid owner_id: User.id { on_delete: OnDelete.restricted } title: TodoTitle policy: { create: [owner_id] read: [owner_id] update: [owner_id] delete: [owner_id] }}
owner_id is a reference to a User, so the person it points to is the
one let in. A caller no list names is refused, and a todo they may not
read behaves as if it didn't exist (When policy says no).
Each entry in a list names who it lets in, in one of four ways:
| Who | Written | Lets in |
|---|---|---|
| A user field on the record | owner_id |
the user that field points to |
| A membership role | CompanyRole.editor |
a user with that role in the record's company |
| Anyone signed in, or anyone | Access.authenticated, Access.public |
anyone signed in; anyone at all |
| Background work | Access.system |
schedules and subscribers, limited to the tenant their event came from |
When your app is shared by many customer companies, Tenancy keeps each company's records to its own members, whatever the lists say.
Markdown for agents: /docs/policy.md.Built from Jadpo main at a707efb.