Es scheint, dass ich in diesem Beitrag etwas übersehen habe: Let's talk Moderation - #2 by simon. Frühere Sperrungen wirken sich tatsächlich auf TL3-Beförderungen aus. Es ist seltsam, wie die hier aufgeführten Anforderungen im Beförderungsprozess zweimal berechnet werden:
Zuerst im TL3-Beförderungsjob, dann erneut durch den Aufruf von review_tl2. Diese Methode berechnet die TL3-Anforderungen erneut und berücksichtigt dabei Strafzählungen für Stummschaltungen und Sperrungen: discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub.
Dies ist ziemlich bedeutsam, da Sperrungen oft dazu verwendet werden, den Zugriff auf eine Website vorübergehend zu entziehen, ohne die Benutzer zu bestrafen. Zum Beispiel werden Benutzer gesperrt, wenn eine kostenpflichtige Mitgliedschaft in einer externen Anwendung abgelaufen ist.
Bearbeiten: Es scheint, dass, wenn ein Benutzer gesperrt und dann von einem Benutzer, der nicht der Systembenutzer ist, entsperrt wird, die Strafzählung entfernt wird: discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub. Das bedeutet, dass, wenn ein Benutzer versehentlich gesperrt und dann von einem menschlichen Benutzer entsperrt wird, keine Strafzählung erfolgt. Es bedeutet auch, dass für den Fall, dass Benutzer “für immer” gesperrt werden, um den Zugriff auf die Website zu entziehen, wenn ein externes Abonnement abgelaufen ist, keine Strafzählung erfolgt, wenn sie entsperrt werden, solange die Entsperrung nicht vom Systembenutzer durchgeführt wird.
Diese Logik ist sinnvoll, aber vielleicht könnte sie irgendwo explizit gemacht werden. Es ist ziemlich üblich, Benutzer über die API zu sperren und zu entsperren. Ich wusste bis jetzt nicht, dass es einen Unterschied macht, ob die Aktion vom Systembenutzer oder von einem anderen Benutzer durchgeführt wird.
Die gleiche Logik wird für Strafzählungen bei der Stummschaltung eines Benutzers verwendet.