Improving the Groups page for 1.7

One of the last big things on the 1.7 release list is to improve the groups page. @tgxworld will be working on this in December, so I wanted to gather feedback and make sure we didn’t miss anything.

Here’s what I remember about it so far:

  • :white_check_mark: general cleanup of the groups page design, not a radical redesign but make it more… presentable.

  • :white_check_mark: show the group avatar (that @neil already worked on) on the group page prominently, since that is how the group is identified by all users. If you are a group owner you should be able to select the group avatar from the group page, just like a user would select their avatar from their user page.

  • :white_check_mark: add an “about me” field for groups so that they have parity with users, also, the about me can describe what the group is for, why it exists, how to join it, etc

  • :white_check_mark: add a “full name” for groups for parity with users, plus a long name can contain Unicode and be more descriptive just like a user full name - Group’s title serves more or less the same purpose as full name

  • :white_check_mark: if the group allows it, let people self-join and self-exit the group as desired. This will also require some kind of logging so group moderators know when people enter/leave

  • :white_check_mark: if the group allows it, let people apply for membership to the group, probably the easiest way to implement this is for 1.7 is a PM button that group PMs the group owners with a pre-filled title and body (we already support this).

  • :white_check_mark: We also need some sort of basic groups directory page like /users but it can be very simple for this release, to be improved later.

Some other related topics:

Probably the best way to think of this, is continuing to make groups first class citizens, as @sam started when he unified the group and username @ namespaces and added support for messaging groups, just like you’d message users.


Maybe a different context, but related, is the group page usage for @ampburner


That description sounds great. I had originally proposed a mockup for the group page but am not wed to that design specifically.

A PM seems fine, but recall that new users can’t send PMs immediately so it could limit the use case of asking new users to “please sign up for our group.” I used groups for an event and had to move the PM setting down to TL0. No need to start the “PM settings” debate again, (although I would be in favor of letting TL0 users PM admins as a setting). Seems like TL0 users would need to be able to PM group owners for this feature. If an admin or moderator is going to ask for invites, they should be willing to manage the PMs.

From a design standpoint, it would be nice to remove the left rail (or manage via CSS) since those items seem to cover posts based on users not the group?

Adding a groups page would be ideal if you can fit it in to 1.7 Thanks very much.


Excellent news :slight_smile: Been looking forward to this!


This sounds great :slight_smile: I am looking forward to seeing better integration of groups.

In that sense I would like to see that “Titles” given through groups are better integrated with badges. Currently users can’t select the title that is displayed if they are part of multiple groups. Title given through groups are not selectable by users

1 Like

What about Groups and SSO?

SSO can set groups for some weeks now.


Sorry to be such a novice here, but I don’t understand the purpose of “Groups”. I have searched in the forum and with Google, but I could not find any basic info.

Could someone please provide a link to the basics of Groups?

  • Purpose
  • Use case
  • How to use


Permissions are tied to groups and categories, for one thing.

Use cases for groups:

  • Private categories (define group; set category security for that group only)

  • Support group mailbox (create support group; assign for incoming email; allow anonymous users to email in; respond via PM)

  • create directories of users for display on site

  • create groups to assign badges

  • messaging to groups with @mentions using group name


Might be cool to show this helper text on the blank groups directory once we have it!


It certainly gets a +1 from me! It’s been in “maybe” territory since January; if we put it off now, it could easily be another year until we revisit groups again. I’m also curious to see what a creative community admin can use a “Groups Directory” for.


Additional thoughts on the specifications for /Groups summary page and individual Group pages:

/Groups summary page


  • locate at /groups
  • list of Groups ordered by alpha
  • display avatar for each group
  • settings on each Group page for “Show Group on Groups page?” [Yes/No]

Nice to have

  • column for number of users
  • settings on each Group page for “Show Group Description on Groups page?” [Yes/No]
  • Sortable columns like /users

Individual Group page

I think the focus of individual Group pages should remain on users (not content) at least until the user features are further developed. In addition to those features mentioned, consider the following for the user page (example of current page Discourse Meta):


  • self serve add/remove/request membership (but note issue for PMs from TL0 users)
  • remove left rail; currently has posts/topics/mentions/messages (these don’t seemed to be tied strictly to group?)
  • add Group Owners area (possibly in left rail area) separate from other users
  • add About (possibly in left rail area below group owners)
  • make mobile responsive (it’s not quite there yet)
  • Support markdown or HTML in About
  • Sortable columns like /users
  • Search box

Nice to have

  • separate user field from name field (for sorting)

Content related enhancements

  • Area for private Categories related to the group (possibly in left rail area below About)
  • content areas for recent/featured content/announcements (based on group inbox?)

Groups icon

Some sites might want to consider add a Groups icon next to search/hamburger menu to allow users an easy way to navigate back to a list of groups. The manual method to set this up is as follows:

  • use Admin/Customize/CSS to add Groups icon in </head> + style with CSS
  • add Groups topic with links to various Group pages (or use /groups when implemented)
  • link Groups icon to Groups topic (or /groups when implemented)



I am the owner operator of several multi thousand member forums, and want to come onboard with Discourse. The primary feature that I need and am ‘missing’ is a robust Groups feature. I would like to know what I can do to further the fastracking of this feature within Discourse. Might I ask for a private conversation with the proper party who can most effect the advancement of this feature? Pls advise. Thanks.

Could you please expand on that here in public so we can discuss it? Please explain what’s missing from Discourse’s current groups functionality in the context of your use case.

Sure, we can talk further about that in a separate conversation. I’ll PM you.

1 Like

the group name is not allowed to be non-English. it’d be nicer if one could set the name based on the local language.

Same rules as usernames since they share a namespace.

1 Like

On my Discourse instance I use groups to manage access to “special interest” categories that users opt-in to.

For example, we keep our “robust” political discussions tucked away in a category that’s only visible to users that have read the rules and deliberately opted in to the “Politicos” group

At the moment they opt in by replying to the Politicos “opt-in” topic, and then a group owner has to manually add them as a member of the group.

This works on a small scale but it’s clunky.

I’d rather have our “special interest” categories listed on a dedicated page with a button next to each that a member can tap to opt-in to see that category.


I have a PR for this feature over at

Hmm I don’t see any significant benefits of logging members joining/leaving a group. As a group owner, I feel that stats like number of users in the group over time and number of posts by group uses over time will be more beneficial.

Perhaps we should only log when group owners make edits or kick people out of the group?

My :two: cents.


A key point for me and others will be for group owners to approve the user request to join the group. This feature is called “public group” (which it would have to be for any users to see it) but many of the use cases, like restricted categories, would need this approval feature. Can that be included in 1.7?

One reason would be to allow a group owner to send a welcome message to new users. Can we capture In the logs or, even better, display “join date”? If the user columns could be sorted that would solve a few issues in this area.

1 Like