Permissions & roles

WP-PFManagement has a two-layer permission system: WordPress capabilities for admin access, and a custom Roles/Groups system for fine-grained data access control.

WordPress capabilities

Capability	What it controls
`pfm_admin`	Full access — bypasses all per-entity/per-field/per-action gates
`pfm_manage_entities`	Create, update, delete entities and fields
`pfm_design_forms`	Design form layouts
`pfm_view_records`	View records
`pfm_create_records`	Create records
`pfm_edit_records`	Edit records
`pfm_delete_records`	Delete records
`pfm_fire_events`	Fire events

All capabilities are auto-granted to Administrators. Users with manage_options also inherit all PFM capabilities as a fallback.

PFM Roles system

Beyond WordPress caps, PFM has its own fine-grained roles:

Role	Purpose
`admin`	Bypasses all permission gates
`schema_manager`	Access Schema Manager, Templates, Navigation, Actions
`data_reader`	Fallback for empty entity `can_read_roles`
`data_writer`	Fallback for empty entity create/write/delete roles
`public` (META)	Opens any gate to anyone, including anonymous visitors
`authenticated` (META)	Opens any gate to any logged-in WordPress user

Groups

Groups collect users and assign them roles:

Users belong to Groups
Groups carry Roles
The synthetic __wp_administrators group is auto-created and gives all WP admins the admin role

Entity-level permissions

Each entity has per-CRUD role columns:

can_read_roles — who can read records
can_create_roles — who can create records
can_write_roles — who can edit records
can_delete_roles — who can delete records

Empty = fallback to data_reader (read) or data_writer (write). Add public to open access to everyone; authenticated for logged-in users only.

Field-level permissions

Each field can have its own can_read_roles and can_write_roles. If empty, the field inherits from its entity. On record updates, each touched field is individually checked for write permission.