OG Access port

joelpittet → credited joachim → .

joelpittet → credited pfrenssen → .

joelpittet → credited tatarbj → .

joelpittet → credited zerolab → .

joelpittet → credited Maarten Segers → .

joelpittet → credited gordon → .

Adding labels as tags and adding @gordon

claudiu.cristea → made their first commit to this issue’s fork.

I did a fist look the module. Before jumping into details, I have 2 architectural concerns:

1. Why not moving this functionality to a new project? It would make the development and maintenance more easy. OG already has a big code surface and it will become more and more hard to maintain. Having OG Access as separate project, in the OG ecosystem, would speed up development, I guess.
2. Shouldn't we benefit from the new, amazing Access Policy API → . We can create our own access policy and checking the OG group context. Note that Group module is doing something similar by relying on flexible_permissions (which is now added in core as Access Policy API → )

Apart from that, if I'm not mistaken, the solution from the MR only covers nodes (group or group content). But we need a solution to cover any type of entity acting as group or group content

@claudiu.cristea I agree that moving this to a separate module in the OG ecosystem could streamline development and help with maintenance over time. Keeping it distinct would likely simplify its evolution without adding further load to OG itself.

My initial testing of the port was promising as-is, given that it’s a direct port, but I see the value of exploring the Access Policy API. Perhaps for a 1.0 release, we could keep it node-centric as originally designed, then immediately open a 2.x branch to explore re-architecting it with Access Policy API integration. This way, we can establish a stable base while paving the way for more flexible group context handling.

As for the scope, you’re right; the current solution focuses solely on nodes, consistent with the D7 implementation. Expanding to support additional entity types as groups or group content would indeed be beneficial as we move forward, though again I would recommend doing so in a 2.x branch of the separated module.

This port has been moved to it's own project: https://www.drupal.org/project/og_access →
Please use that if you need this functionality that was provided in D7.

Thanks, guys. Moving to another module is a great idea.

> Note that Group module is doing something similar by relying on flexible_permissions module (which is now added in core as Access Policy API)

It may not fit into OG access, which has a field to determine if it's private or public (and write a record into the node grants system). But it can likely be used in OG core, where we do some heavy lifting to decide if a user has access. In fact, some years ago, as we prepared for this blog post @kristiaanvandeneynde has mentioned he had plans to get this functionality out of Group. We also said it would be nice for both Group and OG to rely on it. Ideally, reducing both of the module's own code.

Automatically closed - issue fixed for 2 weeks with no activity.

joelpittet → closed merge request !17