Skip to content
MoltaroMoltaroMoltaro Docs

Entity access policies

Every Entity Definition uses Security Statements assigned to Permissions. View is the root permission for every record: without a valid View assignment, the record type is locked. Actions such as update, archive, restore, import, export, comments, attachments, and tags refine View; they never replace it.

Field permissions refine the same decision. Field:Read controls projection, search, reference previews, and display dependencies. Field:CreateWrite and Field:Write are separate permissions for supplied create values and changed existing values. A denied field is omitted from the response rather than returned as a null placeholder.

Responsibilities connect users or Responsibility Groups to one record through stable responsibility keys. Assignment Rules decide who may Add, Replace, or Close those assignments. Role, user, responsibility, record fields, references, and the captured workspace clock are available to the Security Statement DSL.

Moltaro applies the View SQL predicate before search, filtering, sorting, count, and pagination. Owner and Admin receive no implicit record access. Administration access never substitutes for Entity record Permissions.

The same PostgreSQL authorization path is used for one-record details, forms, available actions, field projection, imports, mutations, and background processing. Create and update validate the uncommitted database state inside the command transaction. Moltaro does not preload reference or collection graphs into application memory to decide access.

Configure Entity Security

Section titled “Configure Entity Security”

Open an Entity Definition and use the three entries under Security. This is separate from calculated Entity Statements:

  • Responsibilities defines responsible subjects, initial assignment, and who may add, replace, or close assignments;
  • Access Policies manages one reusable condition together with every exact Permission it grants. The guided editor and DSL mode both create the same canonical Security Statement and Permission Assignments;
  • Permissions shows explicit field refinements and inherited field access. Ordinary fields inherit root access; add an explicit refinement only when a field needs a narrower allow-list. Board transition coverage is shown only in the corresponding Board security profile.

Policy changes are reviewed as a server Plan and applied atomically. Multiple Security Statements assigned to the same Permission use OR semantics. Expert users can still open Raw configuration — Advanced for immediately effective Statement and Assignment changes; those changes invalidate any existing Plan.

Upgrading from the legacy Entity access model is a breaking change. Old grants, field rules, assignments, and inheritance state are not migrated. Back up the workspace, configure every used definition through these three sections, and verify representative users before reopening production. Restoring the pre-upgrade database backup is the only rollback boundary.