- Maniphest Tasks
- T4029: Support policies on Phriction wiki articles
- 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
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.
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.
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.