Group nodeサブモジュールを使って、集団でコンテンツを作り上げていく、あるいは開示範囲を限定したコンテンツを作り上げていくというのが基本となるユースケースだと思う(DrupalのGroupモジュールに高い可能性を感じているが、権限のモデリングは非常に難しい)。Drupal 9 おいしいレシピ集 (技術の泉シリーズ（NextPublishing）)でも執筆した。
割と単純なことのように思えるが、実は権限の共有はとてもむずかしい。同じグループに属していても、その中でも読むだけ、記事を作成できる権限、どの記事も編集したり削除したりする権限など容易ではない。複数の人がコンテンツの編集に関わるようになると、やがてワークフローの設定は不可避となる。DrupalのCoreにはContent moderationモジュールが含まれていて、標準のワークフローが定義されているが、現行のGroup 8.xでは、このContent moderationを使うためにはGroup Content Moderationが必要となる。以前、Drupal Group Content Moderationモジュールを試してみたという記事を書いたが、残念ながらほとんど利用されておらず、今もベータのままである。
group 2.0.0-beta1のリリースノートには、The "finally doing things right" releaseと書かれている。8.xの経験を踏まえて2.xでは、権限の扱いが大幅に見直されている。特にAccess bypass permission is goneは潔い。group 2でもgroup 3でもサイト管理者がGroup typeをデフォルトのままの設定で（例えばOut of the boxという名前で）定義し、管理者がGroupを作成して、グループ一覧を見ると、自分が作ったグループが見えないのである。アクセスバイパスが効かないので、自分が作ったグループでも何もできない。見られるようにするためには、以下のようなロールをGroup typeで設定すれば良い。
この設定を行うことによって、作成者はGroupのメンバーなので、Insiderかつ通常のロールで管理者、GroupとしてのAdmin roleにチェックが入れてあるので、Groupの管理者になる。初めてGroupの全てが管理できるようになる。ただ、サイトに複数管理者がいる場合は、他の管理者はOutsiderなので何も見ることができない。管理者にアクセスバイパスを許すためには、Outsiderの管理者にもAdmin roleを与える必要がある。そういう設定にしても良いのだが、作者の思想に従えば、むしろサイト管理者にはGroupに関する最低限の権限を与えるようにした方が良いだろう。
前後してしまったが、権限設定がRoles and their UI have been reworkedとあるように、一般のロールとマップできるようになったため直交性が高まり、Group 2/3ではもはやGroup Content Moderationモジュールは必要なくなる。Groupのない世界で考えてみればわかるが、基本ページや、記事といったコンテンツタイプ毎にContent Moderationを定義する必要はなく、操作権と承認権は独立している。同様にGroupメンバーとしてコンテンツの操作権があれば、Content Moderationは一般のロールに対して権限を割り付けておけば良い。もちろん、とても細かく制御しようと思うと、組み合わせの数だけロールを定義しなければいけなくなるので事前によく考えておいたほうが良いのは言うまでもない。
group 3.0.0-beta1のリリースノートには、The "all good things come in pairs" releaseと書かれている。これを読むと現時点の中身は一緒で、名前付けがcontentからrelationに変わっただけなのがわかる。group 2のリリースノートにSponsored by ANNAI: Configuration entities can now be groupedと書かれているので、group 3以降ではcontentに限られない関係性定義になるのだから名前から変えようということだろう。
Webformはconfiguration entityでWebform submissionはcontent entityなのはヒントとなる。Webform submissionに対してグループ権限で管理したくなるのは当然で、メタ情報であるWebformもグループ権限を適用できるようにできるということだ。現時点では、Webform nodeを利用し、対応するnodeをグループ管理下におけば、グループ権限を適用できるということ(The Webform module now provides Group integration for submission management)だが、Group 3以降では、もっと依存関係の少ない実装が可能になるだろう。朗報だと思う。うまく普及したら、ANNAI社の貢献は大きい。
話を権限設定に戻す。
Groupの権限とサイトの権限を切り離して考えるという理念に根ざすと、前述のようにサイト管理者にはGroupに関する最低限の権限を与えるようにした方が良い。様々な考え方はあると思うが、私はGroup typeの基本形として、以下の設定を推奨したい。
まずThe group creator automatically becomes a memberを外す。グループを作る権利はサイト管理者（あるいは特殊なロール）に持たせたほうが良く、グループを作成する人がグループに所属する必要はない。むしろ、管理者はグループに所属させないほうが良い。そして、Automatically configure useful default rolesとSutomatically configure an administrative roleはオンで良いだろう。特に後者は、グループの代表者となる特定のユーザーに付与されるべきものなのでサイトの権限と連動するInsider権限にするより好ましい。
この状況でGroup typeを作成すると権限は以下のようになる。
これだけだと管理者がグループにタッチできないので、Outsider 管理者ロールを定義して、グループそのものへのアクセス権とAdminister group members権限を付与する。グループメンバーの管理権を付与することで、グループ管理者を登録し、Admin権限を付与することが可能になる。どうしても必要であれば、自分をグループ管理者として登録しAdmin権限を付与すればグループ管理の全権を掌握できるが、介入せずに指名したグループ管理者にお願いしてすすめるのが適切だろう。
これで基本形は固まる。この後、Group nodeやContent moderationを設定していくことになるが、それらは別途別記事としたい。