@sam What do you think about this idea? Is it something that’s likely to be added?
We just started our community and are rolling out to a number of different audiences in stages. The first audience is general and doesn’t need to be added to any groups, but our next audience will be a specific group that should get special treatment.
Allowing groups to be specified via SSO is fine, my pref would be for 2 keys
groups: [group1,group2,group3]
remove_groups: [remove1]
That should allow you full fidelity here, should be fairly straightforward to add. We can slot it for 1.7
Glad to hear this is something you can support.
The only issue I see with having a remove_groups flag is that I will need to know what groups the user is no longer a member of to remove them. What about supporting three keys:
groups: [group1,group2,group3] # ensure user is only in groups1, group2, and group3
or
add_groups: [group4] # ensure user is in group4
remove_groups: [group2] # ensure user is not in group2
This way, my main app can handle all the logic and Discourse will simply be kept in sync.
I think the only way that works is the second one, because otherwise the membership of any group you create through the Discourse UI will have its members removed as they re-log.
The remove groups parameter would then be managed_group_list - user.groups (inventing the terminology of a “sso-managed group” for the sake of this post).
We can revisit that design if the managed groups list gets too big.
That’s the desired behavior for me. I don’t want people managing user groups in the discourse admin. I want our main app to have full control of group memberships.
This is now completed per:
Sorry to re-open this, but I’m trying to make sure I understand what was (or wasn’t) done to solve the use cases presented earlier.
I’m also on SSO. With a Discourse hosted site. We want to have a private forum where we can invite people select people, but unfortunately it’s not tied to a parameter we can identify and pass via SSO.
We want to upload a list of email addresses that, if/when a user signs in for the first time they are auto-added to the group. We are using the domain solution for some groups, but that wouldn’t apply in this case.
It looks like this was discussed, but it’s unclear to me which solution was ultimately chosen. I tested with an email address that was registered in our main userbase, but hadn’t logged into our discourse site to initiate the SSO. When we logged in with that ID the account created but he’s not in the group.
SSO ユーザーをメールアドレスのリストに基づいて事前にグループに追加する方法を見つけました：
email_time_window_minutes 内でそのプライベートメッセージを削除してください。SSO が有効な場合にメーリングリストをフォーラムにインポートする際、これは非常に役立ちます。
（スレッドの「ネクロマンシー」になってしまい申し訳ありません 
– 2 年経ってもこの質問は未解決のようですし、他の場所でこのアドバイスを見つけることができませんでした）
それでも、通常の「ユーザー招待」機能が SSO と連携すれば、この作業を 1 段階で完了でき、モデレーターも実施できるようになるため、実現するとより良いと思います（現状では、ステップ 2 は管理者のみが実行できるようです）。
@RyanK / @tobiaseigen これで閉じても問題ないと思います。招待はSSOとの互換性が非常に高くなったはずです。過去2年間で多くの進歩があり、ネイティブでユースケースに対応できるはずです。
はい、これで大丈夫だと思います。招待したユーザーがSSOまたはサイトが提供するその他のログイン方法でログインすることが可能です。招待の設定方法によっては、招待されたユーザーはログイン時にグループに追加されたり、特定のトピックに配置されたりします。素晴らしいですね！
ここでの議論のほとんどは、実際には「SSOによるユーザーのグループへの追加と削除のサポート」に関するもので、私はこれについてあまり詳しくなく、ここメタでのドキュメントもあまり見かけません。詳しい人がFAQを作成して、わかっていることをまとめることができるかもしれません。これは、SSO経由でログインする際に、ユーザーをグループに追加または削除することを可能にしますが、実際には招待システムとは関係ありません。
これは、WordPressを使用して実装する方法の@simonによる良い例です: Automatically Adding New Users (from WP integration) To A Group - #4 by simon
ただし、注意点もあるため、この方法を実装することを推奨するのは得策ではないかもしれません。Discourseのグループは、これが機能するために既に存在している必要があり、認証プロバイダー側の変更を有効にするには、ユーザーがログアウトして再度ログインする必要があります。