Ik krijg heel veel “Mooi antwoord”-badges, omdat ik erg actief ben in mijn community. Ik heb er duizenden.
Dus elke dag als ik inlog, moet ik mijn badges in bulk afwijzen. Maar dat wijst ook alle meldingen van gevolgde onderwerpen af, omdat die in dezelfde categorie staan.
Er zou een manier moeten zijn om meldingen voor bepaalde badges (niet alle badges) te stoppen of kunnen we meldingen van gevolgde onderwerpen in een andere sectie plaatsen, zodat ze niet tegelijkertijd worden afgewezen?
Eerlijk gezegd ben ik op een punt waarop ik daadwerkelijke, belangrijke meldingen mis omdat het zo vol zit met “Leuk antwoord”-meldingen.
Ik vraag me af of dit geïmplementeerd zou kunnen worden.
Waarom schakelt u de Nice Reply-badge voor de site niet gewoon uit?
Have you considered not having as nice of replies? /s
This could work, but it would deprive anyone else of receiving this badge, too. How often has it been awarded in your community @Shauny?
Because people who maybe aren’t as active enjoy getting them.
I think maybe once you’ve got a certain number it should stop.
It’s currently at 40,000.
Are they enjoying receiving badges? That is the hot question.
I know this is a cultural question. In my environment, members asked me to shut down the whole badge system, because it was considered very childish. Somewhere else, badges are counted as the main reason to participate [1].
not discussion per se, which I feel quite troubled by ↩︎
Ja hoor, onze gebruikers houden van badges. We hebben er heel veel (ook voor de bijbehorende website, niet alleen voor het forum, die heb ik geïntegreerd).
Het is alleen dat deze badges niet bijzonder spannend zijn, aangezien je er honderden krijgt.
Kunt u de limieten dan verhogen?
Ik denk niet dat je de SQL voor deze ingebouwde badges kunt bewerken?
en zelfs als je dat zou kunnen, zou dat dan niet met terugwerkende kracht badges van mensen verwijderen?
As I said I don’t use badges, so I’m just guessing here 
and you propably know way better. But really many things in Discourse is editable, so I would be very surprised if this one is hard coded.
Well, quite soon someone who actually knows something and doesn’t write just meta will chime in.
The system badges are indeed hardcoded and uneditable in the UI, though you could disable the default Nice Reply (et al) ones and recreate them as custom ones with an extra clause to exclude your user id to prevent you from earning any more.
It’s not quite the same as the feature request to suppress notifications for them, but it might be an alternative workaround.
Badges are only automatically removed if the ‘Run revocation query daily’ option is ticked on the badge setting page. If that’s unchecked then people would get to keep them even if they no longer qualified for it. (The system Nice Reply does have it checked, but you can’t edit it anyway, so this is more an FYI 
)
Het probleem hier is dat als ik het zou verwijderen en opnieuw zou aanmaken, het de oude badges van iedereen zou verwijderen EN een enorme spam zou veroorzaken met duizenden meldingen voor de nieuwe.
Ik heb me altijd afgevraagd waarom we de SQL voor bestaande badges niet gewoon kunnen bewerken? Het lijkt een beetje een vergissing te zijn, aangezien al het andere bewerkbaar is.
Yes, I think swopping over on an established site will have some potential downsides. Especially for these types of ones. 
To override the default one I think you’d need a plugin [ETA not true, see post below] (but I think the same is true for muting the notifications). They’re not editable in the UI as I think it’s easy for people to do some real damage to their site with a poorly amended one. The custom badge sql is behind a hidden site setting as an added safeguard.
I think a similar feature request has come up before too, which can add more weight to it:
(There may be others too)
A setting in your user preferences similar to the ‘Notify when liked’ one could work and keep it simple. Something like ‘Notify when badge earned’ - never | first time a badge is earned | always
As soon as I wrote that I had a vague memory resurface of being able to amend the ‘system’ flag for the badge in the database using the rails console. Let me give it a run through and see if I’m remembering right.
Yes, I was remembering right. If you change the ‘system’ field for the badge from true to false using a rails command you can then edit the default badge in the UI [1]
I used:
Badge.where(id:6).update(system:false)
Though be cautious when doing anything in the rails console as accidents can happen. 
(at your own risk, of course ) ↩︎
Oh Jammy - dit is briljant! Verschillende van de ingebouwde badges irriteren me al jaren. Eindelijk heb ik de macht om ze te veranderen!!!
Ik ben een beetje geschokt dat je je bezighoudt met de duistere kunsten van de Rails-console…
I do normally lace in a lot more ‘AT YOUR OWN RISK 
’ as it can be difficult to know what sharks are waiting further down the line when you sidestep some things in the rails console. Please make sure to test things throughly first before getting too giddy.
There are some system badges that don’t show the SQL in there (eg. New User of the Month or First Onebox), so I don’t think you’ll be able to change those ones.
Edit: It looks like I may also have spoken too soon, and the original badges are reset on rebuild. So this may be more limited than I first thought.
I also think that the feature request itself is a much much better option if it could be implemented 
Bedankt voor de hulp, maar ik voel me niet prettig bij het aanpassen van de hostinginstellingen (en iemand anders host het voor ons).
Ik heb met de community gesproken en besloten om de huidige Nice Reply badge te verwijderen en onze eigen badge te maken die slechts één keer wordt toegekend, plus enkele extra badges voor het behalen van veel van deze.
Ik geef de voorkeur aan badges die één keer worden toegekend boven badges die meerdere keren kunnen worden toegekend.
FWIW I think that’s a smart choice. Hopefully this will be an even better solution for you and your whole community.
(And my tentative workaround turned into a bit of a busted flush at any rate )