Page MenuHomePhabricator

Policy explanations for some extended policy objects with "open" default policy plus constraints are misleading
Open, WishlistPublic


Some objects, like PaymentMethods, effectively enforce all their policies with ExtendedPolicyInterface. Their default policy is usually PhabricatorPolicies::getMostOpenPolicy().

At runtime, the check is "you must be any user AND you must be able to do something specific". This is an accurate policy check, so the overall behavior is correct.

However, the UI tends to render things like this:

Any user at all can see this super secret object!
However, as an exception to this rule, you also must be a member of the elite cabal to see the object.

This case, where the default policy is very open and the exception adds constraints, is misleading and unintuitive.

The cleanest fix here is probably to let these objects return something like null or POLICY_EXTENDED from getPolicy() to mean "only the extended policies for this object are relevant in evaluating and communicating policy rules". If an object returns null from getPolicy() and also returns no extended policies, that would be an error so we could still fail safe/closed.

Event Timeline

epriestley triaged this task as Wishlist priority.Aug 16 2019, 5:04 PM
epriestley created this task.

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:

You Shall Not Pass: Object A
<Description of policies for object B.>

Although this tends to result in a technically true explanation, it's not as clear as it could be.

In T13493, PhabricatorExternalAccountIdentifier could also benefit from this null policy behavior.