Page MenuHomePhabricator

Apply hierarchical policy checks to Phriction

Authored by epriestley on May 19 2014, 2:31 PM.



Ref T4029. When checking the view policy of a document, require the viewer to also be able to see all of the ancestors.

Test Plan
  • Hard-coded /x/y/ to "no one".
    • Checked that /x/y/ is not visible.
    • Checked that /x/y/z/ is not visible.
    • Checked that /x/, /x/q/, etc., are still visible.
  • Tested project pages and sub-pages for project visibility.

Diff Detail

rP Phabricator
Lint Skipped
Tests Skipped

Event Timeline

epriestley retitled this revision from to Apply hierarchical policy checks to Phriction.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
btrahan edited edge metadata.

It would be cool if

  • when creating a new wiki document it defaulted to the most-restrictive applicable policy based on ancestors
  • when editing a wiki document it was apparent what the most-visible policy possible is given ancestor policies
  • changes to policies that could not be enforced - making a child document public in a restricted ancestor hierarchy - loudly gave error messages and possibly prompted the user on how to solve corner cases ("Because Phriction enforces wiki policy hierarchically, you should make a new document outside this hierarchy. Consider a 'public' folder just below the top-most node." ...or something...)

...taking a step back, maybe the policy UI for Phriction needs to be different. You are in essence adding an additional constraint or constraints to the existing set specified by the hierarchy. Ergo, perhaps something that clearly displayed the existing set as read-only and then let you add new policy constraint(s) via the existing-ish UI?


that must have worked well

This revision is now accepted and ready to land.May 19 2014, 7:16 PM
epriestley updated this revision to Diff 21861.

Closed by commit rP9cb4047134f5 (authored by @epriestley).