Bonjour,
Je débute avec les modèles de formulaires, donc j’espère que je passe juste à côté de quelque chose de simple.
J’ai créé un modèle de formulaire qui remplit un menu déroulant à partir d’un groupe d’étiquettes. Celui-ci s’affiche correctement, mais je ne parviens pas à sélectionner quoi que ce soit.
La catégorie possède bien 3 groupes d’étiquettes qui lui sont restreints, avec l’option « autoriser également d’autres étiquettes » décochée.
Aucun groupe d’étiquettes n’est spécifié dans le champ « groupe d’étiquettes requis », bien que j’aimerais idéalement y spécifier les mêmes 3 groupes.
Voici le YAML de mon formulaire :
- 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
L’aperçu se charge correctement :
Mais le formulaire lui-même, lors de la création d’un sujet, ne me permet pas de sélectionner d’étiquettes :
Tous les groupes d’étiquettes sont configurés de manière similaire :
Toute aide serait appréciée. Comme je l’ai dit, j’espère qu’il s’agit de quelque chose de simple
Cela inclut-il les groupes d’étiquettes que vous utilisez ici (« Type de problème » et « Priorité du problème ») ?
Merci pour votre réponse !
Oui, ces deux éléments sont inclus
J’ai du mal à reproduire le problème localement. @Parker1090 , quelle version de Discourse utilisez-vous ?
2026.6.0-latest (c61074ebf8)
Heureux de fournir tout autre détail si nécessaire
Merci, j’ai réussi à reproduire le problème localement en utilisant des noms de balises avec des majuscules et des minuscules mélangées.
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.
Incroyable, merci pour votre aide !
