Access policies for content within Phabricator.
Fri, Jan 17
Thu, Jan 16
Nov 19 2019
We materialize some members into the milestone? This causes no real problems, but we shouldn't materialize members into milestones.
We predict the wrong set of members for the milestone when testing policies: we predict "no members", but should predict "exactly the same as the members of the parent project"?
We check the wrong edit policy when testing if you can create a milestone: we check the default application policy, but should check the parent project policy?
Sep 12 2019
Here's the fate of the various issues discussed here:
This should be reworked some day (perhaps partly here) into some more cohesive API, perhaps newLink().
One other thing is that PhabricatorApplicationPolicyChangeTransaction->renderApplicationPolicy() has unconventional behaviors which are not very helpful and not consistent with normal CAN_EDIT / CAN_VIEW transactions. This is somewhat perplexing because ModularTransactions has renderPolicy() already, which has better behavior. I think it didn't exist yet when Applications modularized in D17757, and when it was introduced in D19829 I just overlooked the opportunity to update it.
In Applications → (Pick Something), if an application policy is set to "Custom Policy", the policy is not linked.
Sep 9 2019
Aug 16 2019
A related issue is that when object A returns object B as an extended policy check and the user fails the extended policy check, the "PolicyException" dialog is misleading. It reads like this:
Aug 2 2019
Aug 1 2019
Jun 20 2019
Jun 19 2019
See also T13317.
May 3 2019
Although I'm not entirely confident that 100% of objects which should implement ExtendedPolicyInterface actually do today, I think we've gotten pretty much all of them. This approach also seems stable.