Details
- Reviewers
epriestley - Maniphest Tasks
- T4029: Support policies on Phriction wiki articles
- Commits
- Restricted Diffusion Commit
rP8a3b1b973041: Phriction - add viewPolicy and editPolicy back-end data
made sure the lone project page on my wiki had a project with restrictive view policy. Post migration verified correct policy applied to this lone project page AND most open policy applied to the others
Diff Detail
- Repository
- rP Phabricator
- Branch
- T4029
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 2990 Build 2994: [Placeholder Plan] Wait for 30 Seconds
Event Timeline
| resources/sql/autopatches/20141107.phriction.policy.1.sql | ||
|---|---|---|
| 2–6 | do I need to add these to the PhrictionDocument schema definition? | |
| src/applications/phriction/storage/PhrictionDocument.php | ||
|---|---|---|
| 70–74 | ah, i need to default the policy to something in here... will update in a min or three. | |
add code to default view policy to *something*... note this does not maintain any project automagicalness.
| resources/sql/autopatches/20141107.phriction.policy.1.sql | ||
|---|---|---|
| 2–6 | bin/storage adjust will yell at you now if you screw up, so if you aren't sure you can just run that. (If it gets it wrong, it's my fault.) You don't need them for these -- we guess default types for anything named editPolicy, viewPolicy, maybe joinPolicy, anythingID, id, anythingPHID, any serialized column, and I think in a couple of other cases where the column type unambiguously follows from convention. | |
Okay, thanks! I guess maybe I should keep going on this diff or at least not check it in right away... I'm now thinking about things like how "stub" documents need to inherit the parent doc permissions at time of create. That could live in a future diff but it should be included at the same time this functionality here lands so people don't break stuff.
Yeah, we're getting into more-dangerous territory here. I'll look at this thoroughly in a sec and yell if I can come up with any issues.
This seems good to me, but I agree that we should probably at least queue up things like stub document handling before landing this.
Things that would be good to get in before / shortly-after this lands, offhand:
- Show policies when viewing documents, in the header (this could happen first).
- Add shouldAllowPublic() if we don't already (can also happen first)?
- Deal with stubs.
- Do moves need special handling?
- Remove the magical stuff from Projects? Probably? Like the automatic wiki link. Or generally do something with it, since without changes it will have confusing / different behavior than it does today.
- Should a document start with the policies of its parent by default?
Basically, make sure we have a fairly cohesive approach in the works. I haven't thought through exactly how all the details should work but a lot of them are probably fairly obvious (e.g., only have one reasonable answer).
For example, if we default documents to the policies of their (nearest, existing) parent, which I think is reasonable, that also provides a sensible default for all the stubs.
| src/applications/phriction/storage/PhrictionDocument.php | ||
|---|---|---|
| 201–203 | I don't think this is currently true. You have to be able to view all of the parents, but do not need to be able to edit them, I think. I believe there are two messy cases here:
Moves add some more magic to this. | |
update text to say you need view permission on parent docs to edit
(other bits will come in a new diff)
make default view policy most open possible and default edit policy to USERs as default edit policy of public would be badsauce
| src/applications/phriction/storage/PhrictionDocument.php | ||
|---|---|---|
| 73 | This one too. | |
fix the other spot we set policy
start showing the policy on the header (I just didnt feel like merging my "progress" forward so adding it here.)