Page MenuHomePhabricator

Add a "members of all projects" (vs "...any project") custom policy rule to the upstream
ClosedPublic

Authored by epriestley on Jun 12 2018, 2:36 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 17, 6:35 AM
Unknown Object (File)
Thu, Dec 5, 5:57 PM
Unknown Object (File)
Sat, Nov 30, 4:24 AM
Unknown Object (File)
Oct 1 2024, 2:41 PM
Unknown Object (File)
Sep 6 2024, 3:28 AM
Unknown Object (File)
Aug 27 2024, 10:21 AM
Unknown Object (File)
Aug 25 2024, 12:37 PM
Unknown Object (File)
Jul 30 2024, 4:24 PM
Subscribers
None

Details

Summary

Ref T13151. See PHI702. An install is interested in a "members of all projects" (vs "members of any project", which is currently implemented) rule.

Although this is fairly niche, I think it's reasonable and doesn't have much of a maintenance cost.

This could already be implemented as an extension, but it would have to copy/paste a bunch of code.

Test Plan
  • Ran unit tests.
  • Used the UI to select this policy for a task, with various values. Joined/left projects to satisfy/fail the rule. Behavior seemed correct.
  • Used the UI to select the existing policy rule ("any project"), joined/left projects to satisfy/fail the rule. Doesn't look like I broke anything.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I'm assuming the red at the end of the diff is just cruft that got cleaned up at the same time?

This revision is now accepted and ready to land.Jun 12 2018, 6:15 PM

I put most of PhabricatorProjectsPolicyRule into PhabricatorProjectsBasePolicyRule, which caused all the red -- it moved up a level so that the "Any" and "All" logic could subclass it.

Because Policy rules use the actual class name, I had to keep PhabricatorProjectsPolicyRule named that way -- I'd rather have renamed it to PhabricatorProjectsAnyPolicyRule or similar, and then omitted Base from the base class. In modern code, we'll generally use an identifier instead of the actual class name, since we've wanted to rename classes with some frequency.

That is, we ended up here:

- PhabricatorProjectsBasePolicyRule
  - PhabricatorProjectsPolicyRule ("Any")
  - PhabricatorProjectsAllPolicyRule ("All")

Better would be this, but we'd have to migrate a bunch of JSON to get there:

- PhabricatorProjectsPolicyRule
  - PhabricatorProjectsAnyPolicyRule ("Any")
  - PhabricatorProjectsAllPolicyRule ("All")

That migration would be maybe-nice at some point, but if we do it we should get rid of "use classnames" entirely, I think, so it would be a big scope expansion over just this change.