v0.1.4 — Accessible role and permission controls

Role and permission administration fragments now present native checkbox inputs as switches and show disclosure carets for expandable groups. Keyboard activation, focus indication, checked/disabled state and submitted field names follow the native controls.

Reduced-motion preferences disable control, thumb and caret transitions, including a selector-specificity defect found during the release audit. Forced-color mode restores the browser's native checkbox rendering. Hosts can customize the thumb with --rbac-switch-thumb.

Coverage includes a browser regression for keyboard interaction, reduced motion and forced colors, authenticated rendering of the actual administration fragments, the PHP policy suite and MySQL 8.4 acceptance checks. The package CI passed for the exact tagged merge commit. No database migration is needed for this update.

v0.1.3 — MySQL role migration and writes

MySQL installations can now migrate and synchronize roles. The stored system flag is a reserved MySQL identifier; unquoted migration and write statements previously failed with a SQL syntax error. The migration and repository now quote that fixed column using the PDO driver's identifier syntax.

The column name, role data and grant rules remain unchanged. Existing installations require no schema change. Coverage includes the SQLite policy suite and a real MySQL 8.4 migration/create/delete/sync regression, now run in CI. Local PHP 8.5.10 passed 50 tests with 79 assertions, formatting and strict Composer validation; main CI passed for the tagged merge commit.

v0.1.2 — RBAC sync registers after CLI boot

RBAC declares that it boots after optional naf/cli, so its sync command is registered whenever CLI is installed. The framework ignores this edge if CLI is absent.

Contributor and README guidance now point to the maintained documentation, and package CI runs the test and style checks. RBAC APIs and grants are unchanged. CI passed on the release commit.

v0.1.1 — A grant change announced as an object

A grant change is dispatched as the object it already is.

// before
event()->dispatch('rbac.granted', $moved);
event()->listen('rbac.granted', fn(GrantsChanged $g) => …);

// now
event()->dispatch($moved);
event()->listen(GrantsChanged::class, fn(GrantsChanged $g) => …);

GrantsChanged already says what this is, and naming it a second time as a string is a name that can be misspelled into a listener that never runs and never says so. A host now listens for the class, which an IDE can follow and a rename can carry.

Nothing else about the event changed: same payload, same moment, one dispatch per change as before.

Upgrading

A host listening for 'rbac.granted' stops hearing it. Change the listener to GrantsChanged::class in the same deployment — the two are separate keys and nothing warns you.

Requires naf/framework ^0.2.6, which introduced the object form of dispatch().

49 tests, 71 assertions.

v0.1.0 — Roles and permissions, held at a scope

Roles and permissions for a NAF application, scoped to whatever the application says a scope is.

The first release. What it does, and the three decisions behind it.

Grants are held at a scope

A permission is not simply held. It is held somewhere: everywhere, on every project, or on project 7. A Scope is that place, written as type:id — the empty string for the installation, project:* for every one of a kind, project:7 for one. Asking whether somebody may do something is asking at a scope, and a grant held wider covers a narrower question.

That is what lets an administrator's rights reach inside a board they were never added to, without the board having a second idea of what administration means.

A declared role is a starting point, not a standing instruction

Packages declare roles in code, and rbac:sync writes the ones that are missing. It does not rewrite the ones that are there: an installation that took a permission away from its own editor role meant it, and an upgrade must not hand it back.

The price of that rule used to be silent. A permission declared after the roles were written reaches nobody, so the feature behind it is dead on arrival and the only symptom is a button that does nothing for everybody. rbac:sync now compares the two lists it has always had and names the difference:

 6 declared role(s); nothing to add
 24 permission(s) declared across 6 group(s).
   owner is missing delete, export
   manager is missing export
 The roles above no longer carry everything their packages declare. …

It repairs nothing, which is the point: which side is right is a decision, and the installation is entitled to make it. The message names both ways out — grant it in the role editor, or rbac:sync --reapply and take the packages' word for everything.

Only declared roles are compared, and each only against its own declaration. A permission that no role carries at all is ordinary, because packages ship permissions meant for roles an installation builds itself, and counting those would bury the one line that matters.

You cannot lock yourself out

The privilege policy refuses any change that would leave nobody able to administer the system — withdrawing the last grant, deleting the last role that carries it, or removing yourself from it. The refusal names which of those it was.

What is in it

• Scope with parse(), covers() and a string form, so a scope survives being stored and read back
• Role and permission registries that packages declare into, and repositories that persist them
• rbac:sync, with --reapply for taking the packages' word and drift reporting for when you do not
• A GrantWriter that returns what moved instead of dispatching, so the service stays framework-free and the caller announces
• Screens for editing roles, shipped as assets a host publishes

49 tests, 71 assertions. PER Coding Style 3.0.

Requires

naf/framework ^0.2, naf/auth ^0.2, naf/database ^0.2, PHP 8.3, ext-pdo.