はい、ようやく作業中の成果物を共有できます。
いくつかの注記です。
初期の実装では、Google Apps HD グループのやや複雑なケースを選択しました。これは、プロバイダーからのドメイン固有のグループを考慮する必要性など、考えられる組み合わせを整理するのに役立つと思うからです。
このユースケースを実装するために、認証の時点で「二次認証（secondary authorization）」という新しい概念を導入し、段階的な認証を可能にしました。特定のユーザーのグループ権限（HD で認証している場合など）を要求する方法についていくつか検討しましたが、これが最も現実的だと判断しました。これは予想以上に大きな変更かもしれませんが、議論の価値はあると思います。
なお、Google HD グループのケースを実装するには、Google Apps HD グループの管理者以外のメンバーに、グループの一覧表示（管理者ディレクトリ API を通じて）を行うための委任管理者権限を付与する必要があります。これに役立つ「Groups Reader」という「ベータ」プレビルドの管理者ロールが実際に存在します。詳しくは Prebuilt administrator roles | User management | Google Workspace Help をご覧ください。
Google の実装は機能しています。設定後に HD で認証すると、Google HD グループが自動グループメンバーシップ設定で利用可能になり、その HD グループが選択されている場合は Discourse グループに自動的に追加されます。グループが削除された場合は削除されます（両方のアクションは詳細にログ記録されます）。また、その Google HD グループに所属する他のユーザーが認証すると、即座に追加されます。
詳細はコードと仕様から明らかでしょう。また、3 つの新しいテーブルを追加したことに気づかれると思います。より「軽量」なソリューションをいくつか試しましたが、ユーザーに関連するグループやグループに関連するグループの更新を処理する際に、それぞれがより複雑で非効率なものになってしまいました。各ケースで新しいテーブルを作成するしかないのは避けられないかもしれません。データモデリング全般について、アイデアがあれば歓迎します。
上記の概念的・製品に関する質問を除き、技術的な未完了タスクがいくつか残っています。この点についても提案を歓迎します。
- 関連グループの
labelをシリアライズする（クライアント側でモデル化しない）。 - 不足している仕様と QUnit テストを追加する。
- 大量のデータが存在する場合に処理が遅くなる可能性があるため、
user_associated_group/group_associated_groupの作成・破棄をバックグラウンドジョブに移動する。