Skip to content

Comments

[4.x] Multi-site Permissions#5946

Merged
jasonvarga merged 130 commits into4.xfrom
multi-site-permissions
Oct 11, 2023
Merged

[4.x] Multi-site Permissions#5946
jasonvarga merged 130 commits into4.xfrom
multi-site-permissions

Conversation

@jackmcdade
Copy link
Member

@jackmcdade jackmcdade commented Apr 28, 2022

Avatar is Jack but this description has been hijacked by Jason. 👋


What's happening in this PR:

  • Add access {site} site permissions.
  • You can check if a user has permission for a site by doing $user->can('view', $site);, passing a Site object.
  • Show new permissions in role permissions builder
  • Global header site selector hides inaccessible sites
  • Policies handle checking appropriate site
  • Entry/term/global site selector on publish forms get filtered down to the accessible sites
  • Sites are filtered down on tree view site selectors in navs and collections.
  • Control panel navigation items get filtered out appropriately

What's not happening, caveats, notes, etc:

  • The site permissions only affect content management within the control panel. e.g. if you don't have a certain site permission, you won't be blocked from seeing it on the front-end or in GraphQL/REST.
  • No policy changes made for assets since they are not yet localizable. However, they eventually will get the same treatment as this PR. See: Add functionality to localize asset's ALT text ideas#223
  • No policy changes made for blueprints, fieldsets, forms, users as they aren't localizable.
  • No policy changes updater, addon browser, utilities as they have no site-specific logic.
  • Certain string-based policy checks (like create) now "require" the site to be passed along. If the site isn't passed in, then we avoid checking for site permission. The existing create permission still happens as expected.
  • The CP Nav preferences builder builds default navs using policy logic, so the above mentioned policy updates should cover most, if not all scenarios. If a nav item is hidden to a user in the sidebar, it should also be hidden in the user in their CP nav preferences.
  • The only site related content shown in our core widgets at the moment is in our collection widget. The global site selector is responsible for controlling the active site, which hits the same entries endpoint as on the collection listing, so entries listing filtering and policy logic take care of this for us.
  • Relationship fieldtypes are not touched. If we did limit values in relationship fields based on which sites are accessible, it would pose the following problem... A super user may intentionally relate a value that a more limited role cannot, which means entry data initially added by the super user could get wiped by a user with a more limited role. This just adds too much confusion and complexity.
  • Site permissions are required going forward, and the included update script will add them to all existing roles.

Closes #5661.
Closes #2667.

@jackmcdade jackmcdade changed the title Hook up the GUI/YAML portion Multi-site Permissions Apr 29, 2022
@edalzell
Copy link
Contributor

edalzell commented May 3, 2022

Question @jackmcdade, if a user has configure collections AND access site_2 (only) permissions, they should be able to create collections but ONLY in site_2 right?

@jackmcdade
Copy link
Member Author

jackmcdade commented May 3, 2022

if a user has configure collections AND access site_2 (only) permissions, they should be able to create collections but ONLY in site_2 right?

Yes that's how I would expect it to work 👍

@jasonvarga
Copy link
Member

if a user has configure collections AND access site_2 (only) permissions, they should be able to create collections but ONLY in site_2 right?

I would think the opposite. Those kind of configuration permissions can't really be per-site. When you have a collection, you can configure which sites it's available in.

If you have permission to configure a site... but you only have permission for a specific site... what happens to the "sites" field when editing that collection? Do you only get access to the sites you're allowed? When you hit save, does it wipe out the sites you don't have access to?

That's why I think the site permissions should only really apply to content editing. The configuration ones are probably app-wide.

Like the site permissions only apply to stuff you'd give clients. You'll let clients create entries, but you wouldn't want them creating collections.

@jackmcdade
Copy link
Member Author

Ah yeah @jasonvarga I agree with that. Makes everything so much simpler.

@edalzell
Copy link
Contributor

Hey @jasonvarga here's my use case:

  • 3 sites, 2 that are languages, and one that is very different, with a different set of admin users.
  • we'd like site 3 users to be able to configure their collections but NOT see the other collections anywhere.

So like when they go to configure their collection they should NOT be able to put it in a different site. Nor should the other sites show up in either of the 2 (Jack was going to explore why we need both) site drop downs.

They should also not be able to localize an entry into another site, nor a global. Nor configure the global to be available in another site.

This is why I've made so many changes, to handle all these scenarios.

Happy to discuss further.

@tao
Copy link
Contributor

tao commented Aug 5, 2022

It might be out of scope but it would be great if the multi-site permissions worked with Statamic Revisions too, so maybe the users could create revisions without being able to publish them (for a language they have access to), and wait for an admin to review and publish the revision or working copy when ready.

  1. That way we can prevent translators from editing content they shouldn't (without the published version on the live website changing).
  2. And we can review all their formatting, etc to make sure it meets our guidelines before actually publishing their revision.

@jasonvarga jasonvarga merged commit a9e6078 into 4.x Oct 11, 2023
@jasonvarga jasonvarga deleted the multi-site-permissions branch October 11, 2023 20:10
@adnankussair
Copy link

OMG OMG OMG OMG OMG OMG. It's finally happening. Thanks @jasonvarga

@jasonvarga
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[multisite] every user with at least view XYZ entries permission can create entries (localization) User permissions for Multisite Setup

8 participants