is there a way to disable these notifications without resorting to a CSS hack? i would prefer not to have the excess visual noise.
.notification.read.upcoming-change-available,
.notification.unread.upcoming-change-available {
display: none;
}
But wouldn’t that still show a notification count/indicator? But I guess that can’t be helped.
not any more 
https://github.com/Lillinator/dismiss-admin-noise
note: can select to dismiss notifications for either new features or upcoming changes, or both.
This has tripped me up a few times, and I do not see it mentioned above as a concern/problem.
I am not in the habit of checking Upcoming changes by clicking the menu option on the left:
https://xyz.discourse.group/admin/config/upcoming-changes
That page includes a Preview link for each change.
Normally, as part of my daily routine, I check the Discourse inbox and sometimes find a notification about upcoming changes, for example:
https://xyz.discourse.group/admin/config/upcoming-changes?changeNamesFilter=enable_ai_bot_starred_conversations
Notice the change in the URL, and also that the Preview link is missing.
That missing Preview link is what has been tripping me up for a few days. I knew the link existed, but thought it had disappeared.
Hopefully this provides enough detail to understand the concern and possibly fix it.
Both the “Feedback…” and “Preview” links are optional for the upcoming change items:
It’s up to whichever developer who adds the upcoming change to specify these…I’ll ping some people internally and see if I can get them to add them.
Today the Preview button appears with the noted URL.
https://xyz.discourse.group/admin/config/upcoming-changes?changeNamesFilter=enable_new_checkbox_style
Thanks!
Today, I was thinking ths same thing…
I know this is true on our hosting, but I wasn’t sure what we do for self-hosters.
I went looking for the source of truth today about what we do there and discovered that we currently wait until stable.
That’s how we first did things anyway: FEATURE: Automatic promotion of upcoming changes - Pull Request #36211 - discourse/discourse - GitHub
And it looks like that’s still the case here:
I wonder if we should change that to beta for self-hosters?
In the meantime, I’m going to make a small edit to the first post here.
Do you want to update the doc too?
It’s really helpful to know. Now I understand why Martin said he won’t move the change to stable before the problem is resolved. I had checked the documentation back then and wondered what difference it makes if beta already means ‘enabled by default’.
Do you mean beta here?
I also wonder how many admins lose the option to opt out and provide feedback before the change is permanent if you remove it after being in beta - skipping ‘stable’ (and permanent).
Yep, I meant beta. Oops, thanks. Fixed.
There’s a PR open to make that change here now:
So stable is then only relevant for the few sites where the admin adjusted the hidden site setting to enable changes later?
How will this change affect the fact that there is still no solution for theme components and the replacement of the everyone group?
If beta enables the change for everyone, not moving it to stable
does no longer seem that helpful. It will still result in components being broken for almost all forums.
Yes. Perhaps we’d see more sites choose to change that setting after this change. But the default would be to enable things earlier.
A change like that would cause more complaints sooner.
We’d recommend people who are impacted disable it until we sort it out.
The change is still not permanent until it reaches stable/permanent, we won’t remove it earlier…beta just enables it by default earlier for self-hosters. As Dave says:
You can still disable it if there are issues in beta.
I’m working on this presently, I had to get internal consensus on what to do with this. So far we haven’t heard any feedback on this except from you, so I don’t think it’s causing a huge amount of problems for site admins being in beta right now.
Trust me, I want to get this fixed as much as you do, it is my change, but I also have competing priorities on my time.
To me it seemed like ‘reporting improvements’ skipped ‘stable’
Maybe I just don’t get how this works
Not sure why this this particular change was removed at beta instead of progressing to stable/permanent, will inquire internally.
This was a mistake we made and have brought the upcoming change back in DEV: Reintroduce reporting_improvements upcoming change as permanent … · discourse/discourse@08cf6f4 · GitHub.
Sorry, I probably have a misunderstanding. In your linked PR, I see that the setting was added back. What I don’t understand is what effect it has now. What exactly changes depending on whether I enable or disable the change? I can’t quite follow it in the code.
As it is now, the step that would have actually enabled the change for most forums was still skipped, right? So they never had the option to opt out because it affected their forum, or am I still misunderstanding the process?
I also tried to look at how it works now, but I can’t find the change. Does anyone have an idea what I’m doing wrong? The version is 08cf6f4
The feature is now permanent so it is not a change that you can enable or disable.
When changes become Permanent they show up on /whats-new instead, will add this information to the OP, along with anything else we may have missed over the last few months.
Edit: Done now
