First production use of actionCreateContext — the second aggregator
introduced in step 1 and unit-tested at the building-block level, but
not yet exercised against a real caller. Helper file stays 0-diff for
the sixth consecutive migration.
The migration uncovers one real API gap and resolves it at the policy
layer rather than at the helper:
* actionCreateContext always calls actionEnforceCanViewPage. The
Departments create-decision was the only Departments authorize
branch that did not emit can_view_page (View and EditContext both
did). Adding 'can_view_page' => true to the create-capabilities
map is tautological — every actor that survives the deny() guards
at lines 69-70 and 75-76 can by definition see the page. No new
forbidden path is created. View, Create, and EditContext now share
the same capability shape.
Three drift decisions reproduced where applicable:
* notFoundFlashScopeKey is N/A (no model lookup in create flow).
* t() consistency: all three Flash::success('Department created', …)
calls now flow through t().
* Defensive scope consumption: $canManageAllTenants reads
$tenantScope['scope'] === 'all', mirroring the edit-action pattern.
The GET tenant filter rewrites from is_array($allowedTenantIds) to
the three-way scope-tuple form.
AuthzAdminMasterDataContractTest gets a single-line assertion update
(AuthorizationService::class → actionCreateContext() pattern). The
aggregator wraps the same authorize call internally, so this is a
pattern-rename, not a semantic shift.
ActionContextCsrfPairingContractTest now covers six callers (five
edits + departments-create) and stays green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fs
d6be536fbf