Il semble que j’aie manqué quelque chose dans ce post : Let's talk Moderation - #2 by simon. Les suspensions précédentes affectent réellement les promotions tl3. Il est étrange que les exigences listées ici soient calculées deux fois dans le processus de promotion :
D’abord dans le job de promotion tl3, puis à nouveau à partir de l’appel à review_tl2. Cette méthode recalcule les exigences tl3, en tenant compte cette fois des comptes de pénalité pour le silence et les suspensions : discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub.
C’est assez significatif, car les suspensions sont souvent utilisées comme un moyen de révoquer temporairement l’accès à un site d’une manière qui n’est pas destinée à pénaliser les utilisateurs, par exemple, les utilisateurs sont suspendus lorsqu’un abonnement payant sur une application externe a expiré.
Edit : il semble que si un utilisateur est suspendu, puis désouspendu par un utilisateur qui n’est pas l’utilisateur système, le compte de pénalité est supprimé : discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub. Cela signifie que si un utilisateur est accidentellement suspendu, puis désouspendu par un utilisateur humain, il n’y aura pas de compte de pénalité. Cela signifie également que dans le cas où les utilisateurs sont suspendus « à jamais » comme moyen de supprimer l’accès au site lorsqu’un abonnement externe a expiré, il n’y aura pas de compte de pénalité lorsqu’ils seront désouspendus, tant que la désouspension n’est pas effectuée par l’utilisateur système.
Cette logique a du sens, mais elle pourrait peut-être être explicitée quelque part. Il est assez courant de suspendre et désouspendre des utilisateurs via l’API. Je ne savais pas jusqu’à présent que l’action était effectuée par l’utilisateur système était significative.
La même logique est utilisée pour les comptes de pénalité pour le silence d’un utilisateur.