What about an "advanced" or "guided" submission process for new topics in certain categories

I love tagging in Discourse, and the loose structure is great the majority of the time. For some use cases though, it would be great to have a guided submission that guarantees a certain set of inputs that the “optional tags” box in the standard topic creation window doesn’t give users.

My use case is this:
In a category for support requests, I want to guarantee (not just suggest via a template) that people use a specific set of tags, from a couple different categories, and they can immediately see all of the available options that the categories of tags are required.

I imagine that, in categories where this feature is enabled, clicking create topic might first open a modal. The modal would ask most of of the same, but it would have pre-determined, required tag categories/parent tags/tags as defined in the category settings.

I can certainly draw what I see in my mind, if someone wants a terrible MS paint mockup :slight_smile:


Who doesn’t like terrible Paint mockups? :stuck_out_tongue:

That would be appreciated, though, as I have a bit of trouble understanding your request fully. :slight_smile:


Tagging today is just a big, open box of “suggestions”. When I have someone submitting a support request in my support category, I need to know:

Which product are you posting about? Product A or Product B? I have a tag category of “Products” with two tags under it:

  • product-a
  • product-b

I also have some features that transcend all products, but I need to know which feature(s) you’re looking for support on. Feature A, B, C, etc. I have a tag category of “Features” with multiple tags under it:

  • feature-a
  • feature-b
  • feature-c
  • etc.

Again, for most of our forum experience, having a grab bag of tags is fine. For our support category though, people need to be very consistent and very specific. There are discourse features that sort of, kind of do this, but they’re very ambiguous. I can require x number of tags, for example…but they could choose tags from other open tag categories. Also, if a tag category has too many tags, they don’t all show up in the drop-down and so they have to know in advance, via tribal knowledge, what tags may exist.

I am proposing something like this.

  1. User clicks + New Topic
  2. Modal window comes up to create new topic
  3. Required tags to select are based on required tag groups for the category

I’m sure this could be done in the existing new topic window, I’m just horrible with actually designing front-ends to figure that out.


For each required tag group in the category settings, you could have an associated question that shows up for that tag group in the new topic UI as well.

1 Like

Hi Jordan. Many moons ago I had this plugin installed and as far as I can remember it can create topics much in the way you suggested.


I’m not sure if you already know this, but you can enforce this behaviour with tag groups and category settings. The UI gives the user some hints about how the tags need to be applied, but I’m not sure how clear the UI would be for most users.

First, create tag groups for products and features. For example:

Configure your support category’s tag settings like this:

Creating a new topic in the category, users will first see this:

Clicking on the tags input opens a drop down that only allows users to select one of the products tags:

After selecting a products tag, the user is shown the list of allowable features tags:

You could also make the features tags required by adding them to the required tag group setting that’s highlighted in a previous screenshot. The order that tags are added to the category required tag group setting seems to be respected in the UI. I’m not sure if that’s intentional, but it’s helpful for this case if you want to force users to first select a products tag, then select a features tag:


So possibly Discourse already has the functionality you are looking for, but the UI could be improved.

Related to the above screenshot, users are being shown the text “Search or create” in the tags drop down, when based on the category settings, they should only be given the option to search for tags from the features tag group. The instance of Discourse that I’m testing this on isn’t quite up to date, so I can’t confirm whether or not that is a current bug. I can test that later on. In any case, if I attempt to create the topic with an additional tag, an error is returned.

This seems like a bug, but I’ll need to update my local Discourse instance to confirm that.

Edit: mentioned a couple of issues related to this here: Tag "Search or create" text is displayed when a category has restricted tags


See…it’s close. It’s an idea that is definitely in the right direction, but it’s not quite there.

I created a new category, requiring one tag from our “Products” tag group, and two tags from our “Extensibility Features” tag group:

Here is what creating a new post looks like. The dropdown box for tags, before clicking on it, just says “select at least 3 tags…”. This is ambiguous to start, and doesn’t immediately let the user know that I’m requiring one tag from the Product tag group, and two tags from the Extensibility Features tag group. But, okay, let’s click on it:

A closer look is that:

  • The first 3 items are “Extensibility Features”
  • The next 2 items are “Products”
  • The last 5 are “Extensibility Features”
  • There are still 17 possible “Extensibility Features” tags that they aren’t aware are possible.

Here is a simple html form that better exemplifies what the user should see (of course, before any actual design):


I think there’s a need for real world use cases similar to yours to help improve the tagging UI.

This is probably because you are testing this as a staff user. Tag restrictions aren’t applied to admins (possibly not to mods either) so what you are seeing doesn’t reflect what a normal user would see.

Here’s my test with a normal TL3 user (note that it’s only allowing me to select from products at first):

Here’s what I see when I test the same thing as an admin user (tags from both tag groups, returned in alphabetical order):

This difference can lead to confusion when trying to configure tag group permissions.

Yeah, that’s a problem.


Ah, that may be the case there then—but I’d say that’s only 1/10th of the problem. I am going to try that out now though, just to ensure I’ve seen the complete experience.

I would say the majority of the issue still remains.


Similar asks have been made previously, but did not seem to get any traction.