Je reçois beaucoup de badges « Belle réponse », car je suis très actif dans ma communauté. J’en ai des milliers.
Donc, chaque jour lorsque je me connecte, je dois rejeter en bloc mes badges. Mais cela rejette également toutes les alertes de sujets surveillés, car ils se trouvent dans la même catégorie.
Il devrait y avoir un moyen d’arrêter de recevoir des alertes pour certains badges (pas tous les badges) ou pouvons-nous avoir des notifications de sujets surveillés dans une section différente afin qu’elles ne soient pas rejetées en même temps ?
Avez-vous envisagé de ne pas avoir des réponses aussi agréables ? /s
Cela pourrait fonctionner, mais cela priverait également les autres de recevoir ce badge. À quelle fréquence a-t-il été décerné dans votre communauté @Shauny ?
Est-ce qu’ils aiment recevoir des badges ? C’est la question brûlante.
Je sais que c’est une question culturelle. Dans mon environnement, les membres m’ont demandé de désactiver tout le système de badges, car il était considéré comme très puéril. Ailleurs, les badges sont considérés comme la principale raison de participer [1].
pas la discussion en soi, ce qui me trouble assez ↩︎
Oh oui, nos utilisateurs aiment les badges. Nous en avons plein (pour le site web associé également, pas seulement le forum, je les ai intégrés).
C’est juste que ces badges ne sont pas particulièrement excitants car vous en obtenez des centaines.
Comme je l’ai dit, je n’utilise pas d’insignes, donc je ne fais que deviner ici et vous savez probablement bien mieux. Mais vraiment, beaucoup de choses dans Discourse sont modifiables, donc je serais très surpris si celle-ci était codée en dur.
Eh bien, très bientôt quelqu’un qui sait vraiment quelque chose et qui n’écrit pas juste de la méta interviendra.
Les badges système sont en effet codés en dur et non modifiables dans l’interface utilisateur, bien que vous puissiez désactiver les badges par défaut « Nice Reply » (et autres) et les recréer en tant que badges personnalisés avec une clause supplémentaire pour exclure votre ID utilisateur afin de vous empêcher d’en gagner davantage.
Ce n’est pas tout à fait la même chose que la demande de fonctionnalité pour supprimer les notifications les concernant, mais cela pourrait constituer une solution de contournement alternative.
Les badges ne sont automatiquement supprimés que si l’option « Exécuter la requête de révocation quotidiennement » est cochée sur la page des paramètres du badge. Si cette option est décochée, les gens pourront les conserver même s’ils ne remplissent plus les conditions requises. (Le badge système « Nice Reply » l’a cochée, mais vous ne pouvez de toute façon pas le modifier, donc c’est plus une information )
Le problème ici est que si je le supprimais et le recréais, cela supprimerait les anciens badges de tout le monde ET enverrait un spam massif avec des milliers de notifications pour le nouveau.
Je me suis toujours demandé pourquoi nous ne pouvions pas simplement modifier le SQL pour les badges existants ? Cela semble être un oubli alors que tout le reste est modifiable.
Oui, je pense que le fait de passer d’un site établi aura des inconvénients potentiels. Surtout pour ce type de sites.
Pour remplacer celui par défaut, je pense qu’il faudrait un plugin [ETA ce n’est pas vrai, voir le post ci-dessous] (mais je pense que la même chose est vraie pour la mise en sourdine des notifications). Ils ne sont pas modifiables dans l’interface utilisateur car je pense qu’il est facile pour les gens de causer de réels dommages à leur site avec un élément mal modifié. Le SQL de badge personnalisé est derrière un paramètre de site caché comme mesure de sécurité supplémentaire.
Je pense qu’une demande de fonctionnalité similaire est déjà apparue auparavant, ce qui peut lui donner plus de poids :
(Il peut y en avoir d’autres aussi)
Un paramètre dans vos préférences utilisateur similaire à celui de « Notifier lorsque j’aime » pourrait fonctionner et rester simple. Quelque chose comme « Notifier lorsqu’un badge est gagné » - jamais | la première fois qu’un badge est gagné | toujours
Dès que je l’ai écrit, un vague souvenir a refait surface : la possibilité de modifier le drapeau « system » pour le badge dans la base de données en utilisant la console Rails. Laissez-moi essayer et voir si je me souviens bien.
Oui, je me souvenais bien. Si vous changez le champ « system » du badge de true à false en utilisant une commande Rails, vous pouvez ensuite modifier le badge par défaut dans l’interface utilisateur [1]
Détails supplémentaires
J’ai utilisé :
Badge.where(id:6).update(system:false)
Soyez prudent lorsque vous effectuez des opérations dans la console Rails, car des accidents peuvent arriver.
Je fais normalement plus de « À VOS RISQUES ET PÉRILS » car il peut être difficile de savoir quels requins attendent plus loin lorsque vous évitez certaines choses dans la console Rails. Veuillez vous assurer de bien tout tester avant de vous réjouir trop vite.
Certains badges système n’affichent pas le SQL (par exemple, Nouvel utilisateur du mois ou Première Onebox), je ne pense donc pas que vous pourrez modifier ceux-là.
\u003eEdit : Il semble que j’aie peut-être parlé trop vite, et que les badges d’origine soient réinitialisés lors de la reconstruction. Cela pourrait donc être plus limité que ce que je pensais au départ.
Je pense également que la demande de fonctionnalité elle-même est une bien meilleure option si elle pouvait être implémentée
Merci pour votre aide, mais je ne suis pas à l’aise pour explorer les paramètres d’hébergement (et quelqu’un d’autre nous héberge).
J’ai parlé à la communauté et décidé de simplement supprimer le badge Nice Reply actuel et d’en créer un autre qui ne sera attribué qu’une seule fois, ainsi que quelques badges supplémentaires pour en obtenir beaucoup.
Je préfère de loin les badges à attribution unique aux badges à attribution multiple.
et vous savez probablement bien mieux. Mais vraiment, beaucoup de choses dans Discourse sont modifiables, donc je serais très surpris si celle-ci était codée en dur.
)
» car il peut être difficile de savoir quels requins attendent plus loin lorsque vous évitez certaines choses dans la console Rails. Veuillez vous assurer de bien tout tester avant de vous réjouir trop vite. 