Hi there I’m new to using form templates so hopefully this is just me overlooking something. I’ve created a form template that populates a dropdown from a tag group, which shows up correctly, but it doesn’t allow me to select anything. The category does have 3 tag groups restricted to it, with “also allow other tags” unchecked There are no categories specified in the “required tag group”, although ideally I’d like to have the same 3 tag groups specified here The yaml for my form is: - type: tag-chooser id: issue-type tag_group: "Issue Type" attributes: none_label: "Select a type" label: "Type" multiple: false validations: required: true - type: tag-chooser id: issue-priority tag_group: "Issue Priority" attributes: none_label: "Select a priority" label: "Priority" multiple: false validations: required: true The preview loads fine: [discourse-preview] But the form itself on topic creation, doesn’t allow me to select any tags: [discourse-form] All tag groups are similar in set up - [image] Any help appreciated. As I said, hopefully something simple :crossed_fingers:

Thanks, I managed to reproduce the issue locally by using mixed case tag names. FIX: Form template `tag-chooser` dropping uppercase tag selections (#40379) main ← fix-form-template-tag-chooser-uppercase merged 05:52AM - 29 May 26 UTC (UTC) [imagen] ZogStriP +51 -17 When a form template `tag-chooser` field is populated from a tag group, each ` ` is rendered with its display value (the tag name upper-cased, or its description). Selecting an option then has to translate that display value back to the underlying tag name before storing it on the composer. `handleSelectedValues` did this translation by lower-casing the option value (`"HIGH"` -> `"high"`) and `handleInput` matched the result case-sensitively against the real tag names. On sites with `force_lowercase_tags` disabled, tag names keep their casing (e.g. `"High"`), so the reconstructed `"high"` never matched, the selection was silently dropped, and the dropdown reset to its placeholder. Lower-case tag names round-tripped fine, which is why this only affected sites allowing mixed-case tags. This regressed in ed8a62e2729, which switched the option value from the tag name to the upper-cased display and reintroduced the lower-casing round-trip to reverse it. Instead of guessing the casing, build a map of each choice's display value back to its exact tag name and look the selected option up in it. Selections are now preserved regardless of tag name casing. Adds a system spec covering tag names with uppercase characters and `force_lowercase_tags` disabled.

[imagen] Parker1090: The category does have 3 tag groups restricted to it, with “also allow other tags” unchecked And does that included the tag groups you are using here (“Issue Type” and “Issue Priority”)?

Thanks for the reply! Yes, those two are included [Screenshot20260528-212948]

I’m having trouble reproducing the issue locally. @Parker1090 what version of discourse are you running?

2026.6.0-latest (c61074ebf8) Happy to give any other details as needed

Amazing, thank you for your help!

El selector de etiquetas de grupo no permite una selección

Soporte del producto

chapoi 28 Mayo, 2026 16:24 2

¿Y eso incluye los grupos de etiquetas que estás usando aquí («Tipo de incidencia» y «Prioridad de incidencia»)?

Tema		Respuestas	Vistas
Tag-chooser tags are not allowed Bug tags , form-templates	7	403	24 Febrero 2026
Form templates preview broken with tag group Bug pr-welcome , form-templates	2	236	25 Julio 2025
Limiting tags to categories not working as expected Bug tags	8	974	17 Mayo 2023
Category tags page "(optional) list of allowed tag groups" field selects tags, not groups Bug	3	914	27 Febrero 2018
Enable tagging only in some categories Feature	17	3454	5 Febrero 2024

El selector de etiquetas de grupo no permite una selección

Temas relacionados