One user via Twitter who has a use case similar to multi-wiki:

https://twitter.com/anarchivist/status/431055528476028928

@epriestley - that's me! :) I'd be happy to answer additional questions about that usecase, too.

Generally, this is blocked mostly by two product questions:

1. Do we separate wikis at top-level, or retain the entire wiki space as one wiki?
2. Do we give individual wiki pages individual policies, or give all pages in some kind of group the same policy?

I was leaning toward separation and bulk permissions before, but since then we've implemented Phragment, which largely poses the same questions (i.e., it is also a system with hierarchical documents and similar policy issues). In Phragment, it seems more clear that we want/need document-level policies.

Document-level policies will create some level of complexity. Particularly, access to some document x/y/z/ needs to depend on access to x/y/ and x/ (e.g., if you can't see engineering/, you can't see engineering/secrets/cool_project/), and we need to give the user a clear error message if they follow a link to x/y/z/ (i.e., tell them that the policy issue is that they don't have access to x/, and therefor also do not have access to x/y/z/, to avoid a case where x/y/z/ has a relatively open policy and no one can figure out why it isn't visible even though it says "all users" can see it). This will still be a bit confusing (the page might say "All Users" can see the document, when parent documents may restrict this set heavily) but I think we could also mitigate this in the UI. Particularly, the default setting can be "just use the parent document's policies", and then we can show things accurately in the UI and users will only need to change or deal with settings when they explicitly want to lock things down.

A second piece of complexity that document-level policies create arises from bulk editing. Particularly, if you have edit permission on x/y/, it's intuitive that you should be able to recursively delete x/y/, or move x/y/ to x/y.new/, but x/y/ may contain documents which have policies that prevent you from editing them. I think the way to deal with this is to let edit permissions on x/y/ imply some level of permissions on all children (preventing you from doing a recursive delete or a bulk move seems very confusing and bad). Two approaches I see here are: edit on x/y/ gives you view+edit on all children; or edit on x/y/ gives you view+edit of metadata only (like document existence and title, but not content or history) on all children. Obviously, blanket access is the simpler approach here. I'm inclined to start with it and see if metadata-only use cases arise, since I think the transition would not be hugely complicated if we needed to make it later.

If we go down this route, the answer to (2) is "yes", and we end up with these implementations specifically:

• Document x/y/z/ is visible if it and all of its ancestors are visible.
• Edit permission on x/ grants edit and view permissions on all descendants.

I think these approaches are fairly reasonable, and don't immediately see any major technical or product barriers to implementing them.

This leaves (1) unanswered, but this approach is compatible with answering (1) affirmatively later if we have other reasons to do it (for example, if we add more CMS features to Phriction and let you have subsections with certain layouts, etc). It also moots a lot of the question, though, since granular permissions are more powerful than block permissions.

My only real concerns with this approach are that the policy cascading rules may be a bit unintuitive, but with some UI support I think we can make it fairly clear how things work, and the rules are very simple, and it should be easy to reason about policies once you understand the rules. I believe we can support the same rules in Phragment without issue, too, and probably any other future hierarchical applications, so you can learn the rules and then reason about general policy behavior across applications.

@epriestley, is Phragment usable at this point? When opening it, I get the following message:

security.alternate-file-domain must be configured!

Because Phragment generates files (such as ZIP archives and patches) as they are requested, it requires that you configure the `security.alterate-file-domain` option. This option on it's own will also provide additional security when serving files across Phabricator.

It's still pretty alpha, and probably not especially useful until Harbormaster is a little further along. It won't, like, delete all your data or anything, but we may still make significant changes to its basic functionality going forward.

@epriestley, on your document-level policies comment: why not just let everything follow the normal Unix file permissions behavior? Yes, it might be a little bit weird in some layouts, but is proven to be secure and should be easy to use by many.

(Note that the configuration requirement for Phragment is not going to go away; @epriestley and I discussed it at length during the inital construction and it's the only secure way of serving up the dynamic ZIP files)

I think unix file permissions are significantly more complex than the proposal above, and would create a lot of very confusing edge cases. For example, suppose you create a Phriction document called "epriestley_is_a_jerk" and set "Visible To" to "No One". Under the unix model, I can still see that the document exists:

----------     1 epriestley  admin     0B Feb  7 15:04 epriestley_is_a_jerk

I think this result is very unintuitive, and there would be a lot of other similar, very unintuitive cases.

I see, so you want to have an ability to hide pages and include hidden epriestley_is_a_jerk in every installation! :) Really, I don't think there is any problem with the situation you described, because nobody would add important things such as passwords into wiki pages names. At least, that would be very unintuitive.

But it would be a problem for those of us that would like to have internal subpages of wikis; we don't want to publically announce that there are non-public notes on things because then that makes people ask "what is in the internal notes?"

@hach-que Good point, but I doubt any company caring about keeping their internal pages content a top secret would ever keep it under control of engine partially available to public... OK, that's just an opinion. Let's see what other opinions users have.

We have a mixture of secret and public content on this install. I think this is probably a common use case for installs with some public content.

I'd vote for: 1) separate top level wikis

My feeling is this would resolve probably 98% of use cases, which maintaining a much easier to understand hierarchy for users and admins. Users understand they are in a block of pages that are assigned a single permission, and anything new or moved keep those same permissions. I think this is more important (being simple with permissions) in Phriction than most other areas given it's likely to be deployed company wide, and not just engineering. It also seems like less work (design, eng) and still compatible down the road with more granular permissions.

Top-level wikis would not be particularly useful for our case (where we have public documentation with internal notes).

I see no reason not to really support both these modes; page-level permissions is a superset of the functionality required for wiki-level permissions, and it'd be pretty simply to change the interface based on a configuration option or something of that nature (for wiki-level permissions, you just use the same propagation logic that Phragment uses to set policies).

Public documentation with internal notes, something I've seen at every company I've worked for, would be probably better served through more specific means - the CMS route Evan is describing - than just per page visibility. I just would rather track that specific use case in a different task, as I think most public wiki's would enjoy it. (For example, we could have 1 page with 2 different content area's with different visibility restrictions).

Yeah, I think internal notes is a use case we could probably solve in a more tailored way, but I could imagine something like having changelog/version-2.0/ be private until the software version is actually released, at which point it might be made public.

Another example would be for us to keep meeting notes, and have some of them be public (maybe from a Q&A session at a meetup, or an internal meeting or whatever) and others have different visibility (maybe restricted to a specific client).

The more compelling argument to me is that Phragment more or less requires granular visibility because organizing by visibility at the top level makes nearly no sense, so if we don't make Phriction granular we'll have two fundamentally different policy systems in applications which have a lot of high-level similarities.

This is definitely a use case for us. Many situations where one would like to have documents on the Wiki, but not necessarily publicly visible to the casual user browsing around on the site.

bit of a tangent here... re: internal notes, if T5804 sees the light of day, you could store the private stuff wherever, then embed it into the public stuff.

I feel like T5804 with policy at the document level allows for some really creative stuff. For example, virtually all HR documents could be written, which are somewhat dynamic per employee. Consider something like vacation policy which is likely going to be different for an international company on a per-nation basis; if users are slotted into some per-country groups which map to document policies and then some main document is written correctly, this main document is one badass wiki page if you're into HR compliance.

I should note I said creative stuff. Not sure how valuable this really is. Writing and testing the main document sound like huge UI challenges. The glue feels junky too.

If we had an embed syntax (e.g., some syntax like {w/path/to/page}, like {F123} and {P123}) we could apply the same sort of policy rules that we do for the other embed rules -- if you can't see the embedded snippet, you just get a "you can't see this" sort of thing (in the F/P cases we just don't embed it at all and leave the original text, but at some point could maybe show a more explicit "this is a thing that exists which you can't see" output).

The big question to me on T5804 is how useful just embedding a snippet is vs having some sort of template support (where you can pass text into it and it puts it into the output somehow). Basically, how far are we going to go?

It looks like MediaWiki has:

• Templates - Supports basic substitution, like hi {name} as a template and {{greeting, name=bob}} as a call to it to render hi bob.
• Advanced Templates - Supports crazy stuff including branching, templates as template parameters, and variable variables.
• ParserFunctions - Looks like it's basically a functional-flavored DSL.

If we're going to end up at the far end, I'd tentatively want to sketch that out before we write the low end so we know where we're headed.

An extreme high-end thought is that we could make pageType a property, and implement a PhrictionDefaultWikiPageType which is a page that shows the text normally. You could subclass this to choose a different page type, and the page type implementation could render stuff however it wanted (e.g., pull from another source, composite multiple sources, etc). This would cover cases like "the real document is somewhere else, but we want a copy on the wiki". But this is maybe an upper bound of power, and would let us scope whatever templating/snippeting we do to some reasonable middle ground. I haven't actually seen any requests for this, except T3975, which I think wanted an embed specifically rather than just bridging a Google Doc into Phriction.

For us have separate wikis (git accessible even better) would be really great for our use case.

Support Impact Inconsistent and confusing.

I read all this thread and still cannot figure out if I can apply any policy or privacy setting for a project. It is a real trouble. Projects need documentation. But not everyone should access this project.
How does Phabricator approach this issue?

Projects are the privacy setting. You make a Project, set the members and who can join, then lock down other areas of Phabricator with that Project.

I'm unclear on whether or not any of the recent changes are usable right now. Is there any way to actually limit access by project right now? It would be helpful if the task description was updated with a checklist of things that are (not) supported.

Nothing is usable yet.

I think once the task is marked "resolved" you can expect this functionality to work and its potentially most expedient to just hang out until then. In the interim, there's a mountain of technical debt I am taking out, plus related features... Here's my current list

• PhrictionEditController has lots of error-checking business logic that needs to be moved into the editor - see D10795
• PhrictionDeleteController has a small amout of error-checking business logic
• PhrictionMoveController has a small amout of error-checking business logic
• Conduit endpoints need to be upgraded to be savvy to this error-checking from the editor stuff
• https://secure.phabricator.com/T4021#59511 has some more stuff here
• T6472 T6034
• what we're actually talking about here

For anyone waiting on this with bated breath, there are a couple of minor followups in T6495, T6496, and T6497 to iron out some details.