2
0
Fork 0
mirror of https://github.com/discourse/discourse.git synced 2026-03-04 01:15:08 +08:00
discourse/spec/services/upcoming_changes/track_spec.rb
Martin Brennan fb9bb31983
FEATURE: Notify admins of upcoming changes and log events (#37003)
This commit adds several pieces of functionality to help keep admins
in the loop about upcoming changes.

First of all, there is a new initializer on boot that will notify admins
about
newly available upcoming changes, as well as log removed changes and
status movement of existing changes.

* When there is a new upcoming change, we only notify admins about
   it when the status is the `promote_upcoming_changes_on_status` - 1,
   e.g. if `promote_upcoming_changes_on_status` is `beta` then we only
   tell admin about the change once it has reached `alpha`. This means
   we may log the `added` event in one deploy, but only actually notify
   admins in a subsequent deploy.
* We log removed upcoming changes so we can automatically delete old
   site setting data in a future job as needed.

We also now  notify  admins when  upcoming changes are automatically
promoted to enabled based on the site's
`promote_upcoming_changes_on_status`:

<img width="378" height="600" alt="image"
src="https://github.com/user-attachments/assets/4200fbee-9990-4bbc-a378-85946e631e77"
/>

In addition, we now show an indicator in the admin sidebar
if there are new upcoming changes that have been added since
they last visited the upcoming change config page. This data
is stored in a user custom field, because Redis is ephemeral,
and storing in the User table is overkill because 99% of users
are not staff:

<img width="248" height="112" alt="image"
src="https://github.com/user-attachments/assets/4c3d3cf7-ac39-45f8-a2c8-a049cb85b8e9"
/>

Finally, this commit moves both the Track and Promote initializer
logic behind a `DistributedMutex`, we don't want multiple processes
running the same logic here, it needs to be only once.

---------

Co-authored-by: Loïc Guitaut <loic@discourse.org>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
2026-01-21 12:45:54 +10:00

68 lines
2 KiB
Ruby

# frozen_string_literal: true
RSpec.describe UpcomingChanges::Track do
fab!(:admin_1, :admin)
fab!(:admin_2, :admin)
let(:all_admins) { [admin_1, admin_2] }
describe ".call" do
subject(:result) { described_class.call(all_admins:) }
let(:added_changes_result) do
{ added_changes: [:added_change], notified_changes: [:notified_added] }
end
let(:removed_changes_result) { [:removed_change] }
let(:status_changes_result) do
{ status_changes: { status_change: :data }, notified_changes: [:notified_status] }
end
before do
allow(UpcomingChanges::Action::TrackAddedChanges).to receive(:call).and_return(
added_changes_result,
)
allow(UpcomingChanges::Action::TrackRemovedChanges).to receive(:call).and_return(
removed_changes_result,
)
allow(UpcomingChanges::Action::TrackStatusChanges).to receive(:call).and_return(
status_changes_result,
)
end
it "runs successfully" do
expect(result).to run_successfully
end
it "calls TrackAddedChanges with correct arguments" do
result
expect(UpcomingChanges::Action::TrackAddedChanges).to have_received(:call).with(all_admins:)
end
it "calls TrackRemovedChanges" do
result
expect(UpcomingChanges::Action::TrackRemovedChanges).to have_received(:call)
end
it "calls TrackStatusChanges with correct arguments" do
result
expect(UpcomingChanges::Action::TrackStatusChanges).to have_received(:call).with(
all_admins:,
added_changes: [:added_change],
removed_changes: [:removed_change],
)
end
it "populates the context with results from actions" do
expect(result).to have_attributes(
added_changes: [:added_change],
removed_changes: [:removed_change],
status_changes: {
status_change: :data,
},
notified_admins_for_added_changes: %i[notified_added notified_status],
)
end
end
end