Page MenuHomePhabricator

Allow applications to provide custom policy rules
Closed, ResolvedPublic

Description

Currently, custom policies can only use global rules like "users", "members of project", etc.

This prevents creating a default edit rule for tasks like "the task author, or administrators". However, there shouldn't be any technical reason that we can't support and evaluate "the task author" as a rule, because we always know (or always can know) what kind of object a policy is being applied to, and policy rules are already pluggable.

This probably doesn't have a huge amount of general purpose utility, but would allow installs to effectively build more custom policy behaviors without needing patches or hacks.

Related Objects

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Policy.
epriestley added a subscriber: epriestley.

This requires some changes to the policy framework, but I think nothing too severe:

  • PhabricatorPolicyRule needs to know about the object the rule is being applied to. Currently, it only knows about the viewer. However, it appears trivial to thread the object through to the rule application.
  • PhabricatorPolicyRule needs to have methods like canApplyToObject($object) to allow rules to activate when applied to tasks and deactivate when applied to other types of objects.
  • PhabricatorPolicyEditController needs to be passed the type of object it is editing policies for (probably a PHID?)
  • AphrontFormPolicyControl needs to be passed this information so it can pass it to the EditController.
  • Application policies probably need some additional config.
qgil added a subscriber: qgil.Jul 22 2014, 2:17 PM
mikaye added a subscriber: mikaye.Jul 22 2014, 2:21 PM
chad added a subscriber: chad.Nov 4 2014, 3:13 AM
Krenair added a subscriber: Krenair.Jan 3 2015, 6:17 PM
eadler added a subscriber: eadler.

In case it's helpful: Here's a real-world use case: custom policy rule I wrote to allow "Subscribers of this task" WMFSubscribersPolicyRule

It requires this nasty hack to fill in the task id because I couldn't find any way to get the task id inside of applyRule unless it was hard coded as the rule parameter. So the rule ends up being "Subscribers of task Tnnn" instead of "Subscribers of $this task" with $this being inferred at runtime.

We want this for T8488 and it's probably a component in moving T8434 forward.

@20after4, D13252 changes the signature of two methods in PhabricatorPolicyRule:

  • willApplyRules() now takes array $objects.
  • applyRule() now takes PhabricatorPolicyInterface $object.

Old rules will need method signatures updated, but will otherwise work the same way they currently do without requiring additional changes.

epriestley added a revision: Restricted Differential Revision.Jun 11 2015, 7:55 PM
epriestley closed this task as Resolved.Jun 13 2015, 10:50 PM

This now works, and the upstream has implementations for the reasonable-seeming use cases we've seen, particularly the policy that blocks T8488. This is relatively modular and extensible, but I don't think there are any other problems for it to solve right now.

(T6860 is slightly more general; this laid the groundwork for that but can't solve the Passphrase problem on its own.)

epriestley added a commit: Restricted Diffusion Commit.Jun 14 2015, 1:55 PM

@epriestley: thanks for the heads up

urzds added a subscriber: urzds.Jul 12 2017, 11:13 AM