mirror of
https://github.com/discourse/discourse.git
synced 2026-08-11 02:59:07 +08:00
fb9bb31983This 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>
27 lines
1.1 KiB
Ruby
Vendored
27 lines
1.1 KiB
Ruby
Vendored
# frozen_string_literal: true
|
|
#
|
|
# Tracks both the addition and removal of upcoming changes by
|
|
# observing site_settings/settings.yml files and writing to
|
|
# an upcoming change event log.
|
|
#
|
|
# Added upcoming changes will send a notification to site admins
|
|
# to inform them that the change is now available to opt-in,
|
|
# as long as the status of the change is one less than
|
|
# SiteSetting.promote_upcoming_changes_on_status. For example,
|
|
# if a site has `beta` for the promotion status, we only notify
|
|
# admins when the change reaches `alpha`.
|
|
#
|
|
# We may end up with separate added & status change events, and
|
|
# the admin should only be notified when the status is actually
|
|
# SiteSetting.promote_upcoming_changes_on_status - 1 OR gte
|
|
# SiteSetting.promote_upcoming_changes_on_status.
|
|
#
|
|
# Removed upcoming changes will be logged. After some time,
|
|
# if the setting related to the change no longer exists, the
|
|
# setting value in the site_settings table will be deleted
|
|
# in a cleanup job.
|
|
|
|
require "upcoming_changes"
|
|
require "upcoming_changes/tracking_initializer"
|
|
|
|
Rails.application.config.after_initialize { UpcomingChanges::TrackingInitializer.call }
|
