Problem/Motivation

I've been asked to look at making a version of the module compatible with Group 2.x

Proposed resolution

Remaining tasks

Permissions system. Alternatives:

Using the same logic as now with only the taxonomy terms in the group, but implementing a flexible permissions calculator to work with group's own to restrict access to nodes (and comments).

Add CRUD hooks to create/remove group relationships for the nodes and comments such that they become group content.

Issue fork group_forum-3349564

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ekes created an issue.

ekes’s picture

ekes CreditAttribution: ekes as a volunteer commented

So my initial thoughts were to use the calculator because it'd work much the same as the current version, and doesn't have any potential 'out of sync' errors. Plus having a good excuse to use the new flexible permissions calculators would be great.

However, I'm now wondering, if it might not be better to have the forum content appear in the group administration lists, gnode and maybe even group_comments. It could also even be used to get group context that people could use in site implementations, rather than just be only access control on a central forum. Just has the issue of correcting membership if there is any way content gets out of sync, terms are added to groups etc.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops commented

Great to see this module seeing some love. Unfortunately, I haven't had time to dive into groups 2.x, although we do have a wide use case for groups and need to migrate lots of other things soon as well.

As for the way forward for forums, I'm not certain about the best approach. But adding nodes and comments as group content sounds a bit complex. The use cases I'm aware of, use the forum module and either all or some forums (i.e. taxonomy terms) with limited access by groups. And their expectation is that all content within such a forum (i.e. nodes and their comments with an association to such a forum) will then also only visible to those group(s). That sounds like access control only.

What extra benefit would we get, if the nodes and their content were also attached to the groups?

As for implementation/maintenance, what can I do to make your job possible/easier?

ekes’s picture

ekes CreditAttribution: ekes as a volunteer commented

> What extra benefit would we get, if the nodes and their content were also attached to the groups?

I'd guess the primary case is the UX (and DX) when dealing with nodes and maybe even comments. They would be listed as group content in the same way that all other content is. The relationship would be available too if the desire is to back reference the group in the same way that you would other group content (Usually linking to, including colour or logos from, parent group/s).

I find the site I'm dealing with having all the forum content under /forum rather than having multiple /group/id/forum is confusing. Everything else lives within a group, and it's not super clear why you see individual forum containers (and not others). But I don't think either route would stop extending the forum.inde and forum.page controllers to have group filtered versions.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops commented

I'd guess the primary case is the UX

...

I find the site I'm dealing with having all the forum content under /forum rather than having multiple /group/id/forum is confusing.

I would have just thought the opposite. When having a forum, the traditional way to look at a forum is to have a list of all forums, that the current user has access to. And from there, they go into these forums (taxonomy terms in Drupal's case) and browser the forum content.

If some forums (terms) have limited access, then some users see a shorter list of forum topics than others. And that's how people were used to use forums. Well, TBH this is back in the old days. But the forum module in Drupal is just like that. It's not a modern thing, it is a means to still do it that traditional way, isn't it?

I fear that users having forums all over the place on a Drupal site may become more confusing, as it just breaks that known model.

ekes’s picture

ekes CreditAttribution: ekes as a volunteer commented

The suggestion to split the forums was very much optional extension; and actually can be done which ever way the access control is done. So I think adding that rather confused things. It is one of the possible solutions for the site I'm looking at though; which is very focused on people working on content from within the context of their groups. The other option, for that site, is to keep the one forum but make it clear what groups forum content is in (which I think would be much easier with the group content relationship).

ekes’s picture

ekes CreditAttribution: ekes as a volunteer commented

OK I spent a bit of time running through steps for implementation and I can see @jurenhaas your reservations about actually making the content part of the group; even when the content might even only be shown in the group. So running through details - for my own clarity and if anyone else has options.

Forum has:

  • Forum taxonomy terms in which Topics are posted, and other (child) Forum and Forum Container terms.
  • Forum container taxonomy terms which are identical to Forum terms (same vocabulary) but have a boolean field which means that Topics cannot be posted in them, just other (child). Forum and Forum containers.
  • Topic nodes which are posted into Forum terms. There is a single Forum for a Topic and a sql lookup table forum and index table forum_index for this. When moving nodes between terms there's also some idea of shadow Forums I think this can be ignored?
  • Reply comments to Topic nodes.

When a Forum (container) is placed in a group it makes sense that all child content Forum (container), Topic and Reply are under the same access control as the Forum (container) itself. Doing so by making Relationship entities for every Term, Node and even Comment entity is clear if maybe a bit fiddly if large Forum with lots of child terms and nodes are moved into, or out of, group. But where I thought this would bring clarity about what content is in a group it adds complexity as it does not make sense that you could remove a child Forum or Topic from a group when its parent is in the group.

The present 1.x compatible Forum Group does this by adding entity_access hooks and node access grants. Which is similar to how the Group 1.x module implements its access control. Group 2.x/3.x drop using node access and go for a comprehensive entity access system by not only implementing entity_access hooks, but also query_alter hooks. What gets added to the queries, and in the access hooks, is based on the permissions that come out of the permissions calculator. Original permissions, in this case, come from the permissions plugins in the modules providing group content relationships. What permissions are relevant to the user (individual), group roles (outsider, insider role), anonymous are computed with the calculator. Group Permissions module, for example, adds to the calculator so you can have different permissions per group (rather than group type).

Thus if forum_group does not add Relationship entities for all the Terms, Nodes (and Comments) in a group. It will have to re-implement the 1,x logic for grants as a query alter; and update the entity_access hooks. I don't think adding a permissions calculator plugin here helps. We are using the output of the group one to find which permissions to apply. Where Group has a reasonable set of JOINs to do this, based on the group relationship entities, Group Forum doesn't because of the taxonomy tree. Just adding the node forum lookup table seems sane. But as 1.x we'll have to do an additional set of queries to get parent terms that might be in groups.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops commented

Great summary, thanks for doing this.

ekes’s picture

ekes CreditAttribution: ekes as a volunteer commented

https://git.drupalcode.org/issue/group_forum-3349564/-/compare/2.0.x...3... contains a first pass at reimplementing the option of just one forum (container) in the group and all children forum (containers) and topics being access controlled using the group 2.x style entity access and query alter.

monaw’s picture

monaw CreditAttribution: monaw commented

hi, is the current 2.0.x release or dev compatible with Group 2 and 3?

ekes’s picture

ekes CreditAttribution: ekes as a volunteer commented

2.x version of this module is Group 1.x compatible.

The branch referenced in this issue is Group 2 compatible.
https://git.drupalcode.org/issue/group_forum-3349564/-/tree/3349564-grou...
We're using it. If it's good it could become a 3.x version of this module.

monaw’s picture

monaw CreditAttribution: monaw commented

terrific, thank you @ekes!

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops commented

Let's think about the future releases of this module.

Version 2.0.x is group 1 and Drupal 9/10 compatible.

When group 2 support is going to land, this should be Drupal 10 only. Would that then also be group 3 compatible? Or would we have to do that separately?

The answer to that question would then be relevant for what branches of this module would be required. I mean, this could be 2.1, if it's group 2 only. But we could even go to 3.x if it were to support both group 2 and 3.

leeksoup’s picture

leeksoup CreditAttribution: leeksoup commented

Wondering what the current status on this issue is. I would like to update groups to 3.x but cannot due to group_forum requiring groups ^1.x

With Drupal 10.2.x there is also a conflict between older VariationCache and the core dynamic_page_cache module. admin/modules shows that group_forum requires VariationCache. Should I file a new issue on that?

leeksoup’s picture

leeksoup CreditAttribution: leeksoup commented

@ekes - I just installed and tried your 2.x compatible branch but am getting errors on every site page.

Also getting the foll error when I try to clear / rebuild the cache using drush, which I would guess is the source of the site errors:

$ drush cr
In CheckExceptionOnInvalidReferenceBehaviorPass.php line 88:

  The service "group_permission.calculator" has a dependency on a non-existent service "flexible_permissions.chain_calculator".

Going to guess that this comes from the flexible_container module and will install it. If it is a requirement, should it be added to the composer.json dependencies for this module?

ETA: Installed flexible_permissions but cannot enable it. The UI still gives the errors on every page, and drush gives a circular reference error:

$ drush pm:enable flexible_permissions

In Container.php line 147:
                                                                                                                                   
  Circular reference detected for service "plugin.manager.group_content_enabler", path: "plugin.cache_clearer -> plugin.manager.g  
  roup_content_enabler -> drupal.proxy_original_service.module_installer -> drupal.proxy_original_service.group.uninstall_validat  
  or.group_content".

I'll roll back group_forum and try again ....

ETA2: Still broken.

leeksoup’s picture

leeksoup CreditAttribution: leeksoup commented

OK, so I was able to put everything back to 10.1.8 and then install the fork by doing the following:

  1. composer require 'drupal/flexible_permissions'
  2. cd web; drush pm:enable flexible_permissions
  3. cd modules/contrib/
  4. git clone ...
  5. rm -r group_forum
  6. mv group_forum-3349564 group_forum
  7. cd group_forum
  8. git checkout 3349564-group-2.x-compatible
  9. cd back to top level directory (above web/)
  10. hack top-level composer.lock to allow group:^2.0@RC
  11. composer require 'drupal/group:^2'
  12. cd web/
  13. drush updatedb

It seems to be working. Or at least the site isn't broken anymore.

leeksoup’s picture

leeksoup CreditAttribution: leeksoup commented

I don't know what happened before. I just put back flexible_permissions^1.1 with composer and this time it works.

After updating to D10.2.x it broke again ... this time due to flexible_permissions and its variationcache dependency. I was able to get it to work again after modifying flexible_permissions to use the new core variation cache. Not certain I got everything, but this is working for me: https://github.com/leeksoup/flexible_permissions on the use-core-variationcache branch