Contrib.social

Leverage the new access policy API ?

Open on Drupal.org →
Created on 10 March 2025, 2 months ago

Problem/Motivation

We are facing an issue in our project where we would need a way to dynamically alter OG permissions.
Our scenario is rather simple: if a member has not accepted the latest group's Code of Conduct then he remains a member but cannot interact within the group (e.g. create content, comment etc). This CoC may be updated anytime which triggers a new acceptance requirement for each user/member, along with limited permissions.

So we need a way to dynamically revoke OG permissions. Or better yet, swap the OG role permissions from "member" to a new "restricted-member" role we would create.
I focused my attention in \Drupal\og\OgAccess::userAccess
hook_og_user_access_alter may offer a way to do this, but I do not see how the example given in the readme even works, because of the !in_array($permission, $permissions) condition there.
If I'm not mistaken, this condition means that we cannot revoke permissions which have been granted to an OG role, so the example is wrong. If correct, this probably belongs to its own issue.

Proposed resolution

I wonder whether it would be possible to leverage the new access policy API introduced in core 10.3 https://www.drupal.org/node/3385551 →
This was introduced by the drupal/group maintainers and they leverage it in there.

So I started a branch as POC. Thoughts/opinions on this are most welcome.
PS: Obviously, this is a breaking change so belongs in 2.x.

✨ Feature request
Status

Active

Version

2.0

Component

og.module

Created by

🇧🇪Belgium herved

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @herved
  • Merge request !33Draft: POC access policy API. → (Open) created by herved
  • Comment 2 months ago →
    🇮🇱Israel amitaibu Israel

    Thank you @herved, the idea of leveraging the access API has indeed came up in the past, and it would be a nice addition. So happy to see your PoC!

    Specifically, for your use case, I would approach it by adding a new "CoC member" OG Role. A "regular" Member wouldn't have those permissions.

    Remember that `Create Content` is a bit more complex, since at the time the user is presented the form to create the content, that non-saved content doesn't belong to any group yet. So you'd have to rely on some `OG Context`/ prepopulating the reference to the group.

  • Pipeline finished with Failed
    2 months ago
    Total: 536s
    #444605
  • Comment 2 months ago →
    🇧🇪Belgium herved

    POC branch added, functional and kernel tests are passing, I only skipped unit tests.
    I left a few todos.

    My only major concern on this approach is that although the AccessPolicyProcessor caches things (statically and persistently) it can get quite expensive to load all memberships and groups to compute all permissions for a user, especially if he belongs in thousands of groups. Although that seems to be what drupal/group does...

  • Comment 2 months ago →
    🇧🇪Belgium herved

    Thank you both, this is still a rough POC.
    Indeed maybe using a "validated-member" OG role could be a good compromize for now.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024