mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-05-28 01:19:30 +08:00
A recent change (#39072) made the composer tag autocomplete pass `excludeSynonyms: true` so synonyms appeared as disabled rows with a "Use canonical X instead" message. That blocked a legitimate workflow: a forum where company names are the canonical tags and stock tickers are the synonyms, so members can type the shorter ticker. The backend has always remapped synonym names to their canonical target at save time, so blocking the selection in the UI was overzealous. This change keeps the disabled-row UX in admin surfaces where synonyms genuinely can't be the target (tag groups form, embedding hosts, webhooks, edit-category-tags, upsert-category/tags) — those still explicitly pass `excludeSynonyms: true`. In the composer (mini-tag- chooser) synonyms are now selectable, and the row shows an inline "→ canonical-tag" hint so the user understands what their typed tag will become. Fixing the autocomplete surfaced two latent bugs that the previous block had been masking: 1. After saving, the topic header kept showing the typed synonym names until a full page reload, because the response of `TopicsController#update` and `#update_tags` only returned the `BasicTopicSerializer` fields (no tags), and the client used its in-memory pre-save tag list to update `topic.tags`. Both endpoints now include the canonical `tags` array in the response whenever tags were part of the request, and `Topic.update` / `Topic.updateTags` on the client overwrite `topic.tags` with that list. 2. Submitting only synonyms of existing tags created an empty `PostRevision` row. The controller's no-op detector compared raw tag IDs, so synonym IDs always looked like a change. `PostRevisor` would start a revision, `apply_tag_changes` would bail out after the canonical remap matched the existing set, but the bumped version and empty revision row had already been written. This is fixed at the PostRevisor level via a new `tag_change_noop?` class method that resolves incoming tag IDs/names through `COALESCE(target_tag_id, id)` and compares the canonical set with `topic.tags`. When it matches, `revise!` deletes `:tags` from `@fields` during normalization, so `should_revise?` correctly short-circuits before any version bump. The same helper replaces the controller-level no-op check and also subsumes the existing "empty tags on empty topic" branch. Specs cover: synonym row appears selectable with the hint, server returns canonical tags after a synonym submission, no revision is created when only synonyms of existing tags are submitted (object and string forms), and the existing disabled-row UX still applies for `one_per_topic` and parent-tag groups. |
||
|---|---|---|
| .. | ||
| _index.scss | ||
| categories-admin-dropdown.scss | ||
| category-chooser.scss | ||
| category-drop.scss | ||
| category-row.scss | ||
| category-selector.scss | ||
| color-palette-picker.scss | ||
| color-palettes.scss | ||
| combo-box.scss | ||
| composer-actions.scss | ||
| dropdown-select-box.scss | ||
| email-group-user-chooser.scss | ||
| flair-row.scss | ||
| future-date-input-selector.scss | ||
| icon-picker.scss | ||
| list-setting.scss | ||
| mini-tag-chooser.scss | ||
| multi-select.scss | ||
| notifications-button.scss | ||
| notifications-filter.scss | ||
| period-chooser.scss | ||
| select-kit.scss | ||
| single-select.scss | ||
| tag-category-admin-dropdown.scss | ||
| tag-chooser.scss | ||
| tag-drop.scss | ||
| topic-chooser.scss | ||
| topic-notifications-button.scss | ||
| user-row.scss | ||