Pulsante "Sì" di moderazione dopo la sospensione di un utente

Buongiorno

Flag: l’utente richiede approvazione.

Dopo aver sospeso un utente a causa dello spam, al giorno d’oggi rimane un pulsante “sì”.

Questo cambiamento sembra essere avvenuto con GitHub - discourse/discourse at 5b61a1d4496d9ea51fcd6fd79f736dff530781ab · GitHub (o forse una versione precedente).

Note:

  1. Non sono un amministratore del sito.
  2. Spero che questi dettagli siano sufficienti.
5 Mi Piace

Grazie per la segnalazione, stiamo lavorando a una correzione che ripristinerà il contesto corretto

2 Mi Piace

Grazie per il lavoro svolto per risolvere questo problema @awesomerobot.

Il mio forum è stato aggiornato alla versione Discourse ed00bce10a9e2ad5f12f6ae6b3a229bb62cf2d2b, che include discourse/discourse#43495. Continuiamo comunque a vedere questi pulsanti inaspettati sugli elementi di revisione “Utente in attesa di approvazione”.

Forse la segnalazione non era chiara. Il problema non è che mancasse il contesto. Il problema è che abbiamo già risolto l’elemento di revisione sospendendo l’utente tramite l’interfaccia di revisione dei flag. Non c’è motivo che ci sia ancora questo pulsante “Sì” su un elemento di revisione già risolto. Crea solo confusione, facendo sembrare che sia necessaria un’azione aggiuntiva per completare la revisione, ma l’unica azione che offre è quella di approvare l’utente, il che non avrebbe senso dato che si tratta di spammer. Nessun altro tipo di elemento di revisione ha pulsanti dopo essere stato esaminato e questi pulsanti non erano presenti in precedenza sugli elementi di revisione “Utente in attesa di approvazione”.

Si tratta chiaramente di un bug, non di “UX”.

2 Mi Piace

Ah, ora capisco, grazie per il dettaglio aggiuntivo: la situazione richiedeva un po’ di chiarimenti… Avevo dato per scontato che si trattasse di qualcosa che avevamo trascurato in precedenza con le modifiche alla coda di revisione, ma in realtà è un effetto collaterale di un’altra modifica che non doveva avere impatto sulla coda di revisione.

Il problema originale era che, con must_approve_users attivo, gli utenti che avevano un elemento nella coda di revisione già gestito ma che non erano ancora stati approvati non potevano essere approvati dalla loro pagina di amministrazione, poiché l’approvazione funzionava solo sugli elementi in sospeso. La correzione ha consentito l’approvazione degli utenti anche in presenza di elementi della coda già gestiti. Questo ha risolto il problema nella pagina di amministrazione, ma ha anche fatto comparire il pulsante di approvazione sugli elementi già gestiti nella coda di revisione.

Quindi, anziché correggere il contesto, quel pulsante di approvazione non dovrebbe comparire, come hai detto. Sto preparando una correzione che lo nasconderà di nuovo nella coda di revisione:

1 Mi Piace

Segnalerò il post n. 6 come soluzione non appena incontrerò di nuovo la stessa bandiera.

Grazie per il lavoro svolto.

1 Mi Piace

OK, il problema sembra risolto.

Dov’è il pulsante per la soluzione su questo forum? Mi aspetterei che fosse nella riga di icone sotto il post.

1 Mi Piace

Il plugin “Risolto” non è abilitato in questa categoria. Puoi trovare il pulsante sotto i topic, ad esempio in #supporto.
A volte gli utenti contrassegnano i topic come risolti dopo che qualcuno ha condiviso una soluzione temporanea, che non è la soluzione definitiva. Pertanto, nei topic di questa categoria viene aggiunto il tag #risolto e il topic viene chiuso dalla persona che ha risolto il problema.

2 Mi Piace