mirror of
https://github.com/discourse/discourse.git
synced 2026-08-06 13:08:40 +08:00
b53dc3d9d3Upcoming changes can be registered by plugins, but nothing in the upcoming changes framework knew whether the owning plugin was actually configurable on a given site. For unavailble plugins on our hosting, `SiteSettingExtension#setting` already forces the plugin's `enabled_site_setting` to false, and `all_settings` already filters the change out of the Upcoming Changes page. The notification paths for upcoming changes did not follow suit...`UpcomingChanges::NotifyPromotion` and `Jobs::NotifyAdminsOfAvailableUpcomingChanges` both gate only on `ConditionalDisplay`, so admins were told a change had been enabled by default for a plugin they cannot use and that is in fact still off. `UpcomingChanges.enabled?` had the same blind spot for a different reason, in that it reads the settings provider directly, bypassing the getter's configurability guard, so it returned true where the setting itself read false. Adds `UpcomingChanges.owning_plugin_configurable?` and short-circuits both `ConditionalDisplay.should_display?` and `UpcomingChanges.enabled?` on it. Core changes have no owning plugin and return early, so hot paths such as `settings_hidden_while_enabled` are unaffected. The gate keys on `configurable?` alone rather than mirroring the getter's narrower `enabled_site_setting == name` condition, a change gating a sub-feature of an unavailable plugin is equally unavailable. |
||
|---|---|---|
| .. | ||
| backfill_nested_reply_stats_spec.rb | ||
| check_upcoming_changes_spec.rb | ||
| directory_refresh_spec.rb | ||
| notify_admins_of_available_upcoming_changes_spec.rb | ||
| notify_admins_of_problems_spec.rb | ||
