Oh, cela ne me dérange pas du tout. Même si l’action principale du bouton déroulant était « Supprimer l’utilisateur » et que, via le menu déroulant, on pouvait choisir « Suspendre l’utilisateur » à la place, ce serait idéal. De cette façon, en supposant que la plupart des configurations ne soient pas basées sur SSO, aucun travail supplémentaire ne serait ajouté pour eux, tandis que ceux qui sont dans cette situation auraient un moyen rapide de suspendre un utilisateur plutôt que de le supprimer.
@Roman, veux-tu ajouter celui-ci à ta liste ? Je le vois comme utile pour les sites avec SSO.
Lorsque nous supprimons des utilisateurs de la file d’attente de révision, une fenêtre contextuelle « 404 Non trouvé » s’affiche :
(J’ai effectué la mise à jour vers la dernière version, mais le problème persiste)
Je vais jeter un coup d’œil. Ces utilisateurs sont-ils en attente d’approbation ?
Approbation + suppression des utilisateurs signalés pour spam.
Je viens de réaliser que je gère également un autre site où cela ne se produit pas, et j’ai un léger soupçon que cela pourrait être lié au Plugin Follow
, car il a récemment connu des modifications concernant les utilisateurs supprimés. @merefield, qu’en penses-tu ?
Je n’en ai aucune idée pour le moment. Pouvez-vous être plus précis ? Des preuves dans les journaux ?
Onglet Réseau dans le navigateur : quelle est l’URL de cette erreur 404 ?
Le seul problème (mineur) avec le Plugin actuellement (à ma connaissance) est que vous devez supprimer les notifications associées si vous désinstallez le plugin (script dans le premier message du plugin). Cela n’est pas lié aux utilisateurs supprimés.
Je n’ai pas non plus réussi à reproduire le problème localement. Le message d’erreur me laisse penser que le frontend effectue une requête AJAX vers un point de terminaison inexistant. @bartv, pourriez-vous partager l’onglet réseau de votre navigateur après avoir effectué l’action de suppression ?
J’aimerais savoir si cela ressemble à ceci :
Je le ferai la prochaine fois que cela arrivera ![]()
Le plugin patche de manière dynamique le UserDestroyer, qui est appelé lorsque vous effectuez l’action de suppression depuis la file d’examen. Cela semble suspect :
Si following_ids inclut un identifiant invalide, User#find lèvera une exception et l’utilisateur verra un message « 404 Not Found ». Je recommande d’utiliser User.find_by(id: ...) à la place.
Je ne peux pas dire si c’est ce qui s’est produit sur le site de @bartv sans examiner la base de données, donc la prochaine fois que cela se produit, je recommande de vérifier les following_ids de l’utilisateur signalé.
Merci. C’est exact et c’est un point très utile.
Je souhaiterais toujours obtenir les journaux et confirmer l’URL 404.
Il existe probablement encore d’autres moyens de rendre cela plus robuste.
Poussé : FIX: make code invoked when deleting users more robust · discourse/discourse-follow@b523b3a · GitHub merci !
Nous avons fusionné une PR pour ajouter cette action. « Confirmer », « Confirmer + Supprimer » et « Confirmer + Mettre en suspens » sont maintenant regroupés :
J’ai désactivé le plugin Follow et mon problème persiste. Dans le journal Rails, je vois :
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'
La ligne ActiveRecord::RecordNotFound est intéressante car elle apparaît à chaque fois que j’essaie de supprimer un utilisateur de la file d’examen, et avec exactement les mêmes identifiants de sujet.
J’ai vérifié les identifiants de sujet et il s’agit tous de publications utilisant le plugin Events. Et effectivement, l’un d’eux a été supprimé. Je suis perplexe quant à la raison pour laquelle cette action depuis la file d’examen vérifierait ces éléments.
@merefield, il semble que je revienne vers vous à nouveau, désolé ![]()
EDIT : lien du plugin modifié
C’est un plugin de base.
Attendez, j’utilise
git clone GitHub - angusmcleod/discourse-events: Allows you to manage events in Discourse · GitHub
Ce n’est pas le bon (plus) ? (Je pense que j’ai peut-être lié vers la mauvaise page là-bas, je corrige)
Ce sont des événements. @fzngagan, tu as des avis là-dessus ?
En cliquant dessus, je suis redirigé vers le bon dépôt.
Haha, non, le problème concerne la suppression d’un utilisateur de la file d’attente de revue.
Ceci n’est pas lié à un plugin, c’est un fichier de bibliothèque du cœur.
Pourquoi pensez-vous que Events est impliqué ?


