When I create a second portal ("Encyclopedia of Fruit") and a page ("Orange"), what URL does the page exist at?

How do I use [[ ... ]] to reference pages in the second portal, like I can currently use [[ consulting ]] to reference Consulting?

When would I want to create a portal called "Public Content" instead of creating a page called "Public Content" at /w/public/ with visibility "Public"?

If I want some pages in my "Phacility Employee Handbook" portal to have restricted visibility, how do the controls available to me differ from the current Phriction controls?

Hmmmmm, so this essentially exists but you have to make /w/ public in order to achieve it?

I think PhrictionPortal probably doesn't look too much different from "make a second wiki, except this time you don't have permission to edit the root document, and it's locked to public / all users visibility automatically, and it's at some other URL other than /w/, and remarkup has two different rules".

Say Wiki #2 lives at /x/ instead of /w/.

Then when you create a "portal" we just create /x/portalname/ and that's basically indistinguishable from a Phriction page, except that now /w/fruit/apple/ and /x/fruit/apple/ can both exist and we have some kind of [[ !fruit/apple ]] syntax or something to refer to the /x/ wiki I guess?

I think that most problems a Portal could solve are solved by making /w/ public / all users, then creating /w/portalname/ to create portals, and applying appropriate visibility to those subsections.

I don't think it's even that hard to convert an existing install. Even if you had lots of /w/apple/ and /w/orange/ stuff before, you don't actually have to move those pages to add a /w/public/ section. About the most work you'd have to do, I think, is move /w/ to /w/welcome_page_for_private_users/ and change the text on /w/ to point at the public and private subsections? Maybe you get into a bit of trouble if the edit history of /w/ had sensitive information on it at one point, but I don't think we've seen users hit that.

If this is a pain point, maybe we could look at locking the policy for /w/ (the root document) going forward so new installs don't get themselves into trouble: "the root document is always public". But I'm not really sure the existing system creates much of a problem.

I probably solved most of this with my Phriction redesign which visually treated child pages as navigation.

(this is a problem for me switching on and off projects, haha, I forget design decisions)

I do think we could make a product argument like "the hierarchical permissions system is too complicated for users to understand, and they'd be better off with a less powerful system". That might look like:

• We lock permissions on /w/ to "everyone who can see Phriction".
• Subpages become "portals", with editable view/edit permissions.
• All descendants of a "portal" have the exact same permission as the portal, instead of being based on parent permissions.

Basically, this would be a less powerful but more straightforward permissions systems, where permissions were clearly divided into chunks.

This would prevent some use cases (like having /project/top_secret/, which is more private than /project/) but could reduce confusion in cases like T12437 where the "directory-like" permissions aren't clear.

I tend to think this isn't the best approach in the long run, and I'd rather support the more powerful use cases than sort of hobble the permissions model because we don't trust users to understand directory-like permissions, even though they use a filesystem which has a similar permissions model every day.

Ok I think this is mostly a UI issue then, and I didn't think this entirely through. Also, spaces then should just work?

I think we could just add spaces without any real fuss, yeah. Two possible considerations:

• They might need a little cleanup around errors like "You can't create that page because it already exists, you just don't have permission to see it." since it's possible the logic would work slightly differently when you couldn't see it because of spaces. This is probably like 5 lines of code.
• If an install is set up like T12421, where there is no "common" space which everyone has access to, there's no space you can put /w/ in which makes it visible to everyone. I tend to think that this is an issue with the use case in T12421, not an issue with the Phriction model, though, and that that install should probably use a "common" space if they want applications like Phriction to work.

One other thought as a sort of counterpoint to myself: if we do implement T11367, I probably would expect it to work more like "portals", where you define a portal/directory/volume and everything inside it shares the same permissions. But that's because I'd plan to eventually build DefinitelyNotDropbox.app for bridging file directories to the desktop so you could mount the filesystem on your computer as a disk, and I think we get into enormous amounts of trouble if I mount the phacility_tax_documents/ drive locally and then individual files inside it might have individual permissions so I couldn't view or edit some of them, since there's no way we can give users guidance about that from a filesystem mount. But maybe we have more flexibility there than I think.

Other design stuff (like custom themes/navigation/etc) may also make the hierarchy more difficult and maybe motivate re-examining things here, but I think spaces, on their own, don't make a strong argument for trying to break permissions up like this, since they should pretty much just work as-is. There's maaaaaaaybe a weak argument for trying to make /w/ more magical so users can't get into trouble by locking it down too much or ending up in bad situations with spaces but I'm not sure that gets us much of anything.