Sembra che mi sia sfuggito qualcosa in questo post: Let's talk Moderation - #2 by simon. Le sospensioni precedenti influenzano effettivamente le promozioni tl3. È strano come i requisiti elencati qui vengano calcolati due volte nel processo di promozione:
Prima nel job di promozione tl3, poi di nuovo dalla chiamata a review_tl2. Quel metodo ricalcola i requisiti tl3, questa volta tenendo conto dei conteggi di penalità per il silenzio e le sospensioni: discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub.
Questo è piuttosto significativo, poiché le sospensioni vengono spesso utilizzate come un modo per revocare temporaneamente l’accesso a un sito in un modo che non è inteso a penalizzare gli utenti, ad esempio, gli utenti vengono sospesi quando una membership a pagamento su un’applicazione esterna è scaduta.
Modifica: sembra che se un utente viene sospeso, quindi sospeso da un utente che non è l’utente di sistema, il conteggio delle penalità viene rimosso: discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub. Ciò significa che se un utente viene sospeso accidentalmente, quindi sospeso da un utente umano, non ci sarà alcun conteggio di penalità. Significa anche che per il caso in cui gli utenti vengono sospesi “per sempre” come mezzo per rimuovere l’accesso al sito quando una sottoscrizione esterna è scaduta, non ci sarà alcun conteggio di penalità quando vengono sospesi, purché la sospensione non venga eseguita dall’utente di sistema.
Questa logica ha senso, ma forse potrebbe essere resa esplicita da qualche parte. È abbastanza comune sospendere e sospendere nuovamente gli utenti tramite l’API. Non sapevo fino ad ora che fosse significativo se l’azione fosse eseguita dall’utente di sistema o meno.
La stessa logica viene utilizzata per i conteggi di penalità per il silenzio di un utente.