Hallo
Ich bin neu bei der Verwendung von Formularvorlagen, daher hoffe ich, dass ich nur etwas übersehen habe.
Ich habe eine Formularvorlage erstellt, die ein Dropdown-Menü aus einer Tag-Gruppe auffüllt. Das wird zwar korrekt angezeigt, aber ich kann nichts auswählen.
Die Kategorie hat zwar 3 Tag-Gruppen, die darauf beschränkt sind, und die Option „Andere Tags ebenfalls zulassen“ ist deaktiviert
In der „erforderlichen Tag-Gruppe“ sind keine Kategorien angegeben, obwohl ich idealerweise dieselben 3 Tag-Gruppen hier angeben möchte
Das YAML für mein Formular lautet:
- 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
Die Vorschau lädt problemlos:
Aber das Formular selbst bei der Erstellung eines Themas erlaubt mir nicht, Tags auszuwählen:
Alle Tag-Gruppen sind ähnlich eingerichtet –
Jede Hilfe wäre willkommen. Wie gesagt, hoffentlich ist es etwas Einfaches
chapoi
28. Mai 2026 um 16:24
2
[quote=“Parker1090, Beitrag:1, Thema:404021”]hat tatsächlich 3 Tag-Gruppen, die darauf beschränkt sind, mit der Option „Andere Tags ebenfalls zulassen
Danke für die Antwort!
Ja, diese beiden sind enthalten
Ich habe Schwierigkeiten, das Problem lokal nachzuvollziehen. @Parker1090 , welche Version von Discourse verwendest du?
2026.6.0-latest (c61074ebf8)
Gerne teile ich bei Bedarf weitere Details mit.
Danke, ich habe das Problem lokal reproduzieren können, indem ich Tag-Namen mit gemischten Groß- und Kleinschreibungen verwendet habe.
main ← fix-form-template-tag-chooser-uppercase
opened 09:40PM - 28 May 26 UTC
When a form template `tag-chooser` field is populated from a tag group, each
`<o… ption>` 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.
Toll, vielen Dank für deine Hilfe!
