L’azione ‘Elimina utente’ si trova sotto pulsanti di primo livello diversi a seconda del tipo di segnalazione. Sarebbe utile se il pulsante Elimina avesse sempre una sottazione per eliminare l’utente.
A proposito, gli URL vengono aggiunti all’elenco monitorato se si elimina da una recensione segnalata manualmente, ma non da quelle pubblicate troppo velocemente dall’utente.
Ho appena verificato alcune stranezze relative alla segnalazione di un messaggio in una conversazione privata. Erano coinvolti due utenti (io e un nuovo moderatore che sto attualmente formando). Stavamo testando la funzione di segnalazione e lei ha segnalato uno dei suoi stessi messaggi. Entrambi abbiamo ricevuto la notifica in cui si affermava che il messaggio era stato segnalato come spam e che dovevamo modificarlo per correggerlo; inoltre, nessuno dei due è riuscito a annullare direttamente l’azione di segnalazione dal post. Inoltre, la segnalazione non è apparsa nella coda di revisione.
Mentre il post era nascosto, ho selezionato l’icona dell’attrezzo per la gestione del post, ma non sono riuscito a utilizzarla perché in qualche modo era sovrapposta al contenuto del post. Vedi screenshot.
Solo dopo aver modificato il post questo è stato reso di nuovo visibile.
Quindi… diversi problemi:
Ho apprezzato molto i miglioramenti qui: finalmente ho avuto l’opportunità di raccogliere i miei pensieri e formulare un po’ di feedback a riguardo:
Un’altra funzionalità che dovremmo aggiungere: fare in modo che gli elementi contrassegnati di nuovo non riappaiano nella coda di revisione a meno che il contenuto del post non sia stato modificato o alterato in qualche modo. Questo dovrebbe ignorare automaticamente i nuovi elementi contrassegnati e non dovrebbe essere possibile notificare o nascondere il post.
L’idea è che un moderatore abbia già visto il contrassegno e lo abbia gestito, e che qualsiasi nuovo elemento (dello stesso tipo) venga gestito allo stesso modo.
Una precisazione: dovremmo probabilmente ignorare i nuovi contrassegni invece di risolvere automaticamente l’elemento da revisionare nello stesso modo in cui è stato effettivamente gestito il contrassegno (ad esempio, concordato), poiché ciò potrebbe avere l’effetto collaterale indesiderato di permettere agli utenti che abusano dei contrassegni di aumentare il proprio punteggio contrassegnando elementi che i moderatori hanno già risolto con “concorda + mantieni”.
Ottimo punto. Per aggiungere qualcosa, apro regolarmente post che poi vengono segnalati come spam da Akismet. Anche questo probabilmente non dovrebbe accadere.
Già, i plugin dovrebbero probabilmente avere ancora la possibilità di sovrascrivere il suggerimento sopra, se necessario, ma sono d’accordo che Akismet non dovrebbe farlo in questo caso. Potrebbe essere più un problema del plugin Akismet, ma è un punto eccellente.
Questo è un problema del plugin, spingerò una correzione.
Ho già iniziato a esaminare la questione. Concordo sul fatto che dobbiamo ignorare le nuove segnalazioni invece di risolverle automaticamente. Stavo pensando di mostrare un messaggio di errore quando qualcuno tenta di segnalare nuovamente un post già revisionato.
Stavo anche pensando che gli utenti dovrebbero attendere circa 24 ore prima di poter segnalare nuovamente un post per lo stesso motivo.
Poiché tutti gli elementi in sospeso più recenti si trovano nel menu Visualizza tutto, la scheda Revisione dovrebbe reindirizzarci a quel menu invece che al menu Raggruppati per argomento.
Hai impostato argomenti predefiniti revisionabili? Questo fa sì che si passi agli argomenti invece che a tutti gli elementi, che dovrebbe essere l’impostazione predefinita.
Abbiamo appena unito questa funzionalità:
Secondo le note di rilascio di Discourse 2.4.0 beta11 disponibili su https://meta.discourse.org/t/discourse-2-4-0-beta11-release-notes/141548:
Utenti sospetti inviati alla coda di revisione
Gli utenti sospetti, ovvero quelli che hanno visualizzato meno di un post e un argomento ma hanno personalizzato la loro biografia, vengono ora inviati alla coda di revisione. Tali utenti hanno un’alta probabilità di essere spammer, poiché la maggior parte degli utenti naviga sul sito prima di dedicare tempo a compilare la propria biografia.
Questo non accade nel nostro caso: i nuovi utenti sospetti appaiono regolarmente in /admin/users/list/suspect, ma non nella coda di revisione. Dipende da qualche impostazione?
Sì, la funzionalità dipende dall’impostazione “approva utenti sospetti” (disabilitata per impostazione predefinita).
Ottimo, ora funziona (forse questo tipo di informazione dovrebbe essere aggiunta alle note di rilascio).
Ho però una piccola richiesta che ci aiuterebbe a rendere il processo di revisione più veloce: potresti collegare il campo del sito web? Al momento dobbiamo copiarlo e incollarlo, il che ci rallenta molto.
Sembra che tu abbia aggiunto un campo utente. Purtroppo non abbiamo modo di sapere se si tratta di URL o meno.
Il campo ‘Sito web’? Non è un campo personalizzato (come qui su Meta). Gli altri due lo sono, ma non ho bisogno che siano collegati direttamente.
Ha senso che il campo standard del sito web sia attivo. Sarebbe fantastico se avesse il tracciamento del numero di clic.
Penso che dovresti poter rendere i tuoi campi personalizzati cliccabili con un componente del tema.
Doppio clic, Control+C, Control+T, Control+V, Invio
Scusa! Ho controllato qui su Meta e l’utente che ho esaminato non aveva un sito web. Inoltre, mi sono confuso a causa degli altri campi utente situati subito sotto. Questo collegamento porterà al sito web per facilitare la revisione:
Dopo averci riflettuto ulteriormente, una finestra di riflessione di 24 ore sembra adatta per i siti più piccoli, ma sono preoccupato che gli utenti possano comunque sovraccaricare i moderatori su un sito di grandi dimensioni.
Cosa ne pensi di rendere la finestra di non segnalabilità una variabile (o almeno configurabile tramite un plugin)? Qualsiasi cosa possa ridurre il potenziale carico di lavoro per i moderatori la considererei un successo.
Un altro problema non correlato: gli utenti altamente fidati potrebbero essere percepiti come aventi poteri da “mod” con la capacità di nascondere un post con una singola segnalazione. Il vecchio numero minimo di segnalazioni per nascondere un post potrebbe essere ancora desiderabile come opzione, in modo che nessun singolo membro della comunità possa agire come censore.
Sì, dopo un lungo confronto, non sono realmente contrario a reinserire il numero minimo. Vorrei solo essere certo che il cliente di @featheredtoast abbia provato prima le altre modifiche e sia sicuro che questo sarebbe utile.
@Roman, potremmo rendere configurabile quella finestra di 24 ore?
Fatto qui:
Può essere abilitato o disabilitato con l’impostazione high_trust_flaggers_auto_hide_posts.
Può essere configurato utilizzando l’impostazione cooldown_hours_until_reflag (predefinito a 24 ore).
