Advice needed for tailoring Discourse to my organisation

[Alexander_Wright]

I’m the IT director for CAMRA. We’re an organisation of 190,000 people with roughly 20,000 active volunteers organised into a branch and region structure.

I’ve had success with implementing Discourse, and we now have 1400 users, with over 700 active every month. I’d like to have a push to recruit more people. One of the desired features is to have region and branch categories, but I’m worried that we’ll end up with 250 odd categories that will clutter up the interface. Members are typically interested in their own branch and region, and would not want to see discussions occurring in other branches.

We’re implementing oauth to authenticate users, and thus can add their branch and region to their user details.

What is the best implementation pattern for us? At the moment, I’m thinking of having a group per branch and using that to authenticate each category, but as above, I’m worried about clutter.

Ideally I’d have a My Region category that automatically mapped to that member’s region. Is this possible with plugins, or would it require major modifications?

Finally some paid help would be welcome. Offers please!

[Mittineague]

IMHO, this sounds more like a community heirarchy rethink would be best.

@Alexander_Wright

Is this possible with plugins, or would it require major modifications?

Yes.

Seriouly though, could you expand a bit more on how you envision things working, or better yet, a mock-up?

[jomaxro (Joshua Rosenfeld)]

@Alexander_Wright

We’re implementing oauth to authenticate users, and thus can add their branch and region to their user details.

@Alexander_Wright

Ideally I’d have a My Region category that automatically mapped to that member’s region. Is this possible with plugins, or would it require major modifications?

One possibility would be to implement Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) instead of OAuth. If you track the user’s region in your system, then when they sign in via SSO you can use the add_group payload to add them to a group for this region. You could them make a category per region, with security settings so they need to be in the group for that region to see it. While you’d still end up with tons of categories (and I agree a rethink of this wouldn’t be a bad idea), normal users would only see public categories and the category for their region, not all 250 categories.

One possible way to organize this would be to use tags instead of categories. You could have 1 category for regional discussions, and they users could add tags for their region. While users would see everything, they could update their notification settings to track or watch their region tags. For more details on tags, see our recent blog post.

[scombs (Steve Combs)]

I think expecting users to tag things reliably or at all is tough, especially on mobile.

I would like to see auto/default tag settings on a per category basis as discussed at Topic auto tagging

Could be used to group the branches and/or languages by region for each category. I have a similar org structure but want tags for subcategories with events and galleries so the topics can all roll up across the org.

Using private groups really locks things down and could limit a lot of good discussions/searching.

[pfaffman (Jay Pfaffman)]

I’ve been a fan of CAMRA for a long time, and I live in the states. I’d love to help out, though it’s not clear from what you posted, just what the constraints are.

If whatever database you have knows what region people are in, then it’s not that hard to update group membership accordingly. There are some things you can do like hiding regional groups from the home page, add, maybe add categories to users’ ignore lists via API.

[Alexander_Wright]

Hi, thank you all.

Unfortunately, our structure is dictated by geography, so we’re stuck with our branch and region model.

We want to continue to use oauth, as there are a number of other sites we wish to share the authentication.

Expecting our users to tag things correctly is not realistic, sadly.

Where we are

I’ve set up Discourse with a small number of categories: Volunteering, Campaigning and Support. With a small amount of promotion we now have 1500+ users, with more than half active each month.

I’m currently using the basic oauth2 plugin.

Requirements

Every user belongs to a branch and a region, and this information is available from the oauth server.

Upon successful authentication, we need the following to happen:

• Login the user keyed by their membership number, not email address (in case the email address has changed)
• Assign the user access to the correct branch and region category
• Allow users to join other branch and region categories if they want to.
• Ideally have virtual categories of “My Branch” and “My Region” that would point to those categories. (icing!)

So, the Category page would have a listing thus:

Support	Accessible by everyone
Campaigning	Accessible by everyone
Volunteering	Accessible by everyone
My Branch	The user's branch category
My Region	The user's region category
Branches	All the branch categories (muted by default)
Regions	All the region categories (muted by default)

I’m uncertain as to whether the branch and region categories should be muted by default, or access controlled by groups. Suggestions welcome!

@pfaffman has suggested he can help with development; I’d welcome help with my intended approach!

[outofthebox (Carson)]

Hi Alexander, I’ve been working with @pfaffman on our migration to Discourse and he has been excellent, incredibly detail oriented, and a pleasure to work with.

[Alexander_Wright]

Thank you for the recommendation!

[HAWK]

I would strongly recommend against setting up ~250 categories. Categories are very resource hungry and an architecture that relies on hundreds of them is not sustainable long term. I’m currently working with clients to reduce their category overhead in favour of tags.

I understand that tagging enforcement involves behaviour change but that isn’t hard to drive if you message it properly.

[codinghorror (Jeff Atwood)]

@Alexander_Wright

One of the desired features is to have region and branch categories, but I’m worried that we’ll end up with 250 odd categories that will clutter up the interface

Can you clarify exactly how many regions there are? And how many branches there are?

[mikechristopher]

The issue with tags is that you cant restrict viewing of certain tags by groups. We have a similar issue in which we use a large number of categories for our model in that we have private groups of people who have access to categories. I do however want to trial it with group messaging over categories to see if that works just as well.

[HAWK]

@mikechristopher

The issue with tags is that you cant restrict viewing of certain tags by groups.

Correct. Security is a category function and that is a legitimate use of categories.

[Alexander_Wright]

@codinghorror

Can you clarify exactly how many regions there are? And how many branches there are?

At the moment we have 220 branches. This figure is not likely to change more than 10 in either direction. We’re an established organisation. We have 17 regions. Again, this is not likely to change.

Apart from the general categories, users are interested in only their branch and region. The topics contained therein will be geographically specific, and so will not be of interest to others, in general.

[Stephen]

Are you ok with the idea that if someone moves region they will be unable to view content from their old region?

What about if users want to share stuff cross-region?

[Alexander_Wright]

@steve_pd

Are you ok with the idea that if someone moves region they will be unable to view content from their old region?

The way I’d see it working is my magic virtual category would track their current region (and branch) but users could gain access to other regions if they wanted to.

@steve_pd

What about if users want to share stuff cross-region?

It would be up to the moderators to move stuff to the general categories.

Good questions both!

[angus (Angus McLeod)]

As @hawk pointed out, Discourse is not really optimized to have hundreds of categories. One aspect of the performance issue is that the Discourse site model loads every category when it is created (see here). So even if you achieve your desired functionality, you may find that your 250+ category instance starts slowing down and you’ll either need to modify your environment, or modify various aspects of Discourse’s server and client logic to load categories more selectively (or both).

However, with the performance issue firmly in mind, the functionality / UX you’re proposing is possible. I have done something similar to this in an ‘unreleased’ plugin (It’s here). It won’t work for you out of the box though, and it does a whole bunch of other things you don’t need. I can provide some ad hoc advice and assistance to whoever works on your version of this, but I’m not available for hire or to focus on a project like this.

If someone attempts this, what you need is:

• User custom fields storing the region and branch category ids (cast them as integers).

• A new /user route that allows the user to change their region and or branch (explainer text + category drop downs). e.g.

  

  There is a user-main-nav plugin outlet for the button and you’ll need to add a new user route.

• A migration or some other auth logic to set the user’s initial region and branch.

• Discovery route redirects to the region / branch categories. Probably just on the / and /categories routes, which still allows the user to visit other categories, but will direct the user to their branch / region in most instances, e.g. when they click the logo in the top left. Something like:

   DiscoveryRoute.reopen({
     redirect() {
       const user = Discourse.User.current();
       const path = window.location.pathname;
       if (path === "/" || path === "/categories") {
         DiscourseURL.routeTo('c/' + user.branch_id);
       }
     }
   });
  

There are a few ancillary issues that you’ll face, for instance:

• Do you want to place restrictions on when / how often a user can change their region / branch? (my implementation of this is here).

• Do you want branch or region specific moderators? I created a separate plugin for this actually: Moderator Extension

Probably others that I’m forgetting atm.

The bottom line is that the functionality / UX you’re proposing is doable, but the performance risk is not insignificant.

[schungx (Stephen Chung)]

It is a legit use for organizations. I have about ten world regions plus around 100 countries. Mine is easier because not many countries are currently active but I hope them to be in the future.

I also allow people to read from other countries to share knowledge, so read access is less of a concern than reply/post access.

[Alexander_Wright]

Thank you all for your help. Discourse is a top notch community!

@angus

• A new /user route that allows the user to change their region and or branch (explainer text + category drop downs). e.g.
• A migration or some other auth logic to set the user’s initial region and branch.

I’ll not need this; branches are assigned (and changed) by the membership system that provides the oauth.

[codinghorror (Jeff Atwood)]

Hundreds of categories (particularly low-hundreds) isn’t ideal but it is possible and should perform reasonably. It’s when you get to thousands of categories that it starts being a Very Bad Idea.

[schungx (Stephen Chung)]

Luckily there aren’t that many countries in the world…