Group domain access (similar to group_sites)

This adds a configurable option to enable this more strict access checking.

The last submitted patch, 2: 3403517.patch, failed testing. View results →

+1

With Group Sites, you can also achieve this, if you choose so. We currently have a similar set-up going for a client.

1. Set up a bunch of domains, one being the default (i.e. fallback)
2. Assign a group to each domain
3. Configure Group Sites to use the domain context provided by Group Context: Domain
4. Write a few hook_entity_insert that assign any created entity that is supposed to be grouped to the group derived from the active domain
5. You may now use your site and even try to create global nodes via admin/content or node/add and they will still end up in the group that belongs to the current domain

However, you may also have a website where there is shared global content between multiple domains (e.g.: privacy statement) and restricted content for a single domain (e.g. contact page per country). If you don't take the above approach but allow content to be global or grouped, then you can also implement said use case with Group Sites.

All in all, I wrote Group Sites to be as generic as possible, allowing for multiple use cases either out of the box or by writing a custom service provider or access policy.

@kristiaanvandeneynde I see group_sites was released half a year after group_domain. group_domain work is based on custom code from a project that started even earlier. Pity we didn't join forces, now we may need to choose what works best and potentially duplicate effort. Do you see any solution on how can we avoid that?

@Graber Group Sites wasn't necessarily created as an alternative to Group Domain, but rather as a generic solution to the problem space. We are currently using Group Sites with a context provider that determines a group from the active language. It sort of supersedes all modules that are individually tailored to one context (Domain, Language, ...)

I had been sitting on the idea for a few years already but never found the time nor budget to work on it. Now that we had the opportunity to work on it for clients, we pulled the trigger and finally got it out of my head and into git.

I would welcome a comparison between the two to see if we can still collaborate somehow, but I thought it was important to point out that I am not interested in merely serving the Domain use case. I want Group Sites to be the solution to all context-based group delegation, to unify the landscape a bit. Kind of what purl and spaces used to do in D7.

Ok, let's make a comparison in some free time and see what can be added / improved in group_sites basing on group_domain. Migration path is also important as we have projects using it. If it'll be possible and will not present too many difficulties on current projects are you willing to share maintainership of group_sites with the current maintainers of group_domain?

Yeah I'm always up for collaboration.

I only have two wishes:

1. We agree that Group Sites should be generic and specific stuff should go in extra modules (e.g. group_context_domain)
2. We do not bloat the module to serve edge cases

If anything, the module could use another access policy or two out-of-the-box that serve use cases other than SingleSiteAccessPolicy, I'm just having a hard time coming up with use cases as it's usually that one that people want.

Re migration path: Group Sites requires no migration. You may need to run a small update hook to move your domain-group ties into third_party_settings for group_context_domain, though.

Sounds like plan :)

In the meanwhile..

+  $domain_group = \Drupal::service('group_domain.info')->getCurrentDomainGroup();
+  $relationships = GroupRelationship::loadByEntity($entity);
+  if (!$domain_group instanceof GroupInterface && count($relationships) === 0) {
+    return AccessResult::neutral();
+  }

I'd split that if to 2 ifs to improve performance a bit.

if ($domain_group instanceof GroupInterface) {

That's double checked.

-    return (string) $this->t('Domain group ID');
+    return new TranslatableMarkup('Domain group ID');

Worth checking why it was cast to a string, can't remember now but feels like there should've been a reason.

I know that's extra time but we should update tests to include that value.

Let's have a MR, it'll be easier since a bit more work is required.

re ##5: Part of the reason for the approach we adopted is that the flagship site here has 200K nodes and the microsites have 5-20 nodes each. To add all the extra overhead of creating group relationships in an already large site seems like too much weight. But that is a great suggestion and would work, if this site didn't need to keep so many nodes outside of group's purview for performance reasons.