Commit Graph

20 Commits

Author SHA1 Message Date
Krzysztof Kotlarek
1f1709d249
FIX: use a custom prefix for custom flags ()
Currently, when the custom flag has the same name as the system flag (which is disabled) then it is not displayed. To fix the problem, `custom_` prefix as `name_key` is used to distinguish between the system and the custom flag.

I considered writing a migration to fix existing custom flags name key. However, at the end of migration I would need to run rails code to reset cache `Flag.reset_flag_settings!`. I decided to skip that step as it is a very edge case. If someone has the same flag name as the system flag, then all they have to do is edit the flag and click save.

In addition, I made 2 small fixes:
- edit flag title was missing translation;
- flag form UI was not showing that description is the required field.
2024-09-11 15:30:20 +10:00
Krzysztof Kotlarek
e82e255531
FIX: serialize Flags instead of PostActionType ()
### 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-14 12:13:46 +10:00
Krzysztof Kotlarek
559c9dfe0a
REVERT: FIX: serialize Flags instead of PostActionType () 2024-08-13 18:32:11 +10:00
Krzysztof Kotlarek
c1f6ec3019
PERF: skip reset flag callbacks on seed ()
When flags are seeded, we don't need to reset the cache for each record.

We should instead create all flags and reset the cache at the very end.
2024-08-13 13:22:57 +10:00
Krzysztof Kotlarek
094052c1ff
FIX: serialize Flags instead of PostActionType ()
### 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 11:22:37 +10:00
Krzysztof Kotlarek
2b6c754779
Revert "FIX: Cache all flags multisite-safe ()" ()
This reverts commit 2225c03455.
2024-08-06 10:59:10 +10:00
Krzysztof Kotlarek
fc2259d1c8
FIX: limit the number of custom flags to 50 ()
Admin can create up to 50 custom flags. It is limited for performance reasons.

When the limit is reached "Add button" is disabled and backend is protected by guardian.
2024-08-06 10:50:12 +10:00
Martin Brennan
2225c03455
FIX: Cache all flags multisite-safe ()
This fixes an N1 in topics when loading all flags
and also makes the cache multisite-safe, followup
to fb7cc2d375
2024-08-06 09:59:49 +10:00
Krzysztof Kotlarek
bb54270e92
Revert "FIX: fallback to custom type for flags ()" ()
This reverts commit 7b6b7ca863.
2024-07-18 14:00:27 +10:00
Krzysztof Kotlarek
7b6b7ca863
FIX: fallback to custom type for flags ()
Before migration is run flags code is evaluated. It is causing error:
```
NoMethodError: undefined method `require_message' for an instance of Flag (NoMethodError)
Did you mean?  require_dependency
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activemodel-7.1.3.4/lib/active_model/attribute_methods.rb:489:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.1.3.4/lib/active_record/relation/delegation.rb💯in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.1.3.4/lib/active_record/relation/delegation.rb💯in `each'
/var/www/discourse/app/models/post_action_type.rb:64:in `reject'
```

The solution is to temporarily fall back to old column name - custom_type
2024-07-18 13:34:01 +10:00
Krzysztof Kotlarek
c975c7fe1b
FEATURE: custom flag can require additional message ()
Allow admin to create custom flag which requires an additional message.

I decided to rename the old `custom_flag` into `require_message` as it is more descriptive.
2024-07-18 10:10:22 +10:00
Krzysztof Kotlarek
25485bddee
FIX: refresh flags cache after update ()
`after_commit` should be used before refreshing processes to be sure that the database is already updated.

Also, MessageBus is used instead of events as MessageBus works correctly with many processes;
2024-07-15 19:45:25 +10:00
Krzysztof Kotlarek
9e4e591d60
Revert "FEATURE: custom flag can require additional message ()" ()
This reverts commit c0bcd979e3.
2024-07-15 09:45:57 +10:00
Krzysztof Kotlarek
c0bcd979e3
FEATURE: custom flag can require additional message ()
Allow admin to create custom flag which requires an additional message.

I decided to rename the old `custom_flag` into `require_message` as it is more descriptive.
2024-07-15 08:48:01 +10:00
Krzysztof Kotlarek
c3fadc7330
FEATURE: created edit and delete flags ()
Allow admins to create edit and delete flags.
2024-07-03 08:45:37 +10:00
Krzysztof Kotlarek
aa88b07640
FEATURE: the ability to change the order of flags ()
Continued work on moderate flags UI.
In this PR admins are allowed to change the order of flags. The notify user flag is always on top but all other flags can be moved.
2024-06-05 13:27:06 +10:00
Krzysztof Kotlarek
963b9fd157
FEATURE: admin can disable flags ()
UI for admins to disable system flags.
2024-05-29 14:39:58 +10:00
Krzysztof Kotlarek
cfbbfd177c
DEV: move post flags into database ()
This is preparation for a feature that will allow admins to define their custom flags. Current behaviour should stay untouched.
2024-05-23 12:19:07 +10:00
Krzysztof Kotlarek
40d65dddf8
Revert "DEV: move post flags into database ()" ()
This reverts commit 7aff9806eb.
2024-05-21 16:21:07 +10:00
Krzysztof Kotlarek
7aff9806eb
DEV: move post flags into database ()
This is preparation for a feature that will allow admins to define their custom flags. Current behaviour should stay untouched.
2024-05-21 13:15:32 +10:00