2019-05-02 18:17:27 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2019-01-03 12:03:01 -05:00
|
|
|
class PostActionDestroyer
|
|
|
|
class DestroyResult < PostActionResult
|
|
|
|
attr_accessor :post
|
|
|
|
end
|
|
|
|
|
2020-08-19 11:21:02 -04:00
|
|
|
def initialize(destroyed_by, post, post_action_type_id, opts = {})
|
|
|
|
@destroyed_by, @post, @post_action_type_id, @opts =
|
|
|
|
destroyed_by,
|
|
|
|
post,
|
|
|
|
post_action_type_id,
|
|
|
|
opts
|
2019-01-03 12:03:01 -05:00
|
|
|
end
|
|
|
|
|
2020-08-19 11:21:02 -04:00
|
|
|
def self.destroy(destroyed_by, post, action_key, opts = {})
|
|
|
|
new(destroyed_by, post, PostActionType.types[action_key], opts).perform
|
2019-01-03 12:03:01 -05:00
|
|
|
end
|
|
|
|
|
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 post_action_type_view
|
|
|
|
@post_action_type_view ||= PostActionTypeView.new
|
|
|
|
end
|
|
|
|
|
2019-01-03 12:03:01 -05:00
|
|
|
def perform
|
|
|
|
result = DestroyResult.new
|
|
|
|
|
|
|
|
if @post.blank?
|
|
|
|
result.not_found = true
|
|
|
|
return result
|
|
|
|
end
|
|
|
|
|
|
|
|
finder =
|
|
|
|
PostAction.where(user: @destroyed_by, post: @post, post_action_type_id: @post_action_type_id)
|
|
|
|
finder = finder.with_deleted if @destroyed_by.staff?
|
|
|
|
post_action = finder.first
|
|
|
|
|
|
|
|
if post_action.blank?
|
|
|
|
result.not_found = true
|
|
|
|
return result
|
|
|
|
end
|
|
|
|
|
2020-08-19 11:21:02 -04:00
|
|
|
unless @opts[:skip_delete_check] == true || guardian.can_delete?(post_action)
|
2019-01-03 12:03:01 -05:00
|
|
|
result.forbidden = true
|
|
|
|
result.add_error(I18n.t("invalid_access"))
|
|
|
|
return result
|
|
|
|
end
|
|
|
|
|
|
|
|
RateLimiter.new(
|
|
|
|
@destroyed_by,
|
|
|
|
"post_action-#{@post.id}_#{@post_action_type_id}",
|
|
|
|
4,
|
|
|
|
1.minute,
|
|
|
|
).performed!
|
|
|
|
|
|
|
|
post_action.remove_act!(@destroyed_by)
|
|
|
|
post_action.post.unhide! if post_action.staff_took_action
|
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
|
|
|
if @post_action_type_id == post_action_type_view.types[:like]
|
2019-01-03 12:03:01 -05:00
|
|
|
GivenDailyLike.decrement_for(@destroyed_by.id)
|
2023-01-09 07:10:19 -05:00
|
|
|
end
|
2019-01-03 12:03:01 -05:00
|
|
|
|
2023-08-09 13:55:00 -04:00
|
|
|
case @post_action_type_id
|
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
|
|
|
when *post_action_type_view.notify_flag_type_ids
|
2023-08-09 13:55:00 -04:00
|
|
|
DiscourseEvent.trigger(:flag_destroyed, post_action, self)
|
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
|
|
|
when post_action_type_view.types[:like]
|
2023-08-09 13:55:00 -04:00
|
|
|
DiscourseEvent.trigger(:like_destroyed, post_action, self)
|
|
|
|
end
|
|
|
|
|
2019-01-03 12:03:01 -05:00
|
|
|
UserActionManager.post_action_destroyed(post_action)
|
|
|
|
PostActionNotifier.post_action_deleted(post_action)
|
|
|
|
result.success = true
|
|
|
|
result.post = @post.reload
|
|
|
|
|
2022-03-03 03:49:36 -05:00
|
|
|
notify_subscribers
|
|
|
|
|
2019-01-03 12:03:01 -05:00
|
|
|
result
|
|
|
|
end
|
|
|
|
|
|
|
|
protected
|
|
|
|
|
2022-03-03 03:49:36 -05:00
|
|
|
def self.notify_types
|
|
|
|
@notify_types ||= PostActionType.notify_flag_types.keys
|
|
|
|
end
|
|
|
|
|
|
|
|
def notify_subscribers
|
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
|
|
|
name = post_action_type_view.types[@post_action_type_id]
|
2022-03-03 03:49:36 -05:00
|
|
|
if name == :like
|
2022-05-09 16:23:39 -04:00
|
|
|
@post.publish_change_to_clients!(
|
|
|
|
:unliked,
|
|
|
|
{ likes_count: @post.like_count, user_id: @destroyed_by.id },
|
|
|
|
)
|
2022-03-03 03:49:36 -05:00
|
|
|
elsif self.class.notify_types.include?(name)
|
|
|
|
@post.publish_change_to_clients!(:acted)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-01-03 12:03:01 -05:00
|
|
|
def guardian
|
|
|
|
@guardian ||= Guardian.new(@destroyed_by)
|
|
|
|
end
|
|
|
|
end
|