Create a new editor flow that does not involve wizards or custom pages

We could also decorate the PermissionChecker service to merge the scopes. That might actually be more logical.

Giving this some more thought and it would mainly affect creation. For that to be possible we need to answer two questions:

1. What group?
2. Which plugin?

We can answer question 1 by using a context provider, one of which could be a selector. Question 2 can be answered if we introduce new logic where only one plugin can leverage entity_access over a particular bundle (or entity type) at any given time. So you could be allowed to have 2 node plugins for "page", but only one of them is allowed to determine entity access.

At that point, we could fallback to the only logical default.

Now, to hand out permissions we could use the context provided Group and hand out some Drupal permissions from said group. This need not be limited to just entity create access. We could very well hand out a few other Drupal permissions based on which group entity is active.

That would change our access policy to take a cache context which returns the active group's permission hash of only those permissions that have a Drupal counterpart. This could lead to only a handful of hashes being possible and not jeopardize the cacheability of the access policies.

So now we need a system where we can indicate which group permissions can affect your Drupal permissions...

Some more thoughts.

Group selector

We introduce a Group permission called "set group as active". We adjust the Group query alter to support a new operation "set as active", which checks for said operation. This way we can build a list of groups you're allowed to set as active. Then we can build a selector (dropdown?) where you choose which group you want active or if you want no group active.

The selector can support a context provider as backup. If a provider is set up, the selector gets an extra option "Automatically selected Group". The selector also always has the option to say "No group is active".

The selector + fallback behavior will replace the context selector from Group Sites and GS will use the one that ships with Group 4.0.0.

Drupal permissions from Group

Every Group permission can specify a Drupal permission it will hand out. The UI will show this in the description saying:
"If the user has this permission in the active Group they will also receive the "foo" Drupal permission"

Then we build an access policy handing out these permissions as describe in #5

The above two items seem like a great place to start building this feature.

Kristiaan, my first impression: i like it a lot where this is going!

Thought a bit about this, and yes, the "domain group preset" case and similar ones are handled nicely.

There are sites though, where the group must come from the URL, but this can be handled by sth like /node/add/foo?group=123

Then there are the use cases where group must be selected on the /node/add/foo page itself.

Which rang a bell:
Why not suck in a stripped down version of Entity group field → ,
and let widgets (like fromDomain, fromQueryString etc) do the work?

(Without that la last use case, which we had quite often, might turn out a PITA.)

Because entity group field is limited to the assignment of a group. I want this system to be able to hand out core permissions based on which group is active. Being able to add a new node is merely one of said permissions. One that we will have to accommodate the UI for, though.