See PHI1313. Currently, if you can edit parent project A, you can edit subproject B.

This rule is old and not clearly explained in the UI. It's also not entirely intuitive and not how Phriction works.

The "bad" case we get into if we drop this rule is:

• you own project A;
• you get locked out of subproject B;
• whoever owns subproject B can indirectly manage membership of A without your consent/involvement by adding members to B, since the members of A are the members of all subprojects of A.

In other similar cases with hierarchical permissions (Phriction, the filesystem), editing a child object generally can not affect ancestors, so this kind of case doesn't come up very often.

I think this is not really such a bad case, and probably not likely to happen in practice or cause many real problems. On the balance, we may be losing more clarity by having permissions cascade like this (which is at least somewhat unintuitive) than we're getting by avoiding this weird edge case. The current model is also less powerful than dropping this rule, since you can always emulate the current model if this rule is removed but can not escalate privileges for a subproject with this rule in place.

A practical example is maybe something like this:

- Engineering
  - Security Engineering

It's reasonable to want "Security Engineering" to be locked down more tightly than "Engineering", and to let, say, HR manage subprojects of "Engineering" but not let them add members to "Security Engineering" without approval.

Practical steps for this are probably:

• Communicate our intent to change this in a future release, since this is an unusually significant change to policy behavior.
• Remove the rule.
• Update documentation, and probably implement PolicyCodex to modernize how projects interact with the policy explanation UI.