@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.
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.
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.
This is the way I found to get SSO users pre-added to a group based on a list of e-mail addresses:
Send a private message, pasting the e-mail addresses into the recipients field (supported since August 2017) to create “staged” users. (Delete the private message within email_time_window_minutes if you don’t actually want to send anything to the users)
Add the staged users to the group, either:
One-by-one, on each user’s admin page
Use “Bulk Add To Group” on the group page, and paste in the same e-mail address list
This is really helpful for importing mailing lists onto a forum when SSO is enabled.
(Sorry for the thread necromancy – seems like the question is still open 2 years later, I couldn’t find this advice anywhere else)
It would still be nice if the normal invite users feature worked with SSO, so this could be done in one step (and so moderators could do it, currently it seems like only admins can do step 2).
@RyanK / @tobiaseigen Sono abbastanza sicuro che questo possa essere chiuso, gli inviti ora dovrebbero essere super compatibili con SSO, abbiamo fatto enormi progressi negli ultimi 2 anni e dovremmo essere in grado di gestire il tuo caso d’uso in modo nativo.
Sì, penso che possiamo chiudere. È infatti molto possibile invitare persone che poi accedono tramite SSO o qualsiasi altro metodo di accesso fornito dal sito. A seconda di come è impostato l’invito, l’utente invitato può essere aggiunto a gruppi e inserito in un argomento specifico al momento dell’accesso. Molto bello!
La maggior parte della discussione qui riguarda in realtà il supporto SSO per aggiungere e rimuovere un utente dai gruppi, di cui ho meno familiarità e non vedo molta documentazione qui su meta. Qualcuno più esperto potrebbe scrivere una FAQ per raccogliere ciò che si sa al riguardo. Permette agli utenti di essere aggiunti o rimossi dai gruppi al momento dell’accesso tramite SSO, il che in realtà non ha nulla a che fare con il sistema di invito.
Ci sono però delle avvertenze, quindi forse non vale la pena incoraggiare le persone a implementare questo metodo. I gruppi di Discourse devono già esistere affinché ciò funzioni e richiede all’utente di disconnettersi e riconnettersi affinché eventuali modifiche sul lato del provider di autenticazione abbiano effetto.