Cluster-7 batch-replay of the departments-create pilot (step 9). All
three remaining create actions follow the same shape with minor
domain-specific variations.
Each migration touches one action and one policy:
* roles-create + RoleAuthorizationPolicy::authorizeAdminRolesCreate —
policy previously returned bare allow() with no capabilities; now
emits ['can_view_page' => true]. Action passes viewAuthFlags: [].
* permissions-create + PermissionAuthorizationPolicy::authorizeAdminPermissionsCreate —
same pattern as roles-create.
* tenants-create + TenantAuthorizationPolicy::authorizeAdminTenantsCreate —
policy already emitted can_manage_sso + can_manage_custom_fields;
can_view_page is added as the first capability. Action passes
viewAuthFlags: ['can_manage_sso', 'can_manage_custom_fields'] and
materializes both booleans from the aggregator capabilities.
All three policy updates are tautological — every actor that survives
the deny() branches in each policy can by definition see the page.
View, Create, and EditContext now share a consistent capability shape
across all four core master-data domains (departments, roles,
permissions, tenants).
Three drift decisions reproduced:
* notFoundFlashScopeKey is N/A (no model lookup in create flows).
* t() consistency: Flash::success('Role created' / 'Permission created'
/ 'Tenant created') now flow through t().
* Defensive scope consumption: $canManageAllTenants reads
$tenantScope['scope'] === 'all' as a resilient hook even where the
policy emits no manage-all flag (roles/permissions are global,
tenants-create has no filter logic). Inline comments document the
intentional non-consumption of $tenantScope['ids'].
Two contract-test pattern updates (AuthzAdminMasterDataContractTest +
AuthzAdminTenantsContractTest) shift the assertion targets from
AuthorizationService::class to actionCreateContext( — semantically
equivalent because the aggregator wraps the same authorize call
internally.
ActionContextCsrfPairingContractTest now covers nine callers
(five edits + four creates) and stays green. Helper file
core/Support/helpers/action_context.php is 0-diff for the seventh
consecutive migration.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
