Subgroups core module

The patch is missing here.

While testing this, I noticed that the subgroups view is using the wrong relationship - this means it lists all groups content, rather than subgroups.

Since there's no patch to update yet, uploading the exported YAML for reference.

In the last patch the view display name changed from page to page_1, which makes the 'Relate subgroup' and 'Create subgroup' links disappear.

This patch updates the ggroup.links.action.yml file to point to the updated display name.

I found a bug where I can't create subgroups. Despite the authorization, the user cannot create subgroups. I can only link existing subgroups using the entity. Also Access subgroup overview cannot be accessed.

to readjust:

* create a group
* create a subgroup (without further node-types, only the subgroup)
* set permission to: access subgroup overview and subgroup type Create new subgroups
* log in with the user who has the authorization

go to the subgroup overview page - there is no menu displayed and no button to insert. only when add subgroup relation is selected in the permissions, it is possible to insert new subgroup. however, i need new subgroups, no entity link.

this bug does not appear, if a node-type is installed for the group. then it works without problems, but i do not need a node-type for the first group.

for my main group i only have the following in use: subgroup, group membership and group membership request

my structure looks like this:

* main group with many users
* users can create new subgroups in the main group
* node-types can be inserted in the subgroups

unfortunately my structure doesn't work like this at the moment. i'm not a drupal developer and can't fix the problem, but i hope that someone can fix this bug. thanks a lot in advance.

---

and one more thing: if a user has a role that only has view subgroups, this user can still edit the subgroups. so in the admin overview all groups are shown, with a dropdown in the button the group information can be edited or even the whole subgroup can be deleted. but the user is not allowed to create a new subgroup, nor edit or delete the subgroups.

I tried this code patch, while you can add existing groups as subgroups via adding content, the realities of using this were less than perfect.

On the face of it subgroups was ideal for the content and user architecture I have. But I needed to create views to drill down from a group into the subgroup and get the subgroups content. Views did not allow this though. I ended up having relationships that were more confusing than illuminating and the returned subgroup content ID (e.g. Node ID) was impossible to get. Instead I got the subgroup ID not the subgroups group ID (from where I could get the related content).

We are currently in the process of developing a fully supported Subgroup module for a client. The architectural decisions here do not fully match what I had in mind, but we will use this thread's patch, discussion and related issues to see which issues people ran into and how they resolved them.

I'm hoping the end results will please everyone. Do keep in mind that the architecture I currently have in mind also focuses on ease of configuration and performance. It will support role inheritance both up and down an ancestry tree and will even allow for circular inheritance so you can achieve scenarios such as "member of child inherits member permissions in parent, but also vice versa".

That's about all I can say now, but I wanted to keep you all informed that this is now in the works.

Hello community,

I have a question of understanding in the area of node access and subgroups. In order not to mix up the topics, I have posted a separate issue. Could someone help me with this or could someone take a look at it.

Understanding Node Access with SubGroups

BR,
Daniel

the patch in #12 does not apply to dev version.

everything else passes except for the changes to the .composer file

patching file composer.json
Hunk #1 FAILED at 23.
1 out of 1 hunk FAILED -- saving rejects to file composer.json.rej
patching file modules/ggroup/config/optional/views.view.subgroups.yml
patching file modules/ggroup/ggroup.group.permissions.yml
patching file modules/ggroup/ggroup.info.yml
patching file modules/ggroup/ggroup.install
patching file modules/ggroup/ggroup.links.action.yml
patching file modules/ggroup/ggroup.module
patching file modules/ggroup/ggroup.routing.yml
patching file modules/ggroup/ggroup.services.yml
patching file modules/ggroup/ggroup.tokens.inc
patching file modules/ggroup/ggroup.views.inc
patching file modules/ggroup/src/Access/SubgroupAddAccessCheck.php
patching file modules/ggroup/src/Controller/SubgroupController.php
patching file modules/ggroup/src/Controller/SubgroupWizardController.php
patching file modules/ggroup/src/Form/SubgroupFormStep1.php
patching file modules/ggroup/src/Form/SubgroupFormStep2.php
patching file modules/ggroup/src/Graph/CyclicGraphException.php
patching file modules/ggroup/src/Graph/GroupGraphStorageInterface.php
patching file modules/ggroup/src/Graph/SqlGroupGraphStorage.php
patching file modules/ggroup/src/GroupHierarchyManager.php
patching file modules/ggroup/src/GroupHierarchyManagerInterface.php
patching file modules/ggroup/src/Plugin/GroupContentEnabler/Subgroup.php
patching file modules/ggroup/src/Plugin/GroupContentEnabler/SubgroupDeriver.php
patching file modules/ggroup/src/Plugin/Validation/Constraint/GroupSubgroupConstraint.php
patching file modules/ggroup/src/Plugin/Validation/Constraint/GroupSubgroupConstraintValidator.php
patching file modules/ggroup/src/Plugin/views/argument/GroupIdDepth.php
patching file modules/ggroup/src/Routing/SubgroupRouteProvider.php
patching file modules/ggroup/tests/modules/ggroup_test_config/config/install/group.content_type.default-subgroup-subgroup.yml
patching file modules/ggroup/tests/modules/ggroup_test_config/config/install/group.type.subgroup.yml
patching file modules/ggroup/tests/modules/ggroup_test_config/ggroup_test_config.info.yml
patching file modules/ggroup/tests/src/Kernel/SubgroupTest.php
patching file src/Access/GroupPermissionChecker.php

Re-rolled the patch fixing the issue in composer.json

Re-rolling again - applying patches in PhpStorm allows fixing issues, but it lost the directory depth...

it still applies... just a composer glitch

(DELETE)
reroll needed for new dev version of group

Exactly the same patch as in #18, just added core_version_requirement: ^8 || ^9 because the code is compatible with Drupal 9.

The above patch failed to apply. Uploading the correct one

In the above patches,

class SubgroupAddAccessCheck implements AccessInterface {
...
...
...
    // Determine whether the user can create groups of the provided type.
    $access = $group->hasPermission("create subgroup:{$group_type->id()} content", $account);
...
...
...
}

shouldn't it be "create subgroup:{$group_type->id()} entity" instead?
Wondering what the expected behavior is because I receive access denied unless I have "administer group" permissions. This change fixes it.

Do we need to update this module because of the changes which were made to the groupe 1.0/1.1 release?
I mean the following:

Group takes care of entity access for ALL content entity types. By leaving only node grants in there, it basically means that all other entity types are shit out of luck. Which is exactly why I've been pushing for entity query access for the past few years. It's time core got rid of this "Only works for Node" nonsense and started caring about all entity types. In short: I could not have released a full Group version without getting rid of node grants, because core only seems to care about nodes.

and

Keep in mind that query access will only work for those plugins that declare these handlers. All plugins provided by Group have been updated to declare these handlers.

Another question:

Shouldn´t we use the official contrib modul instead of using this group modul modification?

https://www.drupal.org/project/subgroup

Let's mark this postponed on https://www.drupal.org/project/subgroup - then the project maintainer can mark duplicate if they want to.

Ok, as we found out in the discussion with the maintainer of the subgroup module, it is not a duplicate, but takes a different approach.

The difference, for me, is that the subgroup module only allows one "one child group can only belong to one parent group".
This implementation here allows a "one child group can belong to several parent groups".

Maybe this variant, though not in the core of the group module, will make it into a separate Contrib module. I would be very pleased!

Yes, subgroup takes a very different approach.

@JD_1 mentions the "one child group can only belong to one parent group" limitation; in addition for me the "one group type can only be in one group hierarchy once" blocks use of subgroup.

The state of my project means continuing with ggroup, given the creation of subgroup as a stand alone module we should also consider that this module will not become part of the group project. So I have set up ggroup as its own project and I have added @LOBsTerr as maintainer.

These two options for building sub-group hierarchy will have to co-exist and not be compatible with each other.

This will also bring #3084153: Subgroup role mapper into the new ggroup module.

doesn't it make more sense to continue working on the subgroup module? maybe find a solution for the problem with a subgroup? for my project i would also need several child groups in one parent group, but i would prefer to use the subgroup module. it is most likely to be maintained, is 100% compatible with the group module.

i see problems and incopatibilities coming up if two identical projects differ only slightly in detail. this would only unsettle future users and if the "wrong" module is selected, the user has no possibility to switch, even a migration i don't see here.

Hi @zcht, you can if you have two different group types, use subgroup to build what you described.

As @kristiaanvandeneynde said in #3084140-9: Subgroups core module

We are currently in the process of developing a fully supported Subgroup module for a client. The architectural decisions here do not fully match what I had in mind. [...] I'm hoping the end results will please everyone.

Specifically in subgroup the tree structure is managed using third_party_settings on the group_type. This means that Group Type A cannot have children that are also of Group Type A. Further a Group of Type D cannot be a child of a Group of Type A, B or C.

Interestingly this is the opposite reason for why I created Entity Reference (with) Hierarchy compared to Entity Reference Hierarchy, the latter builds a hierarchy chain through config fields as this ggroup does.

If you want I could explain the reasoning behind Subgroup's architecture further and why I chose that one over ggroup's approach. But right now I have other fish to fry before I go on vacation so it will have to wait until roughly end of August :)

Hi @dwkitchen,

yeah, you got that right. Not out-of-the-box, though, as only one child of a type is allowed here. But this can surely be solved easily.

I wanted to get back to the general topic in a more regular way. I don't think it's beneficial to create two modules that are designed for the same purpose and differ only slightly in detail. Personally, I also think it's a pity that all the work for the patches was not considered and a different construct was implemented. But I think that we definitely need to join forces for the subgroup module. There are many reasons for this: compatibility, RC version - soon to be stable and therefore considered by the security team, membership/role workflows will be much easier, certainly also the performance (here we always had a problem with subgroup as patch), many patches for patches for patches will be omitted... we had some of them for the RC5, which had to be adapted again and again.

If the community applies the work to a module, many will benefit. But if we develop two modules, the valuable work resource is lost. I think we can definitely find workarounds for the new subgroup module. I would even have gone one step further and implemented the module in the group core, the group module is used for a reason, the subgroups are almost mandatory for many use cases.

The discussion just reminds me of Drupal vs. Backdrop CMS, I think we should avoid that and find a holistic solution. :)

Personally, I also think it's a pity that all the work for the patches was not considered and a different construct was implemented.

It was considered, but the graph approach in this patch has significant downsides compared to the nested set model when it comes to reading the data. As the majority of operations are reads, I chose the system that guarantees optimal performance during read operations as that's what powers the calculation of your permissions.

Upon further review, I noticed this module closely follows what's already there (gnode, group content wizards), but I'm trying to go for a more generic approach nowadays. You'll notice that the gnode module is rather empty these days and that's because group core will soon be able to support most simple entity types without having to write a submodule for it.

So I too regret I couldn't build upon this patch, especially given the excellent work @LOBsTerr has been doing for Group. It's just that, in this matter, we had someone paying for the delivery of Subgroup and it didn't make sense to continue working on an existing module if that module's foundation doesn't match what you think is best for performance and stability (nested set model). It's hard to accept payment while promising good performance and then work with code that you know might form a bottleneck.

The limitations currently found in Subgroup aren't all permanent either. While it's definitely not the goal to allow multiple parents (due to stability/performance reasons), it could become possible to add existing groups to a tree later on. It's just that this raises so many questions and security risks that we chose not to target it for a first release. Especially given how our client was building a site from scratch and had no need for it.

For what it's worth, @LOBsTerr seems to have done a great job translating what I believe to be this graph algorithm into Drupal. https://www.comp.nus.edu.sg/~ooiwt/slides/2007-ioi-training-graph.pdf

It's just that most use cases need a hierarchy tree rather than a "net" and for that particular use case, nested set is both simpler and more performant.

Hi @zcht,

I would say think of this more as the difference between Display Suite and Fences.

Here is how I have explained the difference on the project page:

Subgroup (Graph) ggroup

Uses a Graph model to calculate relationships between groups.
Has more flexibility in including poly-trees, however graph enumeration requires more processing.

Subgroup (Tree) subgroup

Uses a Forest of Rooted Trees model to calculate relationships between groups.
Configuration limits that a Group Type has a fixed position in tree.
Rooted tree enumeration is simpler than graph enumeration (quicker/less processing)

One of the issues with all the patches, is we can see that Group module is reporting over 9k sites - but we don't know how many are using the Subgroup patch.

I would say a big issue is the comparability of the patch with the latest version of `group`

I was able to upgrade switch to ggroup module without problems and upgraded groups to the latest version. 👍