Commit Graph

13 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
77f63a45d3 FIX: Use site contact user + group for Revise... review action (#29271)
Followup 9762e6575841889d50275cb6026e4482d8091857

When we added the Revise... option for posts/new topics
in the review queue, which sends a PM to the user, we used
`SystemMessage.create_from_system_user`, which always sends
the PM from the system user. However, this makes it so if the
user replies to the PM, which they are encouraged to do,
no one will see it unless they actively monitor the system inbox.

This commit changes it so `SystemMessage.create` is used,
which uses the `site_contact_username` and `site_contact_group`
site settings as participants in the sent PM. Then, when the
user replies, it will send to that inbox instead.

If `site_contact_username` is blank, the system user is used.
2024-10-28 09:40:10 +10:00
e0a0a13a91 FIX: Fix broken client-side review actions (#29025)
After #28603, the options "agree and suspend" and "agree and silence" in the review queue weren't working. This was happening because the optionalService, when used as a decorator, needs a name argument to work properly. We were also lacking tests for this.
2024-09-30 13:27:25 +08:00
581dbca97f DEV: Update Reviewables agree and edit action test (#27162) 2024-05-24 12:20:30 -07:00
755f8de6d4 FEATURE: add agree and edit (#27088)
* FEATURE: add agree and edit

adds agree and edit - an alias for agree and keep -- but with a client action to
edit the post in the composer before the flag is agreed with

---------

Co-authored-by: Juan David Martinez <juan@discourse.org>
2024-05-23 11:21:42 -07:00
6e161d3e75 DEV: Allow fab! without block (#24314)
The most common thing that we do with fab! is:

    fab!(:thing) { Fabricate(:thing) }

This commit adds a shorthand for this which is just simply:

    fab!(:thing)

i.e. If you omit the block, then, by default, you'll get a `Fabricate`d object using the fabricator of the same name.
2023-11-09 16:47:59 -06:00
44c84413fb DEV: upgrade reject reason reviewable modal to glimmer component (#24073)
* DEV: add system test for rejecting user from review page
* DEV: upgrade reject-reason-reviewable modal to glimmer & DModal
2023-10-24 17:44:43 +08: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
61571bee43 UX: Add show more button to long post queued reviewables (#23075) 2023-08-14 10:11:30 -07:00
d753e00eb5 DEV: Avoid waiting full Capbyara default wait timeout in system tests (#22684)
Avoid using negated matchers with custom RSpec matchers that rely on
`has_css?` as it'll result in Capybara waiting the full default wait
time.
2023-07-19 14:23:43 +08: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
41f8bff2c3 DEV: Remove superfluous js: true metadata (#21960)
Why this change?

It is very unlikely that we need to ever JS for system tests considering
that we rely on a JS framework on the frontend.
2023-06-07 09:26:58 +08:00
9616a08fa6 UX: Add show more btn to reviewable item (#21579) 2023-06-01 11:55:27 -07:00