Access policies for content within Phabricator.
Tue, Sep 1
Probably related: According to https://phabricator.wikimedia.org/T261642, it seems that when leaving a project, phabricator leaves behind some cruft in the form of materialized memberships for milestones of that project.
Jun 5 2020
Spaces have been working great for my install. The only real place where they're lacking I think arises from their coarseness/mutual-exclusivity.
Feb 20 2020
In T13493, PhabricatorExternalAccountIdentifier could also benefit from this null policy behavior.
Feb 3 2020
Jan 17 2020
Jan 16 2020
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: