# 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:

```jadpo
// policy.jadpo
policy {
    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](field-restrictions.md) and
[tenancy](tenancy.md) 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`.