I’m trying to understand if this is possible with a typical Discourse installation. I’ve read the topics that discuss multi-site installs - this seems to involve setting up a separate database instance for every subdomain.
I’m interested in hosting a large number (hundreds or thousands) of small (~dozens of participants, peak volume likely tens of messages per day) forums. Would be nice if possible to do this without needing to create a separate database for each forum. Thinking about Discourse as an alternative to creating lots of teeny Yahoo/Google groups.
If this is not possible out-of-the-box, is this a feasible customization challenge?
@sam, are you saying that the namespace hack might take 2 months - or that using namespaces would be quick but there’s some better solution that would require more substantial changes and that would take time.
I would consider myself a competent developer … but without any familiarity with the Discourse code. Perhaps time to get my hands dirty. Presumably this is more complicated than adding a forum-id column to the Topics table but that might be the place to start?
You definitely would not do this, this way. Its too hard, risky and there is no chance we will add a “scope” column to every table, never going to happen.
Instead look at apartment gem and how it does schema switching, you would have to port that in conditionally to rails-multisite.
You would need to handle provisioning and comms and a bunch of other stuff.
I’m thinking of an environment where there are thousands of forums, most with very light activity. Creating entire sets of tables for every one of those (as in the apartment gem) is terrifying. e.g. on software updates needing to run the migrations against N tenants. And I want an environment where provisioning a new forum is a fast & lightweight operation.
But I see your point on adding scope columns to the major tables. Probably not to everything, but it would be nice to avoid it even on the main ones. And then needing to add .where(forum: current_forum) everywhere just dirties up the codebase.
I’m going to keep hunting for alternatives. Would like to minimize overall impact.
The Guardian class looks very interesting. Perhaps that could be extended to include the concept of restricting access to subsets of the database? Separate set of scoping tables, only used when the multi-forum feature is turned on.
Yes, I know about groups. But there’s no nesting of groups. There’s some other conversation about subgroups on here, but I’m not sure that’s a good approach for this feature.
My mental model for this is for schools. One forum for each school, and groups for things like class membership, after-school activities, carpool groups, PTA, etc.
If it’s possible to stretch the existing framework to handle multi-forums, I’d rather do it that way than add a whole lot of new machinery.
I am interested in this discussion as well and would be into exploring the use cases more. It seems to me that each discourse forum should be independent and separate. But maybe not right away. At first as it is being evaluated and new forum owners and members learn the ropes it would be hosted as a group on a forum run by someone else for them, like wordpress.com for new bloggers. Eventually as the group grows and takes wings, and needs grow, it could be moved to its own independent forum.
How this would work I am not sure, but the ability to export part of a forum, Eg a group and all related users, categories, and topics, would do it.
Quick question about your model: Do your “schools” have anything in common? That is, do they belong to an overarching larger organization/grouping, (Like a network of districts), or are they simply unconnected groups that would come to you for quick, easy mini-forum setup?
I ask because understanding the relationship between the various “Schools” could help clarify how deeply these communities should be siloed off from each other.
I’m assuming no relationship between schools. So by default the siloing of topics should be complete. Allowing for some degree of “leakage” between school forums (e.g. for schools within the same district) is an interesting idea, but not a strict requirement.
User might be members of multiple forums, and I want to be able to show users an aggregated view of activity across all their forums. In the tenancy model this would require merging results from queries across N databases. I’d like to avoid that.
Category specific moderators is a feature we certainly want in core. It would be a great place to start, you just need to get that feature converted to a spec and @codinghorror can bless it once its good.
You can not create spec category topics, only we can, so… create a detailed post on that feature topic with your proposed spec and we can review it and move it to the spec category once ready.