Actions

Most actions need no permission of their own: an action takes its permission from the entities it touches. Root policy.jadpo lists the few that can't, under actions::

• an action that touches no entity, such as an operator's health report, which is otherwise refused;
• an action that needs different people from its entity's grants, such as handing a todo to someone else, or creating a company together with its first owner's membership.

Each line names an action by its domain and name, and lists who may run it, with the same kinds of entry as a grant:

// policy.jadpopolicy {    tenant: Company    actions: {        todos.transfer_todo: [Todo.owner_id]        accounts.create_company: [Access.authenticated]        monitoring.health_report: [StaffRole.operator]    }}

Todo.owner_id means the current owner of the todo the action changes. For that action, the listed people replace the entity grants on what it reaches. Field restrictions and tenancy still apply.

Calling an integration, an outside service such as a payment provider, needs nothing extra: permission to run the action covers it.

Lines that depend on a record

A user field such as Todo.owner_id, or a role held in a record such as CompanyRole.owner, is checked on the records the action itself creates, changes or deletes. On an action that changes none of them, such as a report, it lets nobody in. The action is then checked as it starts against the line's other entries: anyone signed in, or a role held across the whole application. With none left, it refuses every caller, so its route is policy.effect_ungranted.