Eviepayne
(vladtheimplier)
21 Aprile 2025, 1:08am
1
Quando si cerca nel mio forum con tags:tag1
se tag1 è un sinonimo di tag-one, non ottengo risultati e il post con tag-one non viene mostrato.
1 Mi Piace
Eviepayne
(vladtheimplier)
22 Aprile 2025, 1:16pm
3
Credo che questo probabilmente non sia il comportamento previsto, quindi etichetterò questo come un bug.
sam
(Sam Saffron)
23 Aprile 2025, 5:30am
4
Capisco, dovremmo probabilmente aggiungere la gestione dei sinonimi qui, sono d’accordo.
Metto un pr-welcome su questo nel caso in cui la community volesse aiutare. La ricerca è estremamente autonoma, scrivere test per essa dovrebbe essere molto semplice.
2 Mi Piace
Moin
12 Febbraio 2026, 9:32am
5
Risolto
Questi funzionano tutti ora:
Cerca tag:howto
Cerca tag:how-to
Cerca #howto
Cerca #how-to
main ← fix/tag-synonyms-in-search
merged 07:57AM - 09 Feb 26 UTC
What is the problem?
Discourse allows admins to mark a tag as a synonym of anot… her tag. For
example, "brunch" can be made a synonym of "lunch". When this happens,
all topics tagged with "brunch" are automatically retagged with "lunch",
and the `tags.target_tag_id` column on the synonym tag record is set to
point to the target tag.
However, several code paths did not account for synonyms:
1. **Search:** `Search#search_tags` and the hashtag advanced filter did
not resolve synonyms. When a user searched using a synonym name (e.g.
`tags:brunch`, `tags:brunch+eggs`, or `#brunch`), no results were
returned because:
- The `tags:` comma path queries `topic_tags` joined with `tags` by
name, but topics are tagged with the target tag "lunch", not the
synonym "brunch".
- The `tags:` plus path aggregates tag names per topic into a
tsvector and matches against the searched name, but the aggregated
names are target tag names, so "brunch" never matches.
- The `#` hashtag path picks the synonym tag's own `id` and queries
`topic_tags` by that ID, but topics store the target tag's ID.
2. **Filter route:** `TopicsFilter#tag_ids_from_tag_names` concatenated
both the synonym's own ID and the target tag ID. For match-all
queries (e.g. `tag:brunch`), this required a topic to have both IDs
in `topic_tags`, which never happens since only the target tag ID is
stored. For negation queries (e.g. `-tag:brunch`), the exclusion
targeted the synonym ID rather than the target, so no topics were
excluded.
What is the solution?
In `Search#search_tags`, add a synonym resolution step before the
existing comma/plus branching logic. It splits the match string into
individual tag names, queries for any that are synonyms via
`Tag.where_name(tag_names).where.not(target_tag_id: nil)`, builds a
name mapping, and replaces synonym names with their target tag names.
The replacement operates on the split array elements rather than using
substring replacement to avoid corrupting tag names that may contain
other tag names as substrings.
In the hashtag advanced filter, pick both `:id` and `:target_tag_id`
from the tag lookup and prefer `target_tag_id` when present, so the
query uses the target tag's ID instead of the synonym's own ID.
In `TopicsFilter#tag_ids_from_tag_names`, replace the transpose/concat
approach with `.map { |id, target_id| target_id || id }` to resolve
each tag to its canonical ID — the target for synonyms, or the tag's
own ID otherwise.
A partial index on `tags.target_tag_id` is added (scoped to
`WHERE target_tag_id IS NOT NULL`) to support efficient synonym lookups.
2 Mi Piace
nat
(Natalie T)
Chiuso
14 Febbraio 2026, 12:00am
6
Questo argomento è stato chiuso automaticamente dopo 38 ore. Non sono più consentite nuove risposte.