DrupalのGroupモジュールを好んで使い、顧客にも推奨している。執筆時は利用サイト数が16千件を超えていてSlackも活発だ。関連して、Group Membership Requestモジュールがある。既にサイトのアカウントを持っている人が、特定のグループに参加リクエストを出し、権限を持つ人がその参加を承認できるようにするものだ。
Groupの概念はシンプルで、Group relationshipというエンティティを用いて、Groupエンティティとコンテンツあるいはユーザーを結びつけ、アクセス権を制御する。特定のグループがどのようなコンテンツを管理できるか、そのアクセス権をどうするかを決めるのがGroup Typeで特定コンテンツタイプの作成・編集をGroupメンバーに限定したり、Group内のみの閲覧許可にしたり、出来上がったものは全面公開にするなどの設定ができる。厳密には、コンテンツ(node)との対応付をするのはGroup Nodeというサブモジュール(gnode)で実現されている。
Group relationshipは基本Groupエンティティとコンテンツのペアから成り、フィールドを追加することができる。対象コンテンツがユーザーか、特定コンテンツタイプのコンテンツかを解釈する必要があり、それに対応したプラグインが定義されなければいけない(Group relationship type)。Groupモジュールで、ユーザーとグループの関係を定義するプラグインは実装されていて、コンテンツタイプとの関連付けはgnodeで実装されている。Group Membership Requestモジュール(grequest)では、ユーザーと結びつけるプラグインが実装されていて、Group relationship typeはGroup membership requestとなっている。
この実装で特徴的なのは、このGroup relationshipには「Approved/Rejected by」（user）と「Request status」(State machine)が定義されている。
「Request group membership」というグループ権限を有する人が、参加申請（Group relationshipの作成）ができる。一般には、サイトのアカウントを持っている人全員(Outsider)に与えることになる。
「Administer membership requests」というグループ権限を有する人が、承認することでGroup relationship(Group membership)が作成されて、晴れて申請者がグループメンバーになる仕組みだ。該当Group relationshipで承認者や承認状況を確認できる。
組織が大きくなれば、権限の絞り込みが必要になるし、特に便利だと思うのは、edit own、edit anyの制御で、Group内に限ってedit anyにすることができるところにある。さらに、Group nodeの対象コンテンツにワークフローを設定しても問題なく機能するので、部門内執筆権限と、公開権限を柔軟に設定することができる。ただし、ワークフローモジュールは、グローバルな公開承認ロールの割当が必要になるので、特定グループで公開承認ロールを機能させたいと行った粒度のアクセス制御は困難だ。
Group Content Moderationモジュールでこの問題で対処できそう（Why do we need this module?）だが、確認はできていない。
興味深いのは、Group Membership RequestモジュールもGroup Content ModerationモジュールもEuropean Commission and European Union Institutions, Agencies and Bodiesが支援している点である。どちらのモジュールも利用サイト数は1,000を下回っていてまだSecurity advisoryによる承認はおりていないことには注意しなければならないが、私は今後の高度化に大いに期待している。また、ユースケースを想定してレシピ化されていくのではないかと考えている。レシピを書ける人に成りたいと思っていて、沼にハマりかけている気がしている。
※検討した段階では、GroupMembershipRequestValidator $context type missingという問題に引っかかって、パッチを当てるまで正常動作せずちょっと難儀したが、grequest 3.2.4が2025年9月1日にリリースされて問題なく利用できるようになっている。