nathank
Août 14, 2025, 11:39
1
Il est merveilleux que nous puissions désormais modifier facilement et silencieusement la catégorie des sujets (sans avoir à modifier les paramètres du site) grâce à cette nouvelle fonctionnalité :
committed 03:42AM - 15 Jul 25 UTC
We want to add an option for admins to carry out the operation silently
when the… y are updating the category for the selected topics. When the
“Perform this action silently” checkbox has been checked, the
`:notify_category_change sidekiq` job should not be enqueued.
Cependant, le même problème existe également pour les modifications d’étiquettes. Y a-t-il une chance que cette fonctionnalité puisse être étendue pour couvrir également les étiquettes ?
7 « J'aime »
Zanbabe
Décembre 17, 2025, 3:04
2
Ceci est certainement nécessaire.
1 « J'aime »
En travaillant sur ces PRs, j’ai remarqué que la modification en masse des étiquettes ne générera jamais de notifications, donc celle-ci peut être fermée.
main ← fix/silent-bulk-category-move-notifications
opened 09:56PM - 13 Feb 26 UTC
When performing a bulk category move with the "Notify users of this change" opti… on unchecked, topic authors were still receiving "edited" notifications. This happened because the silent flag was not propagated to the PostRevision `after_create` callback.
The original implementation (7a099ebb) correctly suppressed the `notify_category_change` job (PostAlerter path) but missed the second notification path: `PostActionNotifier.after_create_post_revision`, which fires via the PostRevision `after_create` callback when `create_revision_on_bulk_topic_moves` is enabled.
This fix adds a transient `silent` attr_accessor to PostRevision, set by PostRevisor before saving, and checked as an early return guard in `PostActionNotifier.after_create_post_revision`.
The specs are also updated to properly enable PostActionNotifier (which is disabled by default in tests) so the revision notification path is actually exercised.
Ref - t/174237
main ← fix/bulk-tag-actions-no-notifications
opened 05:02PM - 16 Feb 26 UTC
Bulk tag operations (change, append, remove) were directly manipulating tag reco… rds via DiscourseTagging and TopicTag, bypassing PostRevisor entirely. This meant callbacks, plugin hooks, and other side effects tied to the revision pipeline were not triggered.
This refactors the three bulk tag actions to go through `first_post.revise` instead, using `silent: true` to avoid sending notifications and `skip_revision: true` to avoid creating revision records, preserving the existing quiet behavior.
Also adds eager loading of first_post and tags to avoid N+1 queries, simplifies tag input handling by normalizing both tag_ids and tag_names into a single code path, and refactors `notification_is_disabled?` in PostActionNotifier for readability.
2 « J'aime »