Repository navigation
[P0][security] Role parent dead — manager-rollup unimplemented #1886
Description
Activity
- addedpriority:p0Critical: blocker, must ship before MVPCritical: blocker, must ship before MVP
on Jun 15, 2026 Triage (2026-06-27, for 11.0 epic #2364): enforcement STILL-DEAD (authoring-live only).
role.parentis shown in RolePreview butplugin-sharing/team-graph.tsexpandRoleUsersexplicitly does NOT walk a hierarchy; org rollup usessys_business_unit.parent_department_id. 11.0 action: implement manager-rollup walk or removerole.parent(breaking) and point at the BU hierarchy.11.0 resolution: REMOVE THE FEATURE (owner decision) — part of the breaking-change batch (#2364, ADR-0049). Hierarchy is delegated to
sys_business_unit(ADR-0057); manager-rollup is not implemented.Cascade (removes a feature, supersedes ADR-0056 D6):
- Remove
parentfrom the role schema (spec/src/identity/role.zod.ts) +role.form.ts plugin-sharing: gutRoleGraphService(nosys_role.parentto walk —childRoles()→[]/deprecated) ;role_and_subordinatessharing recipient degrades to plainrole— updatesys-sharing-rule.object.tsdescription- Delete/rewrite
plugin-sharing/src/role-graph.test.ts+ the hierarchy cases inrole.test.ts - Update
packages/spec/liveness/role.json(dropparent) gen:api-surface+ major changeset; changelog note (ADR-0056 D6 superseded)- Cross-repo follow-up (separate): objectui
RolePreview.tsxreadsd.parent— must drop it there too
Risk: medium-high (feature removal across spec + plugin-sharing + tests + an ADR).
- Remove
Resolved-pending-confirmation — assessment in cloud#645. The premise here is stale:
role.parentis not dead — it powers the open, explicitrole_and_subordinatessharing recipient (RoleGraphServicein plugin-sharing; used by examples + dogfood). The automatic "superior sees subordinate" permission rollup is a separate, enterprise feature, already implemented & enforced in cloud@objectstack/security-enterprise(HierarchyScopeResolver:own_and_reportsviasys_user.manager_id,unit/unit_and_belowvia BU tree; license-gated; e2e-tested) — per cloud ADR-0016 (强制免费, 治理收费). It rolls up by manager-chain / BU, notrole.parent(by design).So: keep
role.parent(open, explicit sharing); the auto-rollup is paid via manager/BU. Recommend closing this as resolved-per-ADR-0016 once the boundary is confirmed in cloud#645. Optional: a one-line docs note clarifying "manager sees reports" = enterpriseown_and_reports(or an explicitrole_and_subordinatesrule), not an automatic role grant.Closing as resolved per cloud ADR-0016 (assessment: cloud#645).
Decision: keep
role.parent— it's live in the open edition via the explicitrole_and_subordinatessharing recipient. The "superior auto-sees subordinates" permission rollup is the enterprise feature, already implemented & enforced in@objectstack/security-enterprise(own_and_reportsvia manager-chain +unit_and_belowvia BU tree), license-gated. Enforce-or-remove → enforced (enterprise) + role path stays open-explicit. No open-framework change needed.
Part of the metadata liveness audit umbrella #1878 (P0 security cluster).
Problem
Role
parentis dead.team-graph.ts:27does not walk it, so the documented "managers see subordinates' data" rollup is unimplemented. A role hierarchy authored viaparentconfers no inherited visibility — managers do not actually gain access to their reports' records.Decision required (enforce or remove)
parentso the manager-rollup (and anyrole_and_subordinatessharing recipient — see the SharingRule issue) resolves through the hierarchy.parentfromRoleSchemaif hierarchical visibility is out of scope, and remove the "managers see subordinates" claim from the docs.Evidence
docs/audits/2026-06-security-identity-property-liveness.mdteam-graph.ts:27(does not walkparent)