If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?
End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue
This is an interesting use case and I’d like to help you get it working.
Actions for reviewable types are returned from the build_actions method.
What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.
That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.
Robin,
Je prépare actuellement une PR pour le plugin Discord OAuth, principalement afin de stocker davantage d’informations sur les utilisateurs Discord dans Discourse. J’essaie d’utiliser votre modèle ReviewableUser pour conserver la fonctionnalité d’approbation automatisée.
Comme l’implémentation actuelle crée une revue pour les nouveaux utilisateurs de manière asynchrone, je dois vérifier si une telle revue a été créée et la supprimer.
Malheureusement, je rencontre une erreur Ruby très étrange et je me demandais si vous l’aviez déjà rencontrée.
Le code est le suivant :
def after_create_account(user, auth)
super
data = auth[:extra_data]
if !user.approved && data[:auto_approve]
user.approved = true
user.approved_by_id = Discourse.system_user.id
if reviewable_user = ReviewableUser.find_by(target: user)
reviewable_user.set_approved_fields!(user, Discourse.system_user)
end
end
end
Dès que j’exécute ReviewableUser.find_by, une exception est levée :
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
Bien que je pense faire de bons progrès en Ruby, je ne comprends pas pourquoi cela se produit.
Est-ce un problème de chemin ? J’ai essayé plusieurs require, mais cela empire rapidement.
Cela ressemble beaucoup à des modèles similaires ailleurs dans le code de base. Toute suggestion serait grandement appréciée !
Le dépôt est disponible ici si nécessaire : discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
Cette erreur constante n’est pas très informative, n’est-ce pas ! Je pense que cela a à voir avec les moteurs Rails et les espaces de noms. Une chose rapide que vous pouvez essayer est ::ReviewableUser avec les deux deux-points devant. Cela lui indique d’utiliser l’espace de noms racine, et non celui du moteur.
Ce code semble également quelque peu obsolète pour l’API reviewable. Il devrait ressembler à ceci :
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
Cela a résolu l’erreur. Je suppose que, comme il ne trouvait pas la classe auparavant, il la traitait comme une constante ? En tout cas, c’est résolu, génial, merci beaucoup ! Je suis débloqué !
La raison pour laquelle j’avais ceci :
user.approved = true
user.approved_by_id = Discourse.system_user.id
avant :
reviewable.perform(:approve, Discourse.system_user)
est que l’ajout à la file d’examen est asynchrone. Dans le job, l’examen n’est créé que si approve est faux (discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub) :
if user = User.find_by(id: args[:user_id])
return if user.approved?
@reviewable = ReviewableUser.needs_review!(
target: user,
created_by: Discourse.system_user,
reviewable_by_moderator: true,
payload: {
username: user.username,
name: user.name,
email: user.email
}
)
Il existe un risque que le job s’exécute après que vous ayez testé l’entrée d’examen ?
Le résultat est que l’entrée d’examen semble ne pas exister, mais le job est simplement en attente d’exécution. Le job s’exécute ensuite et crée l’entrée d’examen, et vous avez manqué l’opportunité de la supprimer car votre code de test a déjà été exécuté.
C’est une condition de course potentielle ?
Définissez approved à true avant de vérifier l’entrée d’examen et vous aurez résolu le problème (car un examen ne sera jamais créé après cela, car c’est une dépendance).
J’ai rencontré ce problème en testant mon code : sur dev, cela fonctionnait, puis en production, cela a échoué car les choses s’exécutaient dans un ordre différent.
NB : J’apprécie que vous n’ayez pas écrit cela pour prendre en charge ce cas d’utilisation, mais je pense qu’il est important de permettre aux plugins de pouvoir approuver automatiquement les nouveaux utilisateurs dans des circonstances spéciales (par exemple, comme le plugin Discord qui le fait si l’utilisateur est membre d’un guildes de confiance).
En effet, le dossier révisable est créé de manière asynchrone, ce qui pose problème dans cette situation car la connexion crée l’utilisateur et le dossier d’approbation peut ne pas encore être présent.
Une meilleure solution consisterait à ne pas créer le dossier révisable dans ce cas, mais cela nécessiterait des modifications du cœur du système pour fonctionner correctement. Voici comment cela pourrait fonctionner :
skip_approval: true.Merci Robin, oui.
Pour l’instant, j’ai opté pour ma solution de contournement, conscient qu’elle devra être traitée avant la suppression de l’accès direct à l’API.
Est-ce que l’équipe serait disposée à prioriser cela avant la suppression de l’accès en écriture direct user.approve ?
Je pense que ce changement cassera la fonctionnalité actuelle d’auto-approbation des Guildes de confiance dans le plugin Auth Discord Login (même sans la PR que je viens de soumettre pour ce plugin). @featheredtoast
Je serais ravi de mettre à jour ma PR pour prendre en charge ce changement s’il est implémenté.
Je ne pense pas que nous allons le supprimer de sitôt. Je ne veux pas m’y fier éternellement, mais cela devrait tenir encore un certain temps.
La file d’attente est agréable et le regroupement par sujet est également utile.
Cependant, à ma connaissance, il n’existe aucun moyen de sélectionner et de traiter des publications en masse. Chaque publication doit être traitée individuellement.
La sélection et le traitement en masse seraient un vrai gain de temps !
Je pense que ce serait une excellente amélioration. Pour être honnête, la file d’attente des signalements n’a jamais eu d’opérations par lot, donc ce n’est pas une régression.
De plus, certaines opérations comme « Suspendre » sont un peu étranges lorsque vous travaillez sur plusieurs lignes. Il faudrait les restreindre aux opérations de base pour qu’elles aient un sens.
J’ai repéré un petit problème : quelqu’un a publié dans une catégorie nécessitant une approbation, ce qui fait apparaître le message dans la file d’examen. Il a posté dans la mauvaise catégorie, alors j’ai essayé de le déplacer depuis la file d’examen. Pas de souci, sauf que la catégorie vers laquelle je souhaite le déplacer exige une balise spécifique. Or, cette balise est restreinte à la nouvelle catégorie, tandis que le message en attente d’examen pense toujours se trouver dans la catégorie d’origine, qui n’autorise pas cette balise. Je suis donc bloqué. Il est assez simple d’approuver le message et de le modifier ensuite, mais cela semble être un problème qui devrait être corrigé.
Je sais que cela devrait être corrigé, mais les URL ne sont toujours pas ajoutées à la liste des URLs filtrées. Cela ne compte probablement même pas vraiment, car l’action pour les URLs filtrées indique « ne rien faire » de toute façon. C’est juste bizarre.
Juste pour confirmer que vous avez bien passé à la version correcte ? Ils devraient être filtrés s’ils ne sont pas compatibles onebox ou internes.
Oui, je suis sur la version v2.4.0.beta2 +66. La prochaine fois que cela se produira, je ferai une copie du message.
Oui, après avoir cliqué sur « Supprimer l’utilisateur » dans la file d’attente de modération, l’adresse e-mail et l’adresse IP ont été ajoutées aux listes de filtrage, mais pas les URLs. Le message était le suivant :
Besoin d'un [Service de rédaction académique](https://myassignmenthelp.com/uk/academic-writing-service.html) en ligne auprès du fournisseur n°1 mondial de services de rédaction académique, Myassignmenthelp.com. Service professionnel de rédaction académique offrant une large gamme de solutions pour les étudiants au meilleur prix.
À ma connaissance, les URL n’ont jamais été ajoutées automatiquement à la liste filtrée ? Eh bien, je suppose que si, j’ai vérifié mon instance et il y a toute une série d’URL là-dedans 
Ah oui, je me souviens maintenant. Elles ne font rien en réalité, elles sont purement informatives.
Vous pouvez ajouter ces noms de domaine aux mots surveillés pour empêcher leur saisie, mais vous devrez le faire vous-même.
C’est pourquoi il serait bien qu’ils soient ajoutés à la liste filtrée : même si aucune action automatique n’est entreprise sur les URL, cela nous permettrait de voir quel spam est publié. Gardez à l’esprit que les modérateurs peuvent utiliser la file d’examen, mais ne peuvent pas (je crois) ajouter des mots surveillés.
Quelques retours mineurs sur l’expérience utilisateur : il serait génial que la file d’attente de modération se souvienne de mes paramètres. Puisque nous travaillons avec une équipe de modérateurs, je suis personnellement surtout intéressé par la visualisation des nouveaux signalements et je trie par « Date de création », mais ce paramètre ne reste pas sauvegardé.
Ce n’est pas une mauvaise suggestion. Heureusement, il existe actuellement une solution de contournement : les filtres de recherche sont conservés dans la chaîne de requête (URL). Si vous enregistrez un filtre dans vos favoris, vous pourrez toujours y revenir.
