Ref T4029. When checking the view policy of a document, require the viewer to also be able to see all of the ancestors.
Details
Details
- Reviewers
btrahan - Maniphest Tasks
- T4029: Support policies on Phriction wiki articles
- Commits
- Restricted Diffusion Commit
rP9cb4047134f5: Apply hierarchical policy checks to Phriction
- 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
Diff Detail
- Repository
- rP Phabricator
- Branch
- phriction2
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 572 Build 572: [Placeholder Plan] Wait for 30 Seconds
Event Timeline
Comment Actions
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?
| src/applications/phriction/controller/PhrictionDocumentController.php | ||
|---|---|---|
| 121 | that must have worked well | |