Data security

Model (may I run this operation?), relation (may I go through this field?) and row (may I access this object?). How the levels apply one after another.

Which role an operation requires: base role, role per action, endpoint role, public access. PATCH uses the update role.

The API path /audit/question becomes audit-question, and that becomes audit-question-read. The rule shown with examples.

A field role on a relation allows reading or writing a child model through exactly one field, without direct access to the child model. On simple fields a role works differently: as an additional condition.

A role on a simple field protects a single value. Whoever does not hold it does not see the field, cannot change it and cannot search by it. The model itself stays readable.

A text field with the rule "encrypted" is stored encrypted in the database and comes back decrypted. What you configure for it, how a key change works and what the field cannot do.

In user models every person sees only their own rows. How _userId is set and checked.

An attribute of the person (e.g. projects) restricts a data field. How EQ/IN is formed, what * means, what happens when the attribute is missing and what applies to people with several tenants.

How a project adds its own visibility rules and why a mandatory filter that cannot be resolved aborts the request instead of silently disappearing.

An object you may not see does not exist from the caller's point of view. This also applies to changing and deleting: you can only write what you can read.

Whether a request that is not allowed returns an error or is silently trimmed. Where this applies and why strict is the default.

What a request without a token can reach: open paths, endpoints without a role, and how an invalid token is handled.