Limiting Explorer to the current user's "explorable pages"

Last week, @tomdyson gave me a suggestion for how Wagtail might be enhanced to support completely separated tenants in a multi-tenant Wagtail instance: implement a “View in Admin” Permission. Possibly with a better name… I believe someone suggested “Choose” in one of the issues relating to this concept, but that’s not really broad enough.

Applied to Pages, this permission would prevent unprivileged users from:

• seeing the Page in the Explorer or the fly-out menu in the sidebar
• going to the Explorer URL for that Page (e.g. typing /admin/pages/29/ into the address bar would issue a 403)
• seeing the Page in admin-side search results
• seeing the Page in a PageChooser

Applied to Collections, this permission would prevent unprivileged users from:

• seeing Images or Documents in Choosers
• uploading media to unprivileged Collections

Users already can’t see or upload media in unprivileged Collections on the /admin/images/ and /admin/documents/ pages, so I’ll hopefully be able to use the code from those pages as inspiration for implementing the View permission.

The purpose of this permission would be to completely isolate users belonging to one Site, so they can’t tell that content belonging to any other Site exists (and also can’t get to said content even if they guess the URL, since that would be a privacy violation). This is counter to the way that Collections and Pages currently work, though, so I suppose this functionality would have to be made optional, somehow? I’m not really sure how that would be done, though, so suggestions are welcome!

I intend to implement this myself over the coming days, and will be providing a PR for my changes as soon as they’re in a presentable state. I opened this issue now, though, to get input from you guys on how best to go about this, and whether any of my current assumptions may be in need of an update to properly understand all the subtleties involved.

Since this will involve changing the choosers, it relates to #1645, which I also plan to enhance by making the new unified Choosers be Permission-aware.

[gasman]

Hi @coredumperror,

I’d very much like to stick to a model where the admin behaves the same regardless of the domain they happen to be logged in on. In other words, there’s a single entry point through which the user can edit everything across the installation that they have permission for - there’s no concept of “the admin backend for site A”.

In the past, we’ve had odd bits of logic in the admin that triggered based on the domain the user was logged in on, and that’s always turned out to be a bad idea (see #1461 for example). Indeed, we’d like to allow for the possibility of logging in to the admin through a domain like admin.example.com that doesn’t correspond to a site at all - this doesn’t quite work at the moment (see #1807).

As far as I can see, the only scenario where this wouldn’t be desirable would be if you had users administering multiple sites, and didn’t want those users to know that they were all running from the same Wagtail installation. That seems like a pretty esoteric requirement, and if you really needed that, you could always give users multiple login accounts, one per site.

[gasman]

Closing this to reduce duplication of tickets - I’m now treating #2463 as the “master” issue for tracking multi-tenancy support (even if much of the work is happening on other PRs).