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,
ich bereite derzeit einen PR für das Discord OAuth Plugin vor, um hauptsächlich weitere Discord-Benutzerinformationen in Discourse zu speichern. Ich versuche, dein ReviewableUser-Modell zu verwenden, um die Funktionalität für die automatisierte Freigabe beizubehalten.
Da die Implementierung derzeit asynchron eine Überprüfung für neue Benutzer startet, muss ich prüfen, ob eine solche Überprüfung erstellt wurde, und sie gegebenenfalls löschen.
Leider erhalte ich einen sehr seltsamen Ruby-Fehler und frage mich, ob dir dieser schon einmal begegnet ist.
Der Code lautet:
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
Sobald ReviewUser.find_by aufgerufen wird, erhalte ich eine Ausnahme:
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
Obwohl ich dachte, ich mache in Ruby gute Fortschritte, ist mir nicht klar, warum das passiert.
Ist es ein Pfadproblem? Ich habe eine Reihe von requires ausprobiert, aber das führt nur zu weiteren Problemen.
Es sieht sehr ähnlich aus wie vergleichbare Muster im Core-Code. Jegliche Gedanken dazu wären sehr willkommen!
Falls benötigt, hier das Repository: discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
Dieser ständige Fehler ist nicht gerade aussagekräftig, oder? Ich vermute, das liegt an Rails-Engines und Namespaces. Ein schneller Versuch, den du unternehmen könntest, ist ::ReviewableUser mit zwei Doppelpunkten davor. Das weist das System an, den Root-Namespace zu verwenden und nicht den des Engines.
Dieser Code wirkt zudem etwas veraltet für die Reviewable-API. Er sollte ungefähr so aussehen:
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
Das hat den Fehler behoben. Ich nehme an, da die Klasse zuvor nicht gefunden werden konnte, wurde sie als Konstante behandelt? Auf jeden Fall ist das Problem gelöst, großartig, vielen Dank! Ich bin wieder auf dem Damm!
Der Grund, warum ich dies:
user.approved = true
user.approved_by_id = Discourse.system_user.id
vor:
reviewable.perform(:approve, Discourse.system_user)
hatte, liegt daran, dass der Eintrag in die Warteschlange für Überprüfungen asynchron erfolgt. Im Job wird die Überprüfung nur erstellt, wenn approve falsch ist (siehe 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
}
)
Besteht nicht die Gefahr, dass der Job nachdem Sie den Eintrag in der Warteschlange geprüft haben, ausgeführt wird?
Das Ergebnis ist, dass der Eintrag in der Warteschlange anscheinend nicht existiert, aber der Job nur darauf wartet, ausgeführt zu werden. Der Job wird dann ausgeführt und erstellt den Eintrag, und Sie haben die Gelegenheit verpasst, ihn zu löschen, da Ihr Code zur Prüfung bereits ausgeführt wurde.
Ist das nicht eine potenzielle Race Condition?
Stellen Sie approved auf true, bevor Sie nach einem Eintrag in der Warteschlange suchen, und Sie haben das Problem gelöst (da nach diesem Zeitpunkt niemals eine Überprüfung erstellt wird, da dies eine Abhängigkeit darstellt).
Ich bin auf dieses Problem gestoßen, als ich meinen Code getestet habe – lokal hat es funktioniert, aber in der Produktion fehlgeschlagen, da die Dinge in einer anderen Reihenfolge abgelaufen sind.
Anmerkung: Ich weiß zu schätzen, dass Sie dies nicht für diesen Anwendungsfall geschrieben haben, aber ich halte es für wichtig, dass Plugins neue Benutzer unter besonderen Umständen automatisch genehmigen können (z. B. wie das Discord-Plugin, das dies tut, wenn der Benutzer Mitglied einer vertrauenswürdigen Gilde ist).
Tatsächlich wird der überprüfbare Datensatz asynchron erstellt, was in dieser Situation problematisch ist, da sich beim Einloggen der Benutzer erstellt und der Genehmigungsdatensatz möglicherweise noch nicht vorhanden ist.
Eine bessere Lösung wäre, in diesem Fall den überprüfbaren Datensatz nicht zu erstellen. Dies würde jedoch Änderungen am Kern erforderlich machen, damit es ordnungsgemäß funktioniert. Es könnte wie folgt umgesetzt werden:
skip_approval: true zurückgeben.Danke, Robin, ja.
Für den Moment habe ich mich für meine Workaround-Lösung entschieden, wobei mir bewusst ist, dass sie behoben werden muss, bevor der direkte API-Zugriff entfernt wird.
Hat das Team Interesse daran, dies zu priorisieren, bevor der direkte Schreibzugriff auf user.approve entfernt wird?
Ich bin der Meinung, dass diese Änderung die aktuelle Funktion „Vertrauenswürdige Guild-Auto-Approve
Ich kann nicht erkennen, dass wir das in absehbarer Zeit entfernen werden. Ich möchte mich nicht ewig darauf verlassen, aber es sollte noch eine Weile funktionieren.
Die Warteschlange ist schön, und die Gruppierung nach Themen ist ebenfalls nützlich.
Soweit ich das beurteilen kann, gibt es jedoch keine Möglichkeit, Beiträge massenhaft auszuwählen und zu bearbeiten. Jeder Beitrag muss einzeln verarbeitet werden.
Eine Massenauswahl und -verarbeitung wäre eine echte Zeitersparnis!
Ich denke, das wäre eine großartige Verbesserung. Um fair zu sein, hatte die Flag-Warteschlange nie Massenoperationen, also ist das keine Regression.
Außerdem sind einige Aktionen wie „Suspendieren
Ich habe ein kleines Problem festgestellt: Jemand hat in einer Kategorie gepostet, die eine Freigabe erfordert, sodass der Beitrag in der Warteschlange zur Überprüfung erscheint. Der Beitrag wurde in der falschen Kategorie gepostet, also habe ich versucht, ihn in der Warteschlange zu ändern. Das ging eigentlich problemlos, außer dass die Kategorie, in die ich ihn verschieben möchte, ein bestimmtes Tag erfordert. Dieses Tag ist jedoch nur für die neue Kategorie freigegeben, und der Beitrag in der Warteschlange denkt immer noch, er befinde sich in der ursprünglichen Kategorie, die dieses Tag nicht erlaubt. Also stecke ich fest. Es wäre einfach, den Beitrag freizugeben und ihn danach zu ändern, aber es scheint, als müsste dies behoben werden.
Ich weiß, dass das behoben werden sollte, aber URLs werden weiterhin nicht zur überprüften Liste hinzugefügt. Es macht wahrscheinlich ohnehin keinen großen Unterschied, da die Aktion für überprüfte URLs sowieso „nichts tun
Nur zur Bestätigung: Haben Sie auf die richtige Version aktualisiert? Sie sollten aussortiert werden, wenn sie nicht Onebox-fähig oder intern sind.
Ja, ich bin bei v2.4.0.beta2 +66. Beim nächsten Mal werde ich eine Kopie des Beitrags anfertigen.
Ja, nachdem ich im Überprüfungs-Queue auf „Benutzer löschen
URLs wurden meines Wissens nach noch nie automatisch zur geprüften Liste hinzugefügt? Nun, ich schätze doch, ich habe meine Instanz überprüft und dort sind einige URLs 
Ah ja, jetzt fällt es mir wieder ein. Sie tun eigentlich nichts, sie dienen nur der Information.
Du kannst diese Domainnamen zu den überwachten Wörtern hinzufügen, damit sie nicht eingegeben werden können, aber du musst das selbst tun.
Deshalb wäre es gut, wenn sie zur überwachten Liste hinzugefügt würden – auch wenn keine automatische Aktion auf den URLs ergriffen wird, könnten wir so sehen, welche Spam-Nachrichten gepostet werden. Denken Sie daran, dass Moderatoren die Prüfqueue nutzen können, aber (meines Wissens nach) keine überwachten Wörter hinzufügen können.
Ein paar kleine UX-Rückmeldungen: Es wäre toll, wenn die Überprüfungsliste meine Einstellungen speichern würde. Da wir mit einem Team von Moderatoren arbeiten, interessiere ich mich persönlich hauptsächlich für neue Flaggen und sortiere nach „Erstellungsdatum“, aber diese Einstellung bleibt nicht erhalten.
Das ist kein schlechter Vorschlag. Zum Glück gibt es derzeit einen Workaround: Die Suchfilter werden in der Abfragezeichenfolge (URL) gespeichert. Wenn Sie einen Filter als Lesezeichen speichern, können Sie jederzeit wieder darauf zugreifen.
