Vorrei utilizzare un webhook per rimuovere gli spammer dal nostro database centrale quando li elimino dalla coda di revisione, ma non viene attivato alcun evento quando configuro il webhook in questo modo. Dovrebbe esserlo, o ho frainteso la parte relativa a ‘… e quando il suo stato viene aggiornato’?
Viene attivato un webhook “user delete”?
Lo fa. Purtroppo non sta passando una cancellazione e vorrei agire specificamente solo quando un utente è stato cancellato e bloccato per IP.
Vorrei richiedere la possibilità di nascondere automaticamente le immagini per impostazione predefinita, in particolare per i post segnalati da utenti TL0. Sebbene sia necessario vedere immagini inappropriate e agire in base agli standard di ciascuna community, sarebbe utile nascondere le immagini per chi si trova in ambienti d’ufficio o lavora da casa con bambini intorno (come spesso capita a me).
L’API per “bypassare” la necessità di una valutazione nella coda di revisione non è ancora sufficiente nel tempo, poiché il punteggio viene ricalcolato periodicamente. Se la coda non viene gestita al momento della creazione dell’elemento revisionabile, l’elemento “forzato” può scomparire dalle liste filtrate ad alto livello prima che i moderatori possano esaminarlo.
Forse dovremmo aggiungere un campo booleano force-review all’oggetto revisionabile, che venga unito alla query del punteggio qui.
Le immagini degli utenti TL0 sono sfocate per impostazione predefinita. Questa opzione può essere disabilitata tramite l’impostazione blur_tl0_flagged_posts_media.
Anche questo è stato implementato. Quando il flag force_review è impostato su true, gli elementi in attesa di revisione appariranno nella coda anche se non soddisfano il punteggio minimo di visibilità.
@Roman - Scusa, non sono ancora riuscito a risponderti riguardo a questo. Se può ancora essere utile, ho recuperato i log ed estratto alcuni record (dopo aver rimosso le informazioni identificative). Attualmente sto eseguendo la versione 2.6.0beta3. Tutti gli errori di “integer out of range” sembrano riguardare lo stesso tipo di record.
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
Potrebbe essere utile avere un modo per visualizzare un elenco di elementi da revisione già esaminati, filtrati per il moderatore che ha gestito i segnalazioni: ‘assegnato a’ come filtro quando si consultano i segnalazioni gestiti in passato sembra semanticamente molto simile alla ricerca di un filtro ‘gestito da’, ma è diverso.
'Do ‘assegnato a’ con segnalazioni/elementi da revisione risolti interrogare chi ha gestito i segnalazioni, oppure può trattarsi di un filtro separato?
Penso che sia un’ottima idea @Roman - puoi aggiungerla alla tua lista?
Sto utilizzando un webhook e l’API per inserire nuovi argomenti nella coda di revisione, in modo che i moderatori possano verificare la conformità del nuovo argomento. Attualmente segnalo il primo post del nuovo argomento tramite l’API. Questo funziona, ma appare come un’azione negativa quando si visualizza la cronologia amministrativa dell’utente. Esiste un altro metodo che non faccia sembrare l’utente in una luce negativa?
C’è un motivo per cui non puoi usare approva nuovi argomenti a meno che il livello di fiducia? Questa funzione è integrata in Discourse.
Concordo che funzionerebbe per molti casi d’uso. Abbiamo bisogno di tag provenienti da più gruppi di tag, cosa che non è supportata da Discourse. Vogliamo permettere la creazione di nuovi argomenti senza approvazione, ma garantire che i tag siano corretti quando il tempo lo consente.
Credo che il mio suggerimento sia trovare un modo per inserire elementi arbitrari nella coda di revisione. Attualmente sono supportati tre tipi: post segnalato, post in coda e utente. Stiamo sfruttando il post segnalato perché è quello più vicino a ciò che vogliamo, ma sarebbe utile poter inserire un elemento “revisiona tag” nella coda di revisione, anche se potessimo farlo solo tramite API.
Non esiste un modo semplice per fare ciò che desideri.
Il modo migliore per farlo sarebbe creare un plugin che aggiunga un nuovo tipo di recensione e, successivamente, un qualche tipo di endpoint per crearli.
C’è un modo per disabilitare questa finestra di dialogo? Rifiutiamo quasi esclusivamente gli spammer e questo aggiunge solo un clic al nostro flusso di lavoro:
Ho pubblicato sullo stesso problema qui: Account rejection email - #11 by simon.
Quando il motivo del rifiuto è legato allo spam, sicuramente non abbiamo bisogno di questa finestra di dialogo @sam @Roman..
C’è un modo per aggiungere un elemento da revisionare di tipo “Utente” alla coda di revisione tramite l’API? Oppure è accessibile solo al codice che crea un nuovo utente?
Il mio caso d’uso è quello di voler far sì che i moderatori revisionino tutti gli aggiornamenti degli utenti per assicurarsi che siano conformi alle policy. Quindi ho un webhook user_updated e vorrei inserire l’utente aggiornato nella coda di revisione.
Sono riuscito a capire come segnalare un post (/post_actions…) perché posso segnalarlo manualmente e osservare il traffico di rete, ma non so come fare lo stesso per un Utente. Immagino che sia qualcosa come /user_actions…
Al momento non è possibile farlo tramite API. Penso che tu debba aggiungere un plugin che intercetti un aggiornamento di un utente e ne crei uno revisionabile.
2 post sono stati divisi in un nuovo argomento: Rispondere alle approvazioni dei post
Ciao, queste sono critiche costruttive sulla coda di revisione.
So che sono stati apportati alcuni miglioramenti ai pulsanti “Rifiuta / Approva” per renderli meno ambigui (“Sto approvando il post o sto approvando la segnalazione?”). Ma c’è ancora un doppio significato per questi stati, che rende la revisione dell’elenco degli elementi già gestiti piuttosto confusa per me perché il filtro Stato e lo Stato in alto a destra non hanno davvero alcun significato. Ecco alcuni esempi:
Post approvato contrassegnato per aver digitato troppo velocemente –\u003e Post approvato –\u003e Stato: Approvato
Segnalazione approvata su post inappropriato –\u003e Post rifiutato –\u003e Stato: Approvato
Utente rifiutato per spam nel profilo –\u003e Utente sospeso –\u003e Stato: Rifiutato
Segnalazione rifiutata su un post –\u003e Post rimane –\u003e Stato: Rifiutato
Quindi sembra che sia necessario differenziare tra i seguenti stati, e alcuni elementi potrebbero averli entrambi:
- Utente/post approvato
- Utente/post rifiutato
--- - Moderazione approvata
- Moderazione rifiutata
Un altro suggerimento per migliorare nel caso di spammer nei profili utente, apprezzerei un’opzione per eliminare l’account e bloccare l’email ma non l’indirizzo IP, poiché spesso utilizzano intervalli di IP condivisi che anche gli utenti legittimi potrebbero utilizzare.





