# Aktion „Aussetzen“ zu den Lösungsoptionen für Flaggen „Benutzer benötigt Freigabe“ hinzufügen
**URL:** https://meta.discourse.org/t/add-suspend-action-to-review-resolution-options-for-user-needs-approval-flags/408891
**Category:** Feature
**Tags:** review-queue, fixed
**Created:** [30. Juli 2026 um 04:15 UTC](https://meta.discourse.org/t/add-suspend-action-to-review-resolution-options-for-user-needs-approval-flags/408891 "2026-07-30T04:15:08Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@per1234](https://meta.discourse.org/u/per1234)
#### Post date: [30. Juli 2026 um 04:15 UTC](https://meta.discourse.org/t/add-suspend-action-to-review-resolution-options-for-user-needs-approval-flags/408891/1 "2026-07-30T04:15:09Z")
### Feature-Beschreibung:
Eine gängige Spam-Methode besteht darin, Benutzerkonten zu erstellen, die im Profil Werbekontent enthalten (typischerweise einen Link, aber möglicherweise auch die Bio).
Discourse verfügt über ein [“Verdächtige Benutzer genehmigen”-System](https://meta.discourse.org/t/discourse-2-4-0-beta11-release-notes/141548#p-700363-suspect-users-sent-to-review-queue-6), das automatisch “Benutzer benötigt Genehmigung”-Flags für diese Konten setzt.
Bitte fügen Sie eine “Benutzer sperren”-Option zu den Aktionen hinzu, die der Moderator bei der Überprüfung der von diesem System gesetzten Flags ausführen kann.
🙂 Die Flags können auf eine Weise aufgelöst werden, die ein “Rückgängig machen” ermöglicht, falls das automatisierte System einen falschen Positivwert liefert und der Prüfer das Flag nicht sorgfältig genug überprüft, um dies zu erkennen.
### Aktuelles Verhalten:
Das Überprüfungssystem bietet nur drei Optionen zur Auflösung der “Benutzer benötigt Genehmigung”-Flags:
- **Ja \> Benutzer löschen**
- **Ja \> Benutzer löschen und blockieren**
- **Nein**
Dies zwingt den Prüfer zu einem der beiden folgenden ungünstigen Arbeitsabläufe:
- Den Benutzer löschen. Dies führt zu irreversiblen Schäden, wenn der Prüfer einen Fehler macht. Alle automatisierten Systeme sind anfällig für falsche Positivwerte und alle Menschen machen Fehler, sodass das Eintreten dieses Schadens nicht eine Frage des Ob, sondern des Wann ist.
- Auf die **Nein** -Schaltfläche klicken und den Benutzer dann manuell über die Kontoadmin-Seite sperren. Dies ist ein völlig unintuitiver Arbeitsablauf und ineffizient.
### Discourse-Version:
`ba63d427fd88c5d83cb18695b16dbdbfad6fa834`
### Zusätzlicher Kontext:
Wir haben eine strikte Richtlinie gegen das Löschen von Konten auf meinem Forum. Das schlechte Design der Überprüfungsoberfläche für diese Flags hat meiner Forengemeinschaft aufgrund der Nachwirkungen des Entzugs der Berechtigungen eines Moderators, der sich weigerte, die Richtlinie bei der Überprüfung dieser Flags einzuhalten, großen Schaden zugefügt.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [30. Juli 2026 um 07:09 UTC](https://meta.discourse.org/t/add-suspend-action-to-review-resolution-options-for-user-needs-approval-flags/408891/2 "2026-07-30T07:09:58Z")
Eine ähnliche Anfrage gibt es unter [Suspend from Review Queue - #5 by davemaxwell](https://meta.discourse.org/t/suspend-from-review-queue/225660/5).
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [31. Juli 2026 um 08:13 UTC](https://meta.discourse.org/t/add-suspend-action-to-review-resolution-options-for-user-needs-approval-flags/408891/4 "2026-07-31T08:13:39Z")
Ich habe mein Bestes gegeben, um die Optionen auf allen „Review“-Bildschirmen konsistent zu gestalten
>
>
> Previously, suspect-user reviewables ("user needs approval" flags) and queued-po…st reviewables could only be resolved by deleting the user or rejecting the post outright — a reviewer mistake on an automated false positive was irreversible, and sites with no-deletion policies had to resolve the flag and then manually suspend the user from their admin page. Requested in \[meta t/408891\](https://meta.discourse.org/t/408891) and \[meta t/225660\](https://meta.discourse.org/t/225660).
>
> This change adds guardian-gated \*\*Silence user\*\* / \*\*Suspend user\*\* resolutions to both queues via a shared \`build\_penalty\_actions\` helper, using the same penalize-modal flow the flagged-post and review-every-post queues already use (staff log linked back to the reviewable). Along the way it:
>
> \- hides penalty actions that are already active everywhere (previously a resolve-then-409 dead end), and fixes the penalize modal's unawaited \`before()\` race so the penalty is only applied once the reviewable action succeeded;
> \- narrows the rejected-user \*\*scrub\*\* affordance to records whose identity snapshot is the last remaining copy (user deleted, or renamed/anonymized after a failed deletion), admin-gated to match the endpoint;
> \- shows an active penalty (localized end date and reason) on the reviewable user card, so it's clear why a penalty option is absent;
> \- preloads \`anonymous\_user\_master\` on the queue since the new \`silenced?\` gates would otherwise lazy-load it per row;
> \- rewrites the action descriptions in one consistent voice.
>
> \
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [2. August 2026 um 08:35 UTC](https://meta.discourse.org/t/add-suspend-action-to-review-resolution-options-for-user-needs-approval-flags/408891/6 "2026-08-02T08:35:31Z")