Simplified badge management for new and existing users

I’ve found that in-person conferences and workshops are a great way to build up community membership by personal invitations. For those who attend such conferences and workshops, I’ve been manually granting badges rewarding them. This works well enough for existing forum members, but once I have to start manually awarding ~300 badges one at a time, it’ll be a different story. The flow is particularly awkward for new members. Taking everything into account, my current workflow is:

  1. Get the list of email addresses for all attendees.
  2. Use the search box on the “Users” page to check who’s already a member.
  3. For existing members, grant them the appropriate “attendee” badge, and remove them from my list.
  4. Bulk invite the remaining people using the list.
  5. As people accept the invitation, grant them the appropriate “attendee” badge.

As you can see, this process is really quite labour-intensive.

To alleviate these issues, I’d like to propose two features:

1. Bulk badge management

Or, more generally, bulk user actions.

The essence of this is that you need to a) select a list of people, and then b) perform some action on them. I’ll focus just on badges; to my mind, this could look something like this:

[details=If you want to play along at home, you can run this snippet]

[...document.querySelectorAll('tr.user > td:nth-child(1)')].forEach(el => {
	let checked = Math.random() > 0.4;
	el.innerHTML = '<input type="checkbox"' + (checked ? ' checked' : '') + ' style="vertical-align: middle;margin:0 8px 0 0;"/>' + el.innerHTML;
	if (checked) { = '#25b3fd'; = '#fff';
		[...el.parentNode.querySelectorAll('a')].forEach(a => = '#fff');

You'll see that each user now has a checkbox alongside their avatar, and there's a button labelled "With selected". This button should only show when selections are made, and the checkboxes should follow the normal Discourse conventions of only being shown when you click a "select" toggle in the table header.

The "with selected" button is a drop-down menu, with options that include (for example)

* Grant badge
* Block
* Suspend
* Others?

When "Grant badge" is clicked, a modal dialog should be shown which allows you to select a badge from the drop-down list as normal. When the "OK" or "Save" button is pressed, the badge is granted. If it can only be granted once, then it is not re-granted to those who already have it. In this scenario, it is not possible to link the badge to a particular post as a reason.

When "block" or "suspend" is clicked, a confirmation dialog is shown before the action is performed.

### 2. (Invited) user tags

To make it easy to grant badges to new users, it needs to be straightforward to find them. (I had originally considered some way of "pre-badging" users during invitation, but I think that that's probably less generally useful.)

To this end, I propose that "tags" be added to users. These tags would only be visible to administrators, and would show up in user lists, and could be used for filtering. This would mean that not only could you find users who deserve a specific badge and award it, but you could also quickly build "watchlists" of potentially problematic users, or quickly find people in a particular state or country, for example.

These tags would be editable on the user management page -- exactly as groups are. It would furthermore be necessary to add these tags to invited users during the invitation process -- but I would suggest only for bulk invitations. The bulk invitation popup would then let you not only upload a file, but also select a tag or set of tags to be applied to the users.


Hopefully this all makes sense! I know that these changes would make a big difference to my workflow in Discourse, and my hope is that these changes are sufficiently generally useful to warrant development and inclusion in the base Discourse install.

One interesting option here would be to use groups.

You can bulk add to groups in the UI so you could create a group of all the users that attended conf X. Then create a SQL badge that assigns a badge to all members of the group.


And what happens when addresses that are not members are bulk added to groups?

That’s a good workaround for existing users, thanks! As @pfaffman alludes to, it won’t solve the issue with users which don’t exist yet, but perhaps changing my second suggestion so that you read “group” where you see “tag” (s/tag/group/g) would be a good step.

When you send out invites or bulk invites you can automatically add users to a group.


Of course you can – silly of me to forget.

I’ll go down the path of using groups for now then – it’ll definitely save me a lot of effort. It’s probably still not a bad idea to make bulk badge management more straightforward (perhaps as I’ve outlined above), but certainly less pressing for me with this workaround. :slight_smile: