discourse/lib/site_settings/db_provider.rb
Martin Brennan d4ac43e605
FEATURE: Upcoming changes part 1 (#34617)
This PR introduces part one of the "Upcoming changes" interface for
Discourse admins.

The upcoming changes feature is an enhancement around our existing
site-setting based feature flagging and experiments system. With some
light metadata, we can give admins a much better overview of the current
work we are doing, with ways for them to opt-out in early stages and
opt-in to things that we haven’t yet turned on by default for them.

This system, along with encouraging a more liberal use of site setting
flags for features, experiments, and refactors in the app, should
minimise the problem of breakages and disruptions for all Discourse
users. It is also our intent with this system for it to be easier for
designers to add and remove these changes.

Finally, it also gives us a kind of running changelog that we can use to
communicate with site owners before releases and “What’s new?” updates.

### FOR REVIEWERS

This initial PR is gated behind a hidden `enable_upcoming_changes` site
setting, because there is still more work to do before we reveal this to
admins.

To test the UI, you can add this metadata under any boolean-based site
setting, though upcoming change settings will specifically be hidden:

```
upcoming_change:
   status: "alpha" (see UpcomingChanges.statuses.keys)
   impact: "feature,staff" (feature|other for the first part, staff|admins|moderators|all_members|developers for the second part)
   learn_more_url: "https://some.url"
```

To test the images, add an image under `public/images/upcoming_changes`
with the file name as `SITE_SETTING_NAME.png`

### Interface

Admins can see the following in the interface for upcoming changes:

* The status of the change. Changes can progress along these statuses:
   * Pre-Alpha
   * Alpha
   * Beta
   * Stable
   * Permanent
* The impact of the change. This is split into Type and Role. Type can
be "Feature" or "Other" for now. Changes may affect the following roles:
   * Admins
   * Moderators
   * Staff
   * All members
* The plugin that is making the change
* The groups that are opted-in to the change. Admins can control these
groups for a gradual rollout. If a change is enabled, it is limited to
these groups.
* In some cases, an image related to the change, behind the "Preview"
link
* A link to learn more about the change

Admins can filter the changes by name, description, plugin, status,
impact type, and whether the change is enabled.

### Promotion system

For our hosted customers, we intend to have a status-based
auto-promotion system as changes progress.

For all sites, once a change reaches the Stable status, if an admin
opts-out of that change it will generate an admin problem message that
will be shown on the dashboard.

For self-hosted Discourse admins, changes will only be forcibly enabled
when they reach the Permanent state.

### Notification system

A notification system for upcoming changes so admins can stay informed
will be added in a followup PR.

---------

Co-authored-by: awesomerobot <kris.aubuchon@discourse.org>
2025-10-30 10:46:14 +10:00

67 lines
1.5 KiB
Ruby

# frozen_string_literal: true
module SiteSettings
end
class SiteSettings::DbProvider
def initialize(model)
model.after_commit { model.notify_changed! }
@model = model
end
def all
return [] unless table_exists?
# Not leaking out AR records, cause I want all editing to happen via this API
DB.query("SELECT name, data_type, value FROM #{@model.table_name}")
end
def find(name)
return nil unless table_exists?
# Not leaking out AR records, cause I want all editing to happen via this API
DB.query("SELECT name, data_type, value FROM #{@model.table_name} WHERE name = ?", name).first
end
def save(name, value, data_type)
return unless table_exists?
model = @model.find_by(name: name)
model ||= @model.new
model.name = name
model.value = value
model.data_type = data_type
# save! used to ensure after_commit is called
model.save! if model.changed?
true
end
def destroy(name)
return unless table_exists?
@model.where(name: name).destroy_all
end
def current_site
RailsMultisite::ConnectionManagement.current_db
end
protected
# table is not in the db yet, initial migration, etc
def table_exists?
@table_exists ||= {}
@table_exists[current_site] ||= ActiveRecord::Base.connection.table_exists?(@model.table_name)
end
def site_setting_groups_table_exists?
@site_setting_groups_table_exists ||= {}
@site_setting_groups_table_exists[current_site] ||= ActiveRecord::Base.connection.table_exists?(
"site_setting_groups",
)
end
end