github-mirror/discourse
2
0
Fork 0
mirror of https://github.com/discourse/discourse.git synced 2024-12-05 08:03:40 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
229773e7a8
discourse/app/services/update_site_setting.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

58 lines
1.6 KiB
Ruby
Raw Normal View History

DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
# frozen_string_literal: true
class UpdateSiteSetting
include Service::Base
policy :current_user_is_admin
DEV: Have `contract` take a block in services Currently in services, the `contract` step is only used to define where the contract will be called in the execution flow. Then, a `Contract` class has to be defined with validations in it. This patch allows the `contract` step to take a block containing validations, attributes, etc. directly. No need to then open a `Contract` class later in the service. It also has a nice side effect, as it’s now easy to define multiples contracts inside the same service. Before, we had the `class_name:` option, but it wasn’t really useful as you had to redefine a complete new contract class. Now, when using a name for the contract other than `default`, a new contract will be created automatically using the provided name. Example: ```ruby contract(:user) do attribute :user_id, :integer validates :user_id, presence: true end ``` This will create a `UserContract` class and use it, also putting the resulting contract in `context[:user_contract]`.
2024-10-01 23:17:14 +08:00
contract do
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
attribute :setting_name
attribute :new_value
attribute :allow_changing_hidden, :boolean, default: false
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
before_validation { self.setting_name = setting_name&.to_sym }
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
validates :setting_name, presence: true
end
DEV: Have `contract` take a block in services Currently in services, the `contract` step is only used to define where the contract will be called in the execution flow. Then, a `Contract` class has to be defined with validations in it. This patch allows the `contract` step to take a block containing validations, attributes, etc. directly. No need to then open a `Contract` class later in the service. It also has a nice side effect, as it’s now easy to define multiples contracts inside the same service. Before, we had the `class_name:` option, but it wasn’t really useful as you had to redefine a complete new contract class. Now, when using a name for the contract other than `default`, a new contract will be created automatically using the provided name. Example: ```ruby contract(:user) do attribute :user_id, :integer validates :user_id, presence: true end ``` This will create a `UserContract` class and use it, also putting the resulting contract in `context[:user_contract]`.
2024-10-01 23:17:14 +08:00
policy :setting_is_visible
policy :setting_is_configurable
step :cleanup_value
step :save
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
private
def current_user_is_admin(guardian:)
guardian.is_admin?
end
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
def setting_is_visible(contract:)
contract.allow_changing_hidden || !SiteSetting.hidden_settings.include?(contract.setting_name)
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
end
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
def setting_is_configurable(contract:)
return true if !SiteSetting.plugins[contract.setting_name]
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
Discourse.plugins_by_name[SiteSetting.plugins[contract.setting_name]].configurable?
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
end
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
def cleanup_value(contract:)
new_value = contract.new_value
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
new_value = new_value.strip if new_value.is_a?(String)
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
case SiteSetting.type_supervisor.get_type(contract.setting_name)
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
when :integer
new_value = new_value.tr("^-0-9", "").to_i if new_value.is_a?(String)
when :file_size_restriction
new_value = new_value.tr("^0-9", "").to_i if new_value.is_a?(String)
when :uploaded_image_list
new_value = new_value.blank? ? "" : Upload.get_from_urls(new_value.split("|")).to_a
when :upload
new_value = Upload.get_from_url(new_value) || ""
end
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
context[:new_value] = new_value
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
end
DEV: Drop `OpenStruct` for the context object in services While using `OpenStruct` is nice, it’s generally not a very good idea as it usually leads to performance problems. The `OpenStruct` source code even says basically to avoid it. Since the context object is crucial in our services, this patch replaces `OpenStruct` with a custom implementation instead.
2024-10-04 00:05:45 +08:00
def save(contract:, new_value:, guardian:)
SiteSetting.set_and_log(contract.setting_name, new_value, guardian.user)
DEV: Allow fetching specific site settings and introduce a service for updating site settings (#27481) This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings. Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags. Internal topic: t/130713.
2024-06-14 18:07:27 +08:00
end
end
Reference in New Issue Copy Permalink