pangbo
28 december 2025 om 08:39
46
Currently, the registerReviewableActionModal interface in the frontend plugin API only registers modals to the old review queue layout:
However, the new layout fully supports this feature.
export function registerReviewableActionModal(actionName, modalClass) {
if (Object.keys(defaultActionModalClassMap).includes(actionName)) {
throw new Error(
`Cannot override default action modal class for ${actionName} (mapped to ${defaultActionModalClassMap[actionName].name})!`
);
}
actionModalClassMap[actionName] = modalClass;
}
I am curious as to whether this was an intentional design choice, or simply an oversight?
1 like
T_Disco:
A moderator may use the ‘Flag claimed by’ filter on the review queue to work through items that they’ve claimed, and as such, once action has been taken it would be useful to be able to unclaim the item so that it doesn’t appear in their ‘Flag claimed by’ list.
Ah, I understand. The difference with the new solution is that “unclaim” happens automatically after the review is actioned.
In case another moderator claimed but did not action, another moderator can remove the claim and then claim it themselves.
2 likes
Thank you for spotting this issue. Definitely, it was an oversight.
I have PR with the fix for this problem
https://github.com/discourse/discourse/pull/37023
2 likes
Recently the review queue starting popping up notifications about incoming email from newsletters. I now need to validate each known staged user posting in dedicated categories set up for receiving email. Before these were automatically creating topics, but now they’re filtered.
Yet, I didn’t see any way to put those users on an allow list. Is there any option to do so?
Ethsim2
11 september 2026 om 18:43
50
I found that adding logged_in_users to the site setting: skip review media groups ensures newly-created staged users post automatically to a topic rather than to the review queue.
I’ve also opened a test-only PR to confirm that the current behaviour where staged users match logged_in_users for this check is intentional, and therefore something that can be relied on without regressing in future:
main ← Ethsim12:dev-staged-email-media-exemption
drafted 04:56PM - 11 Sep 26 UTC
This adds regression coverage for media-containing incoming email from a newly-c… reated staged user when `logged_in_users` is included in `skip_review_media_groups`.
This came up in Meta topic 412025 following the staged-email media handling covered by #42515.
The new spec verifies that:
- a previously unknown sender is created as a staged user;
- their media-containing email creates a topic directly when `logged_in_users` is configured to skip media review; and
- no `ReviewableQueuedPost` is created.
This complements the existing test which verifies that the same kind of staged email is queued with `contains_media` when the sender is not in an exempt group.
No production code is changed.
One slightly surprising aspect of the current behavior is that staged users match the `logged_in_users` pseudo-group for this check. This PR makes that dependency explicit for review and regression coverage.
Tests:
- `bin/rspec spec/lib/email/receiver_spec.rb` — 213 examples, 0 failures
- `bin/rubocop spec/lib/email/receiver_spec.rb` — no offenses
- `git diff --check`
