2024-07-02 19:46:53 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
class FlagSerializer < ApplicationSerializer
|
FIX: serialize Flags instead of PostActionType (#28362)
### Why?
Before, all flags were static. Therefore, they were stored in class variables and serialized by SiteSerializer. Recently, we added an option for admins to add their own flags or disable existing flags. Therefore, the class variable had to be dropped because it was unsafe for a multisite environment. However, it started causing performance problems.
### Solution
When a new Flag system is used, instead of using PostActionType, we can serialize Flags and use fragment cache for performance reasons.
At the same time, we are still supporting deprecated `replace_flags` API call. When it is used, we fall back to the old solution and the admin cannot add custom flags. In a couple of months, we will be able to drop that API function and clean that code properly. However, because it may still be used, redis cache was introduced to improve performance.
To test backward compatibility you can add this code to any plugin
```ruby
replace_flags do |flag_settings|
flag_settings.add(
4,
:inappropriate,
topic_type: true,
notify_type: true,
auto_action_type: true,
)
flag_settings.add(1001, :trolling, topic_type: true, notify_type: true, auto_action_type: true)
end
```
2024-08-13 22:13:46 -04:00
|
|
|
attributes :id,
|
|
|
|
:name,
|
|
|
|
:name_key,
|
|
|
|
:description,
|
|
|
|
:short_description,
|
|
|
|
:applies_to,
|
|
|
|
:position,
|
|
|
|
:require_message,
|
|
|
|
:enabled,
|
|
|
|
:is_flag,
|
|
|
|
:applies_to,
|
2024-10-21 19:56:31 -04:00
|
|
|
:is_used,
|
|
|
|
:auto_action_type
|
FIX: serialize Flags instead of PostActionType (#28362)
### Why?
Before, all flags were static. Therefore, they were stored in class variables and serialized by SiteSerializer. Recently, we added an option for admins to add their own flags or disable existing flags. Therefore, the class variable had to be dropped because it was unsafe for a multisite environment. However, it started causing performance problems.
### Solution
When a new Flag system is used, instead of using PostActionType, we can serialize Flags and use fragment cache for performance reasons.
At the same time, we are still supporting deprecated `replace_flags` API call. When it is used, we fall back to the old solution and the admin cannot add custom flags. In a couple of months, we will be able to drop that API function and clean that code properly. However, because it may still be used, redis cache was introduced to improve performance.
To test backward compatibility you can add this code to any plugin
```ruby
replace_flags do |flag_settings|
flag_settings.add(
4,
:inappropriate,
topic_type: true,
notify_type: true,
auto_action_type: true,
)
flag_settings.add(1001, :trolling, topic_type: true, notify_type: true, auto_action_type: true)
end
```
2024-08-13 22:13:46 -04:00
|
|
|
|
|
|
|
def i18n_prefix
|
|
|
|
"#{@options[:target] || "post_action"}_types.#{object.name_key}"
|
|
|
|
end
|
|
|
|
|
|
|
|
def name
|
|
|
|
# system flags are using i18n translations when custom flags are using value entered by admin
|
|
|
|
I18n.t("#{i18n_prefix}.title", default: object.name)
|
|
|
|
end
|
|
|
|
|
|
|
|
def description
|
2024-08-26 09:44:12 -04:00
|
|
|
I18n.t(
|
|
|
|
"#{i18n_prefix}.description",
|
|
|
|
default: object.description.to_s,
|
|
|
|
base_path: Discourse.base_path,
|
|
|
|
)
|
FIX: serialize Flags instead of PostActionType (#28362)
### Why?
Before, all flags were static. Therefore, they were stored in class variables and serialized by SiteSerializer. Recently, we added an option for admins to add their own flags or disable existing flags. Therefore, the class variable had to be dropped because it was unsafe for a multisite environment. However, it started causing performance problems.
### Solution
When a new Flag system is used, instead of using PostActionType, we can serialize Flags and use fragment cache for performance reasons.
At the same time, we are still supporting deprecated `replace_flags` API call. When it is used, we fall back to the old solution and the admin cannot add custom flags. In a couple of months, we will be able to drop that API function and clean that code properly. However, because it may still be used, redis cache was introduced to improve performance.
To test backward compatibility you can add this code to any plugin
```ruby
replace_flags do |flag_settings|
flag_settings.add(
4,
:inappropriate,
topic_type: true,
notify_type: true,
auto_action_type: true,
)
flag_settings.add(1001, :trolling, topic_type: true, notify_type: true, auto_action_type: true)
end
```
2024-08-13 22:13:46 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def short_description
|
|
|
|
I18n.t("#{i18n_prefix}.short_description", base_path: Discourse.base_path, default: "")
|
|
|
|
end
|
|
|
|
|
|
|
|
def is_flag
|
|
|
|
!object.score_type && object.id != PostActionType::LIKE_POST_ACTION_ID
|
|
|
|
end
|
|
|
|
|
|
|
|
def is_used
|
|
|
|
@options[:used_flag_ids].include?(object.id)
|
|
|
|
end
|
|
|
|
|
|
|
|
def applies_to
|
|
|
|
Array.wrap(object.applies_to)
|
|
|
|
end
|
2024-07-02 19:46:53 -04:00
|
|
|
end
|