Me gustaría usar un webhook para eliminar a los spammers de nuestra base de datos central cuando los elimino en la cola de revisión, pero no se dispara ningún evento cuando configuro mi webhook de esta manera. ¿Se supone que debería hacerlo, o malinterpreto la parte de ‘… y cuando se actualiza su estado’?
1 me gusta
¿Se activa un webhook de “eliminación de usuario”?
3 Me gusta
Sí. Desafortunadamente, no está pasando una eliminación y me gustaría actuar específicamente solo cuando un usuario haya sido eliminado y bloqueado por IP.
1 me gusta
Me gustaría solicitar la capacidad de ocultar automáticamente las imágenes de forma predeterminada, específicamente para publicaciones marcadas por usuarios de nivel TL0. Aunque es necesario poder ver imágenes inapropiadas y actuar en consecuencia según los estándares de cada comunidad, sería muy útil ocultarlas para quienes trabajan en oficinas o desde casa con niños alrededor (como a menudo es mi caso).
6 Me gusta
La API para “saltar” la necesidad de puntuación en la cola de revisión sigue siendo insuficiente con el paso del tiempo, ya que la puntuación se recalcula periódicamente. Si la cola no se gestiona en el momento en que se crea el elemento revisable, el elemento “forzado” puede desaparecer de las listas filtradas por alto antes de que los moderadores puedan revisar esos elementos.
Quizás deberíamos añadir un campo booleano force_review al modelo reviewable que se una a la consulta de puntuación aquí.
5 Me gusta
Las imágenes de los usuarios TL0 están difuminadas de forma predeterminada. Esto se puede desactivar mediante la configuración blur_tl0_flagged_posts_media.
Esto también se ha implementado. Cuando el indicador force_review se establece en true, los elementos pendientes de revisión aparecerán en la cola incluso si no cumplen con la puntuación mínima del umbral de visibilidad.
8 Me gusta
@Roman - Lo siento, aún no he podido responderte sobre esto. Si todavía puede ser útil, tengo los registros y he extraído algunos (con la información de identificación eliminada). Actualmente estamos ejecutando la versión 2.6.0beta3. Todos los errores de “integer out of range” parecen estar relacionados con el mismo tipo de registros.
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"
1 me gusta
También sería útil tener una forma de ver una lista de elementos revisables que ya han sido revisados, filtrados por el moderador que gestionó las banderas. El filtro “asignado a” al consultar las banderas gestionadas en el pasado parece semánticamente muy similar a buscar un filtro “gestionadas por”, pero no es lo mismo.
¿Debería el filtro “asignado a” en banderas/elementos revisables resueltos consultar quién gestionó las banderas, o puede ser un filtro separado?
4 Me gusta
Creo que es una gran sugerencia, @Roman. ¿Podrías añadirla a tu lista?
5 Me gusta
Estoy utilizando un webhook y la API para agregar nuevos temas a la Cola de Revisión, para que los moderadores puedan verificar el cumplimiento de los nuevos temas. Actualmente, señalo la primera publicación del nuevo tema mediante la API. Esto funciona, pero al ver el historial administrativo del usuario parece algo negativo. ¿Existe otra forma que no haga que el usuario parezca mal?
1 me gusta
¿Hay alguna razón por la que no puedas usar aprobar nuevos temas excepto por nivel de confianza? Esto ya está integrado en Discourse.
2 Me gusta
Estoy de acuerdo en que eso funcionaría para muchos casos de uso. Necesitamos etiquetas de varios grupos de etiquetas, algo que Discourse no admite. Queremos permitir la creación del nuevo tema sin necesidad de aprobación, pero asegurarnos de que las etiquetas sean correctas según lo permita el tiempo.
Lo que sugiero es una forma de agregar elementos arbitrarios a la cola de revisión. Actualmente hay tres tipos soportados: publicación señalada, publicación en cola y usuario. Estamos aprovechando la publicación señalada porque es lo más cercano a lo que necesitamos, pero sería ideal poder colocar un elemento de “revisar etiquetas” en la cola de revisión, incluso si solo podemos hacerlo mediante la API.
1 me gusta
No hay una forma fácil de hacer lo que deseas.
La mejor manera de hacerlo sería crear un complemento que agregue un nuevo tipo de revisión y, luego, algún tipo de punto final para crearlos.
1 me gusta
¿Hay alguna manera de desactivar este cuadro de diálogo? Casi siempre rechazamos a los spammers, y esto solo añade un clic a nuestro flujo de trabajo:
3 Me gusta
He publicado sobre el mismo problema aquí: Account rejection email - #11 by simon.
3 Me gusta
2 Me gusta
¿Existe alguna forma de agregar un elemento revisable de tipo “User” a la cola de revisiones mediante la API? ¿O eso solo es accesible para el código que crea un nuevo usuario?
Mi caso de uso es que quiero que los moderadores revisen cualquier actualización de usuario para asegurarse de que cumpla con la política. Por lo tanto, tengo un webhook de user_updated y deseo colocar al usuario actualizado en la cola de revisiones.
He logrado hacer ingeniería inversa para saber cómo marcar una publicación (/post_actions…) porque puedo marcar una publicación manualmente y observar el tráfico de red, pero no sé cómo hacer lo mismo para un User. Imagino que sea algo como /user_actions…
1 me gusta
Actualmente no hay forma de hacer esto mediante la API. Creo que tendrías que agregar un plugin que intercepte una actualización de un usuario y cree una revisión.
2 Me gusta
2 publicaciones se dividieron en un nuevo tema: Responder a las aprobaciones de publicaciones
Hola, esta es una crítica constructiva de la cola de revisión.
Sé que se han realizado algunas mejoras en los botones “Rechazar / Aprobar” para hacerlos menos ambiguos (“¿Estoy aprobando la publicación o estoy aprobando la marca?”). Pero todavía hay un doble significado para esos estados, lo que hace que revisar la lista de elementos ya manejados sea bastante confuso para mí porque el filtro de Estado y el Estado en la parte superior derecha realmente no significan nada. Aquí hay algunos ejemplos:
Publicación aprobada marcada por escribir demasiado rápido –\u003e Publicación aprobada –\u003e Estado: Aprobado
Marca aprobada en publicación inapropiada –\u003e Publicación rechazada –\u003e Estado: Aprobado
Usuario rechazado por spam en el perfil –\u003e Usuario suspendido –\u003e Estado: Rechazado
Marca rechazada en una publicación –\u003e La publicación permanece –\u003e Estado: Rechazado
Por lo tanto, parece que necesita diferenciar entre los siguientes estados, y algunos elementos podrían tener ambos:
- Usuario/publicación aprobado
- Usuario/publicación rechazado
--- - Moderación aprobada
- Moderación rechazada
Otra sugerencia de mejora en el caso de los spammers de perfiles de usuario, agradecería una opción para eliminar la cuenta y bloquear el correo electrónico pero no la dirección IP, ya que a menudo utilizan rangos de IP compartidos que los usuarios legítimos también podrían estar utilizando.
1 me gusta