Show and enforce the permission hierarchy in all five editors

Featurekamo-internal
Ya
14 Agosti 2026, 21:26 UTC
Mwandishi
kamo
Ahadi ya
4e82e18

Five editors granted 199 rights as five flat lists of checkboxes, and none of them showed that one right can be a prerequisite for another. Granting a child without its parent looked exactly like granting a working permission — which is how the Legal & Compliance tab needed two rights and no editor could say so. RightsTree renders the tree: indentation with a connector spine, collapsible branches, a granted/total pill per branch, search that keeps a match's ancestors visible, and a cascade that is animated because the animation is what teaches the rule — enabling a child lights up what it depends on, disabling a parent dims its subtree, both with an undo toast naming exactly what moved. Honours prefers-reduced-motion. It also stops lying about three states the editors could never express: rights locked by the org's security model, granted-but-inert legacy rows whose parent is denied, and the 58 rights that are grantable but gate nothing anywhere. An admin could not previously tell a real permission from a placeholder. The cascade rules live in app/lib/rightsHierarchy.ts, mirrored from Java's RoleRightType. A copy of a security rule is a liability, so the parity test reads the Java source and fails on any divergence rather than trusting convention. The branch-types template editor gets the ordering and indentation but keeps its own control and does NOT auto-cascade: those are FORCE values, absolute and applied after every level, so cascading them would silently rewrite a deliberate override. The parent relation is still enforced there at resolution time. Design + the reproducible audit: docs/superpowers/specs/

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei