0
0
Fork 0
mirror of https://github.com/discourse/discourse.git synced 2026-08-06 07:23:30 +08:00
discourse/spec/initializers/track_upcoming_change_toggle_spec.rb
Martin Brennan 4de06a006b
FIX: Do not notify new sites or plugins enabled of old upcoming changes (#42045)
For upcoming changes, we were having a problem where we
were notifying admins of upcoming changes in brand new sites.
A previous fix 2e5afb46e2f5c0547bc298b2bd1a9c39e813dc17 tried
to remedy this, but since it relies on the `new_site?` method, which
isn't true after 1 hour, the next time the scheduled notifications are
run for an admin they will be sent them even if their site is relatively
new.

This commit attempts to conclusively fix the issue by inserting
upcoming change `admins_notified_automatic_promotion` and
`admins_notified_available_change` events via `BackfillNotifiedEvents`
for changes that exist in particular statuses when the site is first
created. These events will have `event_data: {"backfilled" => true}`
to distinguish them from others.

It also fixes an adjacent issue where an admin was notified of a
plugin's upcoming changes as soon as they enable the plugin,
which isn't useful as the intent of upcoming changes is to notify
of changes for things the admin has already been using.

**Before this change, on brand new site with current upcoming change
state**

<img width="401" height="429" alt="image"
src="https://github.com/user-attachments/assets/a89cd641-59aa-4c48-a57c-9692021df176"
/>

**After this change**

No notification to show :) But when I moved an upcoming change to `beta`
it showed
the notification for the enabled upcoming change correctly:

<img width="378" height="174" alt="image"
src="https://github.com/user-attachments/assets/20e4096f-e83f-4c06-970d-a9b43561b12e"
/>
2026-07-30 09:51:08 +10:00

85 lines
2.6 KiB
Ruby
Vendored

# frozen_string_literal: true
RSpec.describe "Upcoming change toggles" do
describe "when a plugin is enabled" do
let(:plugin) do
Plugin::Instance.new.tap do |instance|
instance.metadata = Plugin::Metadata.new.tap { |m| m.name = "my-plugin" }
instance.enabled_site_setting(:enable_upload_debug_mode)
end
end
before do
SiteSetting.promote_upcoming_changes_on_status = :beta
mock_upcoming_change_metadata(
{
show_user_menu_avatars: {
impact: "feature,all_members",
status: :stable,
impact_type: "feature",
impact_role: "all_members",
},
enable_experimental_admin_ui_grouped_filters: {
impact: "feature,admins",
status: :stable,
impact_type: "feature",
impact_role: "admins",
},
},
)
Discourse.plugins_by_name["my-plugin"] = plugin
SiteSetting.plugins[:enable_upload_debug_mode] = "my-plugin"
SiteSetting.plugins[:show_user_menu_avatars] = "my-plugin"
UpcomingChangeEvent.delete_all
end
after do
Discourse.plugins_by_name.delete("my-plugin")
SiteSetting.plugins.delete(:enable_upload_debug_mode)
SiteSetting.plugins.delete(:show_user_menu_avatars)
end
def trigger_enable
DiscourseEvent.trigger(:site_setting_changed, :enable_upload_debug_mode, false, true)
end
it "marks the plugin's upcoming changes as already notified about" do
trigger_enable
expect(
UpcomingChangeEvent.where(upcoming_change_name: :show_user_menu_avatars).pluck(:event_type),
).to contain_exactly("added", "admins_notified_automatic_promotion")
end
it "leaves changes owned by core and other plugins alone" do
trigger_enable
expect(
UpcomingChangeEvent.exists?(
upcoming_change_name: :enable_experimental_admin_ui_grouped_filters,
),
).to eq(false)
end
it "does nothing when the plugin is disabled" do
expect {
DiscourseEvent.trigger(:site_setting_changed, :enable_upload_debug_mode, true, false)
}.not_to change { UpcomingChangeEvent.count }
end
it "does nothing for a setting that is not a plugin's enabled setting" do
expect {
DiscourseEvent.trigger(:site_setting_changed, :show_user_menu_avatars, false, true)
}.not_to change { UpcomingChangeEvent.count }
end
it "is a no-op when the plugin is re-enabled" do
trigger_enable
expect { trigger_enable }.not_to change { UpcomingChangeEvent.count }
end
end
end