OptionalDashboardWidgets

Corex\Config\Notifications\OptionalDashboardWidgets · class · Config layer

The optional, opt-in Dashboard widgets (spec 072 US7, T024). The Command Center widget is registered for everyone with CoreX visibility (FR-023). These are the opposite: nothing here appears unless the site asked for it. FR-025 sets four independent conditions, and {@see shouldRegister()} is the one place all four are decided — - opt-in: absent from the option means absent from the dashboard; - ability: each widget declares the ability it needs, checked per actor; - data: never register for an actor who can see nothing, because an empty widget takes space to say nothing and implies the actor is missing something they are simply not party to; - mode: a Development-only widget must never reach a Production dashboard. That method is pure so each rule is testable without WordPress, mirroring how LoginRouteGuard separates its decision from its hooks. Everything rendered here reuses the canonical services the full CoreX screens use — no widget queries anything for itself — and every action is a link.

Public API

`__construct(?NotificationService $notifications, ?OperationsMode $mode, ?OperationsModeStore $modeStore, ?ConfigInterface $config)`

`catalogue(): array`

The declared widgets. Each entry states the ability it needs and whether it is Development-only, so {@see shouldRegister()} has a rule to enforce for every id it accepts.

`shouldRegister(string $widgetId, bool $enabled, bool $permitted, bool $hasData, string $mode): bool`

Whether this widget may be added to the current actor’s dashboard (FR-025). Pure by design: the caller resolves the four inputs from WordPress, and every rule below can therefore fail on its own in a unit test. Unknown ids fail closed — an id with no catalogue entry has no declared ability or mode rule, so there is nothing to enforce for it.

`register(): void`

`add(): void`

WordPress owns Screen Options for anything registered here, so a user can still hide one.