Permissions & Approvals

Minerva secures data using a team-based access model with three layers working together:

Route permissions
Field redaction
Approvals and locks

Role-Based Access Control (RBAC)

Access is granted by mapping a Team to a specific collection route.

If a user belongs to multiple teams, Minerva takes the superset of those teams’ access.

Granular Control

1. Row-Level Conditions

Permission filters are modeled as structured field/operator/value conditions. CEL is used when the value must come from request context or another computed source.

2. Attribute-Level Redaction

If a field is blocked for a user:

It is not selected on reads
It is removed from tables
Dynamic UI nodes referencing it are replaced with a redacted placeholder
It is stripped from submitted payloads

3. App and Page Redaction

Users only receive the apps and pages they are allowed to access. Navigation visibility is driven by the server, not just the client.

The Permission Layer Pipeline

When a user attempts a mutation:

Minerva evaluates team permissions
Evaluates conditions
Checks whether approval is required
Returns a 202 Accepted flow when approval must be created instead of writing directly

Task Access

Task access is simpler:

Admins can see all tasks unless impersonating
Non-admins can see tasks assigned directly to them
Non-admins can also see tasks assigned to their teams

Linked record access is still enforced separately from task visibility.