Oh, das würde mir überhaupt nichts ausmachen. Es wäre ideal, wenn die primäre Aktion des Dropdown-Buttons „Benutzer löschen
3 „Gefällt mir“
@Roman, möchtest du diesen Eintrag zu deiner Liste hinzufügen? Ich sehe ihn als nützlich für Seiten mit SSO.
7 „Gefällt mir“
Wenn wir Benutzer aus der Bewertungs-Warteschlange löschen, erscheint ein Popup mit ‘404 Not Found’:
(Wir haben gerade auf die neueste Version aktualisiert, das Problem besteht weiterhin)
3 „Gefällt mir“
Ich werde mir das ansehen. Warten diese Benutzer auf eine Freigabe?
3 „Gefällt mir“
Genehmigung + Löschen von Benutzern, die wegen Spam-Meldungen markiert wurden.
2 „Gefällt mir“
Mir ist gerade aufgefallen, dass ich auch eine andere Seite verwalte, wo das nicht passiert, und ich habe eine leise Vermutung, dass dies mit dem Follow Plugin 
zusammenhängen könnte, da es dort kürzlich Änderungen gab, die gelöschte Benutzer betrafen. @merefield, was denkst du?
1 „Gefällt mir“
Im Moment keine Ahnung. Können Sie etwas genauer werden? Log-Nachweise?
Registerkarte „Netzwerk“ im Browser: Wie lautet die URL dieses 404-Fehlers?
Das einzige (geringfügige) Problem mit dem Plugin aktuell (soweit mir bekannt) ist, dass Sie die zugehörigen Benachrichtigungen löschen müssen, wenn Sie das Plugin deinstallieren (Skript im Plugin-OP). Das hat nichts mit gelöschten Benutzern zu tun.
1 „Gefällt mir“
Ich konnte das Problem lokal ebenfalls nicht reproduzieren. Die Fehlermeldung lässt mich vermuten, dass das Frontend eine Ajax-Anfrage an ein nicht vorhandenes Endpunkt sendet. @bartv Könntest du den Netzwerkreiter deines Browsers nach dem Durchführen der Löschaktion teilen?
Ich würde gerne wissen, ob es so aussieht:
4 „Gefällt mir“
Das werde ich beim nächsten Mal machen 
1 „Gefällt mir“
Das Plugin patcht den UserDestroyer, der aufgerufen wird, wenn du die Löschaktion aus der Review-Warteschlange ausführst. Das sieht verdächtig aus:
Wenn following_ids irgendwie eine ungültige ID enthält, wirft User#find eine Ausnahme, und der Benutzer sieht eine “404 Not Found”-Meldung. Ich empfehle stattdessen User.find_by(id: ...) zu verwenden.
Ich kann nicht sagen, ob dies auf der Seite von @bartv passiert ist, ohne die Datenbank einzusehen. Daher empfehle ich beim nächsten Mal, die following_ids des gemeldeten Benutzers zu prüfen.
4 „Gefällt mir“
Danke. Das stimmt und ist ein sehr nützlicher Hinweis.
Ich würde dennoch gerne die Logs und die 404-URL bestätigt haben.
Es gibt wahrscheinlich noch weitere Möglichkeiten, dies robuster zu gestalten.
4 „Gefällt mir“
Gepusht: FIX: make code invoked when deleting users more robust · discourse/discourse-follow@b523b3a · GitHub danke!
3 „Gefällt mir“
Wir haben einen PR zusammengeführt, um diese Aktion hinzuzufügen. Bestätigen, Bestätigen + Löschen und Bestätigen + Suspendieren sind nun gebündelt:
4 „Gefällt mir“
Ich habe das Follow-Plugin entfernt, aber mein Problem besteht weiterhin. Im Rails-Log sehe ich:
Started PUT "/review/6793/perform/reject_user_block?version=0" for xx.xx.xx.xx at 2020-09-03 09:45:48 +0000
Processing by ReviewablesController#perform as */*
Parameters: {"version"=>"0", "reviewable_id"=>"6793", "action_id"=>"reject_user_block"}
Job exception: undefined method `strip' for nil:NilClass
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Started GET "/t/global-variables/331828" for xx.xx.xx.xx at 2020-09-03 09:45:48 +0000
Processing by TopicsController#show as HTML
Parameters: {"slug"=>"global-variables", "topic_id"=>"331828"}
Completed 404 Not Found in 292ms (ActiveRecord: 0.0ms | Allocations: 124598)
ActiveRecord::RecordNotFound (Couldn't find all Topics with 'id': (1185852, 1185853, 1186324, 1186929, 1191089) [WHERE ("topics"."deleted_at" IS NULL)] (found 4 results, but was looking for 5).)
lib/plugin/instance.rb:393:in `block in on'
lib/discourse_event.rb:14:in `block in trigger'
lib/discourse_event.rb:13:in `trigger'
app/models/user.rb:1567:in `trigger_user_destroyed_event'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:340:in `block in with_resolved_locale'
app/controllers/application_controller.rb:340:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/008-rack-cors.rb:25:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
Die Zeile ActiveRecord::RecordNotFound ist interessant, da sie jedes Mal erscheint, wenn ich versuche, einen Benutzer aus der Warteschlange zu löschen, und zwar immer mit denselben Topic-IDs.
Ich habe die Topic-IDs überprüft und es handelt sich dabei um alle Beiträge, die das Events-Plugin verwenden. Und tatsächlich wurde einer davon gelöscht. Ich bin verwirrt, warum diese Aktion aus der Warteschlange trotzdem nach diesen sucht?
@merefield scheint, als würde ich euch wieder einmal belästigen, sorry 
EDIT: Plugin-Link geändert
3 „Gefällt mir“
Das ist ein Kern-Plugin.
1 „Gefällt mir“
Moment, ich verwende
git clone GitHub - angusmcleod/discourse-events: Allows you to manage events in Discourse · GitHub
Ist das nicht der richtige (mehr)? (Ich glaube, ich habe dort auf die falsche Seite verlinkt, ich korrigiere das gerade)
1 „Gefällt mir“
Das sind Events. @fzngagan, hast du dazu Gedanken?
3 „Gefällt mir“
Beim Klicken werde ich zum richtigen Repository weitergeleitet.
1 „Gefällt mir“
Haha, nein, das Problem betrifft das Löschen eines Benutzers aus der Prüfwarteschlange.
4 „Gefällt mir“
Das hat nichts mit einem Plugin zu tun, es handelt sich um eine Kernbibliotheksdatei.
Warum glaubst du, dass Events involviert ist?
3 „Gefällt mir“