Nur eine kleine Unannehmlichkeit, wenn ein Benutzer wegen Spamming gemeldet wird. Wenn man der Markierung zustimmt und den Benutzer sperrt, sollte eine Option „Spammer“ in der Liste der Gründe vorausgewählt sein, damit wir sie nicht jedes Mal eingeben müssen.
Wenn man einen Benutzer als Spammer markiert, kann ich mir auch keinen Grund vorstellen, das Konto wiederherzustellen. Daher sollte die Sperrdauer standardmäßig bis „für immer“ vorausgewählt sein.
Hallo @HAWK , das ist, wenn Benutzer einen Beitrag als Spam markieren und ich ihn in der Überprüfungsoberfläche bearbeite. Es fragt mich etwas wie „Ist dieser Beitrag Spam?“ und ich antworte mit der Option Ja > Beitrag löschen und Benutzer sperren (die Zeichenfolgen sind ungefähr aus meiner Erinnerung), was dann das Popup aus meinem Screenshot aufruft.
Aber selbst wenn ich einen Spam-Beitrag selbst als Moderator/Administrator bemerke, würde ich nicht einfach den Beitrag löschen, sondern auch das Konto sperren, damit sie nicht weiter spammen. Dazu würde ich die Kontoeinstellungen des Benutzers unter /admin/users/.../... öffnen und dort auf die Schaltfläche Sperren klicken, was dasselbe Popup aufruft, das die Eingabe eines Grundes und einer Dauer erfordert.
Eine weitere Option wäre, das Spammer-Konto einfach zu löschen, was auch die Möglichkeit bietet, deren E-Mail-/IP-Adresse von der Anmeldung für ein neues Konto zu sperren. Dies scheint eine bessere Option zu sein als eine dauerhafte Sperrung.
Eine Sperrung ist traditionell etwas Vorübergehendes, wie zum Beispiel, wenn ein Schüler einer Schule viele Probleme bereitet, kann er für eine Woche oder einen Monat gesperrt werden, aber das ist etwas völlig anderes, als vom Schulbesuch ausgeschlossen zu werden und keine zweite Chance zu bekommen, um zu versuchen, es besser zu machen und den Abschluss zu schaffen.
Falls Sie es nicht wissen: Die Option zum Löschen eines Benutzers befindet sich am Ende der Benutzerverwaltungsseite, direkt neben der Option zum Anonymisieren. Die Option zum Anonymisieren würde bedeuten, die Beiträge eines Benutzers beizubehalten, aber dessen Konto dennoch zu beenden.
Hallo @anon65426961 , das ist eine Option, aber sie ist nicht in den Workflow der Berichtsüberprüfung integriert. Außerdem ziehe ich es persönlich vor, die gesperrten Konten in der Datenbank zu belassen und ihre IP-Adresse nicht zu blockieren, 1) um möglicherweise die Hürde für Spammer zu erhöhen, die Registrierungs-E-Mails wie Gmail verwenden, deren Anmeldung einiges an Arbeit erfordert, und damit sie nicht einfach dieselbe E-Mail wiederverwenden, um sich nach der Löschung ihres Kontos erneut anzumelden, und 2) da die IP-Adressen oft in großen, gemeinsam genutzten IP-Blöcken liegen, die später einem legitimen Benutzer zugewiesen werden können, und ich diese lieber nicht blockieren möchte.
Interessant, ich weiß nichts über den Workflow zur Überprüfung von Berichten.
Das scheint eine bessere Idee zu sein, Konten in der Datenbank als gesperrt zu belassen, anstatt sie zu löschen. Es gibt die Option, nur das Konto zu löschen und nicht E-Mail/IP zu blockieren, aber keine Option, nur E-Mail zu blockieren, da es sowohl IP als auch E-Mail blockiert (wie Sie bereits wissen und eine Funktion zum Blockieren nur von E-Mail in diesem anderen Thread angefordert haben), vielleicht ist das eine Option, die sie später hinzufügen können.
Es gibt hier einen weiteren Thread mit einigen Diskussionen darüber:
Ich stimme dem sehr zu. In einigen Fällen scheint jeder in einem großen Gebiet dieselbe IP zu haben. Und wenn Sie nicht für die professionelle Version bezahlen, wird der Dienst unter dem Schutz von Cloudflare nicht die echte IP preisgeben. Daher wage ich es nicht, die Funktion des IP-Bans zu nutzen, da dies unsere ausgezeichneten Benutzer versehentlich ernsthaft verletzen würde.
Ja? Ich bin darin nicht sehr gut. Das hat mir die Serverbetreuerin, mit der ich zusammenarbeite, gesagt. Ich erinnere mich, dass sie mir gesagt hat, dass die Weitergabe der echten IP-Adresse eine zusätzliche Gebühr kostet.
Alle Cloudflare-Konten können die verbindende IP-Adresse sehen, vorausgesetzt, die Discourse-Instanz ist korrekt konfiguriert, um die bereitgestellte Vorlage zu verwenden.
Wir haben es Moderatoren kürzlich erleichtert, mit Akismet markierte Beiträge richtig zu behandeln.
Kopieren und Einfügen dessen, was auf GitHub getan wurde, zur besseren Übersicht:
Was ist diese Änderung?
Mehrere Rückmeldungen deuten darauf hin, dass die Überprüfungsaktionen für von Akismet markierte Beiträge verwirrend sind. Da es konzeptionell wenig Unterschied zwischen einem Beitrag gibt, der von einem Menschen und einem Computer als Spam markiert wurde, bringt dieser PR die Optionen stärker in Einklang mit dem, was wir für als Spam markierte Beiträge im Kern haben.
Ich weiß, dass das alt ist, aber ich bin mir nicht sicher, ob jemand sonst diesen Kontext geliefert hat…
Ich halte sie (dauerhaft) suspendiert, um alle Aufzeichnungen ihrer Aktionen leicht verfügbar zu halten, um Sockpuppen-Spammer zu identifizieren. Ich habe fast 10 Konten als eindeutig vom selben Akteur stammend identifiziert und dies genutzt, um neue Spam-Einträge zu blockieren, sobald sie eintrafen. Wenn ich (sagen wir) nur die IP blockieren würde, würden sie die IP wechseln und ich hätte dies nicht als eines der vielen Signale, die ich zur Identifizierung von Spammern verwende. Dies war ein enorm nützliches Werkzeug, um meine Website in der Praxis frei von neuem Spam zu halten.
Guter Punkt! Das ist kein einfaches Problem, das man angehen kann.
Persönlich würde ich sehr gerne organisierten Drive-by-Spam von anderen Arten individuellen Fehlverhaltens unterscheiden. Ich wäre auch sehr vorsichtig bezüglich der Möglichkeit kompromittierter Konten: Ich habe erlebt, dass ein Konto nach mehreren Spam-Posts gelöscht wurde, wobei sehr viele frühere inhaltliche Posts verloren gingen. Es war dasselbe Konto, aber offensichtlich (für mich) nicht dieselbe Person. Eine Sperrung oder Anonymisierung wäre weitaus besser gewesen.
In einem benachbarten Thread gibt es den Hinweis, dass es nicht ratsam ist, Konten mit TL2 oder höher ohne Nachdenken zu löschen. Natürlich sollten TL0-Konten, die Spam posten, eine viel niedrigere Schwelle haben.
Es wäre gut, wenn die Anleitung und die Benutzeroberfläche die Möglichkeiten widerspiegeln würden: Was könnte passieren und was könnte eine gute Reaktion sein?
Ich habe Leute (vielleicht traumatisierte Menschen) gesehen, die sagen, dass sie Spammer hassen und mit extremer Voreingenommenheit handeln wollen. Was sie übersehen, ist, dass sie von Menschen sprechen, während sie auf Konten handeln, und Konten haben eine Historie.
Vielen Dank für den Hinweis. Wurden diese Funktionen für die reguläre Bearbeitung von „Spam“-Meldungen in Betracht gezogen?
[quote=„rahim123, post:1, topic:271804″]
Wenn man der Markierung zustimmt und den Benutzer sperrt, sollte eine Option „Spammer“ in der Liste der Gründe vorausgewählt sein, damit wir sie nicht jedes Mal eingeben müssen.
[/quote]
[quote=„rahim123, post:1, topic:271804″]
Auch wenn ich einen Benutzer als Spammer markiere, kann ich mir keinen Grund vorstellen, das Konto jemals wiederherstellen zu wollen. Daher sollte die Sperrdauer standardmäßig bis „für immer“ vorausgewählt sein.
[/quote]