I get a lot of “Nice Reply” badges, being very active in my community. I have thousands of them.
So every day when I log in I have to bulk-dismiss my badges. But that also dismisses any Watched topic alerts, because they are in the same category.
There should be a way to stop receiving alerts for certain badges (not all badges) or can we have Watched topic notifications in a different section so they aren’t dismissed at the same time?
Honestly I’m at a point where I miss actual, important notifications because it’s so full of “Nice Reply” alerts.
I wonder if this could be implemented.
Why don’t you simply turn off the Nice Reply badge for the site?
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 ↩︎
Oh yes our users love badges. We have loads of them (for the accompanying website as well not just the forum, I integrated them).
It’s just these badges are not particularly exciting as you get hundreds of them.
Could you raise limits then?
I don’t think you can edit the SQL for these built-in badges?
and even if you could, wouldn’t that retroactively remove badges from people?
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 
)
The issue here is if I removed it and recreated it, it would remove the old badges from everyone AND do a massive spam with thousands of notifications for the new one.
I’ve always wondered why we can’t just edit the SQL for existing badges? Seems like a bit of an oversight when everything else is editable.
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 - this is brilliant! Several of the inbuilt badges have annoyed me for years. Finally I have the power to change them!!!
I’m a little shocked that you are dabbling in the dark arts of the Rails console though…
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 
Thanks for the help but I’m not comfortable delving into the hosting settings (and someone else hosts it for us).
I spoke to the community and decided to just remove the current Nice Reply badge and make our own that will be granted on the first instance only, plus some extra badges for getting lots of them.
I much prefer single-grant badges over multi-grant ones.
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 )