v6.16.0

Added

• PII reveal capabilities ffc_view_certificates_pii and ffc_view_appointments_pii (#739) — carve the decrypted CPF / RF / email out of the plain view tier, mirroring recruitment. A shared 3-tier resolver (Core\PiiAccessPolicy) grants unmasked plaintext to the domain _admin role (and WP super-admins), an audited reveal tier to holders of the _pii cap and to the record's owner, and masked to everyone else. The caps ship on the manager + new _admin tiers; the certificates/appointments ladders gain their fourth (_admin) tier.
• Read-only capabilities ffc_view_forms and ffc_view_calendars (#739) — the só vê tier for the certificate-form and self-scheduling-calendar structures, completing the 3-state model on both CPT surfaces (the view tier deferred from the CPT-decoupling PR). A holder now sees the forms/calendars list read-only; a new map_meta_cap gate forces every per-post edit/delete on those CPTs to the matching manage cap, so viewing never implies editing.
• Hue×tier visual system on the capability editors (#739) — the role editor and the per-user capability panel now paint each capability row with a left accent bar: its colour marks the domain (certificates, forms, appointments, calendars, audiences, …) and its intensity rises with the capability's write-power (view faint → manage strong → delete solid), with the domain hue also carried on the group header. The colour reinforces the existing textual label; the mapping lives in CapabilityCatalog::group_hue() / ::cap_tier().

Changed

• ⚠ Breaking (RBAC redesign, #739): WordPress administrators now receive FFC access through the dedicated FFC Administrator role (ffc_administrator) instead of the plugin's capabilities being granted onto the native administrator role. On upgrade every existing administrator is automatically given the role, so no access is lost; administrators created afterwards are granted it explicitly (on the user-edit screen, by any admin) — they are no longer auto-elevated. The per-user FFC role panel now appears for administrators so the aggregator role can be assigned to them.
• ⚠ Breaking (RBAC redesign, #739): the form (ffc_form) and calendar (ffc_self_scheduling) post types are decoupled from WordPress's native post capabilities. Form structure is now gated by the new ffc_manage_forms capability and calendar structure by the new ffc_manage_calendars capability (distinct from ffc_manage_appointments, which governs the bookings). Previously a plain WordPress Editor could administer every form and calendar via edit_others_posts without holding any FFC capability.
• ⚠ Breaking (RBAC redesign, #739): capability and role slugs were renamed for a consistent taxonomy. Capability: ffc_scheduling_bypass → ffc_bypass_appointments. Roles: ffc_operator → ffc_readonly, ffc_self_scheduling_manager → ffc_appointments_manager, the auto-assigned end-user role ffc_user → ffc_end_user (label FFC End User), plus the §3.2 taxonomy alignment: ffc_certificate_manager → ffc_certificates_manager, ffc_audience_manager → ffc_audiences_manager, and ffc_recruitment_auditor → ffc_recruitment_viewer. One-shot upgrade migrations rewrite every affected grant on both users (user_meta) and role definitions and reassign users onto the renamed roles, so no access is lost on upgrade. External integrations referencing the old slugs must update — the old names no longer resolve after the migration runs.
• Graduated roles (RBAC redesign, #739): every admin domain now ships a uniform viewer → operator → manager role ladder instead of a single per-domain manager, reusing the capabilities that already exist. operator adds the domain's primary action to the read-only viewer (certificates +edit, appointments +bypass, audiences +import, reregistration +export, recruitment +call); manager is the full domain cap set; the global FFC Administrator role tops every ladder. New roles: the viewer/operator tiers for certificates, appointments, audiences and reregistration, ffc_recruitment_operator, and viewer/manager pairs for the two CPT domains (forms, calendars).

Deprecated

• WordPress Editors (holders of edit_others_posts) can still manage FFC forms and calendars during a two-release compatibility window, with an admin notice, but this stops in 6.18.0. Grant the FFC Administrator role — or the form/calendar management capability — to the users who need it. (#739)

Fixed

• Form/calendar CPT menus hidden for every capability holder (#739): the ffc_form and ffc_self_scheduling post types mapped the per-post meta caps read_post / edit_post / delete_post to the same strings used for their primitive caps (ffc_view_forms / ffc_manage_forms / ffc_view_calendars / ffc_manage_calendars). WordPress's _post_type_meta_capabilities() copies every read_post / edit_post / delete_post value into the global $post_type_meta_caps, registering those strings as meta-cap aliases — so a plain current_user_can( 'ffc_view_forms' ) (the admin-menu check) was rerouted through map_meta_cap() to read_post and, with no post ID in a menu context, collapsed to do_not_allow. The result: the "Todos os Formulários" / "Adicionar Novo" / "Calendários Pessoais" menus were hidden even for the FFC Administrator role that explicitly holds the caps. The CPTs now map only their primitive caps; per-post edit/delete stays gated by CptCapPolicy, which forces the write meta-caps to the manage cap on the map_meta_cap filter.
• Capability-map hygiene (#739): a defensive, version-flagged migration (strip_false_ffc_caps()) removes any stale ffc_* => false denial from the FFC-managed roles, and upgrade_role() was hardened to strip 0 / '' denials (not only a strict false), so a future multi-role user can't have an admin-granted cap masked by a legacy explicit denial on a peer role.
• Authorization consistency (#739): the migration-runner AJAX endpoint now requires the ffc_manage_settings_dangerzone sub-cap, matching its no-JS counterparts — a settings operator without the dangerzone cap could previously run destructive migrations through the AJAX runner.
• Audience delegation (#739): the audience booking, schedule-slot, environment and user-permission AJAX actions now accept ffc_manage_audiences (administrator or the granular cap) instead of requiring manage_options, so the FFC Audience Manager role can actually use the interactive screens it is meant to delegate.
• Ticket generation authorization (#739): the ffc_generate_tickets AJAX handler now requires the certificates domain cap (ffc_manage_certificates, administrator or the granular cap) instead of the generic edit_posts any WordPress author holds.
• Email sub-cap alignment (#739): the "send a test email" action now requires ffc_manage_settings_smtp (it exercises the SMTP transport), and the global "disable all emails" kill-switch now requires ffc_manage_settings_dangerzone on every write path (bulk settings save + the per-field autosave endpoint) — a settings operator without those sub-caps can no longer test SMTP or silence all plugin email.
• URL-shortener QR download (#739): the PNG / SVG QR download now accepts the url-shortener manage cap as well as view (administrator or either granular cap), so a manager role that doesn't separately carry the view cap can still download QR codes.
• Recruitment read tier (#739): the recruitment REST read endpoints (candidates list/get, notices, classifications and adjutancies lists) now accept ffc_view_recruitment as well as ffc_manage_recruitment, reactivating the read-only viewer tier that was defined but never wired. PII in those responses stays masked via RecruitmentPiiAccessPolicy (reveal remains per-field + audited), and every write route stays manage-gated.
• Recruitment candidate email on the edit page (#739): the candidate edit page decrypted the email into an editable field for every recruitment manager. It is now masked and disabled for operators below the unmasked PII tier, and handle_save() gates the email write on the loaded row's tier — so a manager without ffc_view_recruitment_pii can neither read the plaintext nor overwrite/clear the stored address (even by forging the field). Editing the email requires the unmasked tier (WP admin / domain admin).