Commit Graph

101 Commits

Author SHA1 Message Date
5eb7d6d9c0 FEATURE: Gracefully handle unhandled reviewables (#31118)
Plugins like for example AI or Akismet create reviewable items. When the
plugin is disabled, then we cannot properly handle those items.

In that situation, we should display warnings about unhandled types.
Instruct admin to reenable plugins. In addition, we should allow the
admin to delete all pending reviews from disabled plugins.
2025-02-05 14:38:45 +11:00
Sam
55a8184231 FEATURE: Reason and deleted content support in the review queue (#30295)
Add flag reason filter and improve handling of deleted content in review queue

This commit enhances the review queue with several key improvements:

1. Adds a new "Reason" filter to allow filtering flags by their score type
2. Improves UI for deleted content by:
   - Adding visual indication for deleted posts (red background)
   - Properly handling deleted content visibility for staff (category mods can not see deleted content)
3. Refactors reviewable score type handling for better code organization
4. Adds  tests for trashed topics/posts visibility

This change will help moderators more efficiently manage the review queue by
being able to focus on specific types of flags and better identify deleted
content.
2024-12-17 11:44:46 +11:00
Sam
58e3e0cc4f FEATURE: add support for "Flagged By" filter in reviewable (#30197)
Previous to this change there was no way to find all the flags
a user raised.

New filter allows you to find all the flags raised by a user.
2024-12-10 18:26:38 +11:00
8a89a77248 FIX: Discard empty bundles for reviewables (#30121)
Followup c7e471d35a0d394899eda5af26de64511e199cc6

It is currently possible to add a bundle (which is a collection
of actions used for a dropdown on the client) for a reviewable
via actions.add_bundle and then never add any actions to it.

This causes the client to explode, as seen in the referenced
commit, because of the way our store expects to resolve objects
referenced by ID that are passed down by the serializer, which
then causes Ember to have an unrecoverable render error.

Fixing this on the serializer level is not really possible because
of all the ActiveModel::Serializer magic that serializes
objects by ID reference when doing things like has_many.
`Reviewable#actions_for` is a better place to do this anyway,
because this is the main location where the bundles and actions
are built for every action via the serializer.
2024-12-05 15:41:13 +10:00
f4d0a77d5f DEV: Add "delete user" options to illegal flag review (#29956)
We already add the "delete user" and "delete and block user" options to the drop-down for potential spam, but we should do this for potentially illegal posts as well.

This is entirely based on the implementation for the potential spam one, including caching the status on the reviewable record.

Also note that just as for potential spam, the user must be "deletable" for the option to appear.

I also took the liberty to move the options in the drop-down to what I think is a more intuitive place. (Between delete post and suspend/silence user.)
2024-11-27 17:23:57 +08:00
a914d3230b DEV: remap all core icons for fontawesome 6 upgrade (#28715)
Followup to 7d8974d02f7360b324b446868463e950fe92883f

Co-authored-by: David Taylor <david@taylorhq.com>
2024-09-13 16:50:52 +01:00
280adda09c FEATURE: Support designating multiple groups as mods on category (#28655)
Currently, categories support designating only 1 group as a moderation group on the category. This commit removes the one group limitation and makes it possible to designate multiple groups as mods on a category.

Internal topic: t/124648.
2024-09-04 04:38:46 +03:00
5ec227334a FIX: Don’t list values from disabled plugins
Currently, when a plugin registers a new reviewable type or extends a
list method (through `register_reviewble_type` and `extend_list_method`
respectively), the new array is statically computed and always returns
the same value. It will continue to return the same value even if the
plugin is disabled (it can be a problem in a multisite env too).

To address this issue, this patch changes how `extend_list_method`
works. It’s now using `DiscoursePluginRegistry.define_filtered_register`
to create a register on the fly and store the extra values from various
plugins. It then combines the original values with the ones from the
registry. The registry is already aware of disabled plugins, so when a
plugin is disabled, its registered values won’t be returned.
2024-07-11 10:51:48 +02:00
8d249457e8 DEV: Upgrade Rails to version 7.1
---------

Co-authored-by: Jarek Radosz <jradosz@gmail.com>
2024-07-04 10:58:21 +02:00
c3fadc7330 FEATURE: created edit and delete flags (#27484)
Allow admins to create edit and delete flags.
2024-07-03 08:45:37 +10:00
f58b844f45 Revert "DEV: Upgrade Rails to version 7.1" (#27625)
This reverts commit ce00f83173863c3151f21c5cd03f24e3f6617e5c.
2024-06-26 18:55:05 +02:00
ce00f83173 DEV: Upgrade Rails to version 7.1
---------

Co-authored-by: Jarek Radosz <jradosz@gmail.com>
2024-06-24 11:16:14 +02:00
160011793a Revert "DEV: Upgrade Rails to version 7.1 (#27539)"
This reverts commit ca4af53be8cb91aa3fe48ecbcf5a578189be32fa.
2024-06-21 11:20:40 +02:00
ca4af53be8 DEV: Upgrade Rails to version 7.1 (#27539)
* DEV: Upgrade Rails to 7.1

* FIX: Remove references to `Rails.logger.chained`

`Rails.logger.chained` was provided by Logster before Rails 7.1
introduced their broadcast logger. Now all the loggers are added to
`Rails.logger.broadcasts`.

Some code in our initializers was still using `chained` instead of
`broadcasts`.

* DEV: Make parameters optional to all FakeLogger methods

* FIX: Set `override_level` on Logster loggers (#27519)

A followup to f595d599dd361b7fb39fb3c82cbc11d19d518c19

* FIX: Don’t duplicate Rack response

---------

Co-authored-by: Jarek Radosz <jradosz@gmail.com>
2024-06-21 09:44:06 +02:00
982c005979 Revert "DEV: Upgrade Rails to version 7.1 (#27539)"
This reverts commit 2301dddcff8c0efe551c3c3baeeea63dadbe0ea6.
2024-06-20 11:43:35 +02:00
2301dddcff DEV: Upgrade Rails to version 7.1 (#27539)
* DEV: Upgrade Rails to 7.1

* FIX: Remove references to `Rails.logger.chained`

`Rails.logger.chained` was provided by Logster before Rails 7.1
introduced their broadcast logger. Now all the loggers are added to
`Rails.logger.broadcasts`.

Some code in our initializers was still using `chained` instead of
`broadcasts`.

* DEV: Make parameters optional to all FakeLogger methods

* FIX: Set `override_level` on Logster loggers (#27519)

A followup to f595d599dd361b7fb39fb3c82cbc11d19d518c19

* FIX: Don’t duplicate Rack response

---------

Co-authored-by: Jarek Radosz <jradosz@gmail.com>
2024-06-20 10:33:01 +02:00
5cb84f8dcf DEV: Revert rails 7.1 upgrade (#27522)
* Revert "FIX: Set `override_level` on Logster loggers (#27519)"

This reverts commit c1b0488c547bca935de51cfbb86bbc528e9ab2e5.

* Revert "DEV: Make parameters optional to all FakeLogger methods"

This reverts commit 3318dad7b4e3365854319bb55301cf667a2c28d0.

* Revert "FIX: Remove references to `Rails.logger.chained`"

This reverts commit f595d599dd361b7fb39fb3c82cbc11d19d518c19.

* Revert "DEV: Upgrade Rails to 7.1"

This reverts commit 081b00391e47a7f9bc44b9fe8ce88ac97d728352.
2024-06-18 23:48:30 +02:00
081b00391e DEV: Upgrade Rails to 7.1 2024-06-18 15:58:05 +02:00
6b872c4c53 FIX: Bump reject_reason limit for reviewables to 2000 characters (#27507)
Followup 783c935dcb7f114c206da4fe9c46c91ca5c687f3

Some admins were finding that the limit introduced above was
too short especially when sending an email to rejected users.
This commit bumps the limit from 500 to 2000 and also fixes
an issue where the friendly error message was not shown in
the browser.

c.f. https://meta.discourse.org/t/500-character-reject-reason-is-too-small-a-limit/291884
2024-06-18 15:49:58 +10:00
2a28cda15c DEV: Update to lastest rubocop-discourse 2024-05-27 18:06:14 +02:00
9762e65758 FEATURE: Add Revise... option for queued post reviewable (#23454)
This commit adds a new Revise... action that can be taken
for queued post reviewables. This will open a modal where
the user can select a Reason from a preconfigured list
(or by choosing Other..., a custom reason) and provide feedback
to the user about their post.

The post will be rejected still, but a PM will also be sent to
the user so they have an opportunity to improve their post when
they resubmit it.
2023-10-13 11:28:31 +10:00
4b52269827 DEV: Move option to delete user under reviewable reject menu (#23257)
Follow-up to #23199 in which we moved the "delete user" options under the relevant action menu for flagged post. This change does the same, but to queued posts.
2023-08-27 10:05:05 +08:00
12cdd7db1a DEV: Move option to delete user under reviewable agree menu (#23199)
As per discussion, we want to move the options to delete the user under the "Yes" menu of the review queue, since these options are often the most recommended, but also frequently missed because they are tucked away under their own menu.

In addition to the move, I removed the title case of the options so that it matches the other options in the "Yes" menu.
2023-08-25 10:53:56 +08:00
87ebbec9b2 FIX: Pending post deletion by creator (#23130)
`ReviewableQueuedPost` got refactored a while back to use the more
appropriate `target_created_by` for the user of the post being queued
instead of `created_by`. The change was not extended to the `DELETE
/review/:id` endpoint leading to error responses for a user attempting
to deleting their own queued post.

This fix extends the `Reviewable` lookup implementation in
`ReviewablesController#destroy` and Guardian implementation to account
for this change.
2023-08-18 15:30:59 +00:00
81cf481b16 FIX: Missing pending queued posts from topic view (#22838)
A previous change updated `ReviewableQueuedPost`'s `created_by`
to be consistent with other reviewable types. It assigns
the the creator of the post being queued to `target_created_by` and sets
the `created_by` to the creator of the reviewable itself.

This fix updates some of the `created_by` references missed during the
intial fix.
2023-07-28 16:16:23 +00:00
3d554aa10e FIX: Keep ReviewableQueuedPosts even with user delete reviewable actions (#22501)
Performing a `Delete User`/`Delete and Block User` reviewable actions for a
queued post reviewable from the `review.show` route results in an error
popup even if the action completes successfully.

This happens because unlike other reviewable types, a user delete action
on a queued post reviewable results in the deletion of the reviewable
itself. A subsequent attempt to reload the reviewable record results in
404. The deletion happens as part of the call to `UserDestroyer` which
includes a step for destroying reviewables created by the user being
destroyed. At the root of this is the creator of the queued post
being set as the creator of the reviewable as instead of the system
user.

This change assigns the creator of the reviewable to the system user and
uses the more approapriate `target_created_by` column for the creator of the
post being queued.
2023-07-18 11:50:31 +00:00
110393e438 DEV: Remove deprecated Reviewable#post_options method (#22595)
The attribute Reviewable#post_options was deprecated (and replaced by #payload) four years ago, and marked for deletion in 2.9.0. This commit removes it.
2023-07-13 22:29:40 +08:00
783c935dcb DEV: Set limits for text fields in reviewables 2023-05-03 09:54:54 +02:00
6c90747dea FIX: correctly use types for reviewables type (#21333)
Before this fix if the underlying model of a reviewable was changed, the filter wouldn't work anymore as it was expecting a 1:1 relation between filter type and model name.

This commit also relies on the `Reviewable.types` array to check against valid types instead of a regex not checking much.

Finally this commit adds a spec to ensure chat reviewables are listable from the review index page.
2023-05-02 14:21:14 +02:00
366ff0e76b FIX: Don't display destroy reviewable button on client (#21226)
# Context

https://meta.discourse.org/t/missing-translate-in-review-page/262604

![image](https://user-images.githubusercontent.com/50783505/234089049-72332040-e7d5-4081-824a-b0b36e37187a.png)

An additional button was added as a result of dd495a0e19 which was intended to grant access to deleting reviewable from the API. 

We were being too flexible by only checking if the user was an admin

012aaf0ba3/lib/guardian.rb (L237)

where it should instead by scoped to check if the request was an API call.

# Fix

https://github.com/discourse/discourse/pull/21226/files#diff-0a2548be4b18bd4ef2dffb3ef8e44984d2fef7f037b53e98f67abea52ef75aa2R237

# Additions

Added a new guard of `is_api?`

https://github.com/discourse/discourse/pull/21226/files#diff-0a2548be4b18bd4ef2dffb3ef8e44984d2fef7f037b53e98f67abea52ef75aa2R657-R660

In `app/models/reviewable.rb` we check if the user has the permissions to the destroy action via the `Guardian`. To do this we were instantiating a new `Guardian` class which then caused us to lose the context of the request. The request is a necessary component in the guard of `is_api?` so we needed to pass the already defined Guardian from the `app/controllers/reviewables_controller.rb` to the `#perform` method to ensure the request is present.
2023-04-24 20:22:37 -05:00
a5235f7d16 DEV: Refactor STI/polymorphic associations in chat (#20789) 2023-04-17 15:41:56 +02:00
12a18d4d55 DEV: properly namespace chat (#20690)
This commit main goal was to comply with Zeitwerk and properly rely on autoloading. To achieve this, most resources have been namespaced under the `Chat` module.

- Given all models are now namespaced with `Chat::` and would change the stored types in DB when using polymorphism or STI (single table inheritance), this commit uses various Rails methods to ensure proper class is loaded and the stored name in DB is unchanged, eg: `Chat::Message` model will be stored as `"ChatMessage"`, and `"ChatMessage"` will correctly load `Chat::Message` model.
- Jobs are now using constants only, eg: `Jobs::Chat::Foo` and should only be enqueued this way

Notes:
- This commit also used this opportunity to limit the number of registered css files in plugin.rb
- `discourse_dev` support has been removed within this commit and will be reintroduced later

<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2023-03-17 14:24:38 +01:00
666536cbd1 DEV: Prefer \A and \z over ^ and $ in regexes (#19936) 2023-01-20 12:52:49 -06:00
5a003715d3 DEV: Apply syntax_tree formatting to app/* 2023-01-09 14:14:59 +00:00
3ff6f6a5e1 FIX: Exclude claimed reviewables from user menu (#19179)
Users who can access the review queue can claim a pending reviewable(s) which means that the claimed reviewable(s) can only be handled by the user who claimed it. Currently, we show claimed reviewables in the user menu, but this can be annoying for other reviewers because they can't do anything about a reviewable claimed by someone. So this PR makes sure that we only show in the user menu reviewables that are claimed by nobody or claimed by the current user.

Internal topic: t/77235.
2022-12-01 07:09:57 +08:00
94aba90c56 DEV: Delete reviewable associations when deleting (#18472) 2022-10-05 13:38:41 -03:00
4d05e3edab DEV: Include pending reviewables in the main tab in the user menu (#18471)
This commit makes pending reviewables show up in the main tab (a.k.a. "all notifications" tab). Pending reviewables along with unread notifications are always shown first and they're sorted based on their creation date (most recent comes first).

The dismiss button currently only shows up if there are unread notifications and it doesn't dismiss pending reviewables. We may follow up with another change soon that allows makes the dismiss button work with reviewables and remove them from the list without taking any action on them. 

Follow-up to 079450c9e4.
2022-10-05 12:30:02 +03:00
079450c9e4 DEV: Do not show handled reviewables in the user menu (#18402)
Currently, the reviewables tab in the user menu shows pending reviewables at the top of the menu and fills the remaining space in the menu with old/handled reviewables. This PR makes the revieables tab show only pending reviewables and hides the tab altogether from the menu if there are no pending reviewables. We're going to follow-up with another change soon that will show pending reviewables in the main tab of the user menu.

Internal topic: t/73220.
2022-09-30 06:10:07 +03:00
26fe047724 DEV: Use AR enums in reviewables related code
This is the first patch of many to replace our custom enums in Ruby by
the ones provided by `ActiveRecord`.
2022-09-22 14:44:27 +02:00
ce9eec8606 DEV: Combine all header notification bubbles into one in the new user menu (#17718)
Extracted from https://github.com/discourse/discourse/pull/17379.
2022-08-03 08:57:59 +03:00
988a175e94 DEV: Add reviewables tab to the new user menu (#17630)
This commit is a subset of the changes proposed in https://github.com/discourse/discourse/pull/17379.
2022-07-28 11:16:33 +03:00
1441226b1a DEV: Don't polute all ActiveRecord classes (#15103)
`pending`, `approved`, `rejected`, `ignored`, and `deleted` scope method were accessible on all model classes… 😂

Fixes `Creating scope :pending. Overwriting existing method DiscoursePostEvent::EventDate.pending.` warnings.
2021-11-26 10:17:10 +08:00
e7c0bbb9c0 DEV: Let's always give a drop_from param to deprecate (#14901)
So that we know when deprecations can be removed in the future.
2021-11-12 08:52:59 -06:00
079d2af55f FIX: Clear stale status of reloaded reviewables (#13750)
* FIX: Clear stale status of reloaded reviewables

Navigating away from and back to the reviewables reloaded Reviewable
records, but did not clear the "stale" attribute.

* FEATURE: Show user who last acted on reviewable

When a user acts on a reviewable, all other clients are notified and a
generic "reviewable was resolved by someone" notice was shown instead of
the buttons. There is no need to keep secret the username of the acting
user.
2021-07-16 19:57:12 +03:00
14a13dc192 FIX: Check type of existing reviewables when new reviewable is created (#13662) 2021-07-07 11:45:00 -05:00
4dc8c3c409 FEATURE: Blocking is optional when deleting a user from the review queue. (#13375)
Subclasses must call #delete_user_actions inside build_actions to support user deletion. The method adds a delete user bundle, which has a delete and a delete + block option. Every subclass is responsible for implementing these actions.
2021-06-15 12:35:45 -03:00
197e3f24ce FEATURE: Show stale reviewable to other clients (#13114)
The previous commits removed reviewables leading to a bad user
experience. This commit updates the status, replaces actions with a
message and greys out the reviewable.
2021-05-26 09:47:35 +10:00
d4b5a81b05 FIX: Recalculate scores only when approving or transitioning to pending. (#13009)
Recalculating a ReviewableFlaggedPost's score after rejecting or ignoring it sets the score as 0, which means that we can't find them after reviewing. They don't surpass the minimum priority threshold and are hidden.

Additionally, we only want to use agreed flags when calculating the different priority thresholds.
2021-05-10 14:09:04 -03:00
fa393b2956 FEATURE: add reviewable score updated webhook (#12846)
Adds a webhook to notify when a reviewable score is updated.

This is different from created or status changed as additional flags can
roll in and update the score without updating status. Useful for applications
looking to integrate in with Discourse's scores
2021-04-26 17:40:32 -07:00
60059a7190 FEATURE: A low priority filter for the review queue. (#12822)
This filter hides reviewables with a score lower than the "reviewable_low_priority_threshold" setting. We only use reviewables that already met this threshold to calculate the Medium and High priority filters.
2021-04-23 15:34:24 -03:00