Conversation
|
Question @jackmcdade, if a user has |
Yes that's how I would expect it to work 👍 |
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. |
|
Ah yeah @jasonvarga I agree with that. Makes everything so much simpler. |
|
Hey @jasonvarga here's my use case:
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. |
|
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.
|
# Conflicts: # src/Fieldtypes/Sites.php # src/Providers/AuthServiceProvider.php
…o. Could happen if their access to the currently selected site gets revoked.
|
OMG OMG OMG OMG OMG OMG. It's finally happening. Thanks @jasonvarga |

Avatar is Jack but this description has been hijacked by Jason. 👋
What's happening in this PR:
access {site} sitepermissions.$user->can('view', $site);, passing aSiteobject.What's not happening, caveats, notes, etc:
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.Closes #5661.
Closes #2667.