We’re in the process of launching a community on Discourse. Since the nature of the community is generally religious, our stakeholders seem intent on having a very closed membership (keeping the conversation in the family). Initially membership was dependent on being a member of our organization, A
The trouble is that as word has gotten out, other groups (B and C) have wanted to jump on board, while still maintaining a closed membership. We’re having difficulty using/coming up with a system to maintain current member lists across multiple organizations. It seems fairly simple to add new members from A, B, or C manually, but going through and removing old/closed accounts as they are updated within each org seems really difficult.
Has anyone else had this particular problem? Our IT team said that it doesn’t seem like we can run APIs to check against multiple organizational datbases (A, B, and C).
I hope I have explained this clearly. I apologize if this is in the wrong section (and unclear, I’m usually content, not IT!). I originally asked this in the Feverbee forum but @HAWK suggested I bring it onto here
Do the members from different organizations want to be able to talk to each other? (If not, then just get 3 Discourse instances).
Do the members from each organization have email addresses like pat@org1.org, joe@org2.org? Then you can use those email addresses to assign them to groups.
Can you get the 3 organizations to run a script that will add/delete members via API when they do their membership maintenance?
I don’t quite understand what auth0 is, but there’s a plugin for it and I’ve configured it for a client recently. They apparently “solve the most complex identity use cases with an extensible and easy to integrate platform that secures billions of logins every month.”
Yes, the three (or more) groups do want to have a category that is open to all groups to allow for some cross-talk and collaboration, so we’ve imagined the Discourse instance as having top-level categories assigned to each group, and one (or more) assigned to all groups.
Most of these groups are associations of individuals from their own orgs, so there isn’t a consistent email naming convention.
I’m curious about the API part, because out IT group seemed to think this was a problem because we’d be checking against three or more separate databases (we don’t have current member data from the other two)
My solution would be to have each org run a script that updated your Discourse. The other solution, which wouldn’t require you to give them the API keys to your kingdom, would be a script that queried their database and then updated your Discourse. The simple solution would be to do it as a cron job on some other system (probably not the one running Discourse, though I suppose it could be).
I think we’d be more comfortable with the second solution. Would you be able to explain a little more about that process? I’m unfamiliar with Discourses ability to systematically remove users that have been removed from the database being queried. This is the sticking point for our stakeholders, as they don’t want someone who has been let go from their org, and thus the association database (once the org makes the change) trashing them on the Discourse site. It’s (hopefully) not a terribly likely scenario, and one that can be mitigated with dedicated mods, but we’re sure to be asked about it.