La acción de eliminar usuario se encuentra bajo diferentes botones de nivel superior, dependiendo del tipo de señal. Sería ideal que el botón Eliminar siempre tuviera una subacción de eliminar usuario.
Por cierto, las URLs se agregan a la lista de filtradas si se eliminan desde una revisión marcada manualmente, pero no desde las revisiones de “publicado demasiado rápido” por el usuario.
Acabo de experimentar algunas situaciones extrañas relacionadas con la señalización de una publicación en un mensaje privado. Había dos personas en el mensaje (yo mismo y un nuevo moderador que estoy en proceso de incorporar). Estábamos probando la funcionalidad de señalización, y ella marcó una de sus propias publicaciones. Ambos recibimos la notificación de que nuestro mensaje había sido marcado como spam y que debíamos editarlo y corregirlo, y ninguno de los dos pudo revertir directamente la acción de señalización en la publicación. Además, no apareció en la cola de revisión.
Mientras la publicación estaba oculta, seleccioné la llave inglesa de administración de la publicación, pero no pude usarla porque de alguna manera estaba detrás del contenido de la publicación. Ver captura de pantalla.
Solo cuando edité la publicación se desocultó.
Así que… varios problemas:
Me han encantado las mejoras aquí; finalmente he tenido la oportunidad de reflexionar y recopilar algo de retroalimentación al respecto:
Otra función que deberíamos añadir: hacer que los elementos re-señalados no vuelvan a aparecer en la cola de revisión a menos que el contenido de la publicación se haya editado o modificado de alguna manera. Esto debería ignorar automáticamente los nuevos elementos de señalización y no permitir notificar ni ocultar la publicación. La idea es que algún moderador ya vio la señalización y la gestionó; por lo tanto, cualquier nuevo elemento (del mismo tipo) se gestionaría de la misma manera. Una salvedad: probablemente deberíamos ignorar cualquier nueva señalización en lugar de resolver automáticamente el elemento revisable de la misma forma en que se gestionó la señalización (por ejemplo, «de acuerdo»), ya que esto podría tener el efecto no deseado de permitir que los «griefers» de señalización aumenten sus puntuaciones de señalización al señalar cosas que los moderadores ya resolvieron con «de acuerdo» + «mantener».
Excelente punto. Para añadir a esto, apruebo regularmente publicaciones que luego son marcadas como spam por Akismet. Eso tampoco debería ocurrir.
Sí, los plugins probablemente deberían seguir teniendo la capacidad de anular la sugerencia anterior si es necesario, pero coincido en que Akismet no debería hacerlo en este caso. Esto podría ser más un problema del plugin de Akismet, pero es un excelente punto.
Este es un problema del plugin, voy a implementar una solución.
Ya comencé a investigar esto. Estoy de acuerdo en que debemos ignorar las nuevas marcas en lugar de resolverlas automáticamente. Estaba pensando en mostrar un mensaje de error cuando alguien intenta volver a marcar una publicación ya revisada.
También pensé que los usuarios deberían esperar unas 24 horas antes de poder volver a marcar una publicación por la misma razón.
Dado que todos los elementos pendientes más recientes están en el menú Ver todo, la pestaña Revisar debería redirigirnos a ese menú en lugar del menú Agrupado por tema.
¿Tienes configurado temas predeterminados revisables? Eso hace que predeterminen en temas en lugar de en todos los elementos, lo cual debería ser el predeterminado.
Acabamos de integrar esta característica:
Según https://meta.discourse.org/t/discourse-2-4-0-beta11-release-notes/141548:
Usuarios sospechosos enviados a la cola de revisión
Los usuarios sospechosos, es decir, aquellos que han visto menos de una publicación y un tema pero han personalizado su biografía, ahora se envían a la cola de revisión. Este tipo de usuarios tienen una alta probabilidad de ser spammers, ya que la mayoría de los usuarios navegan por el sitio antes de tomarse el tiempo para completar su biografía.
Esto no nos ocurre a nosotros; los nuevos usuarios sospechosos aparecen en /admin/users/list/suspect como de costumbre, pero no en la cola de revisión. ¿Depende esto de alguna configuración?
Sí, la función depende de la configuración «aprobar usuarios sospechosos» (desactivada de forma predeterminada).
Genial, ahora está funcionando (quizás este tipo de información debería añadirse a las notas de la versión).
Sin embargo, tengo una pequeña solicitud que nos ayudaría a agilizar el proceso de revisión: ¿podrías enlazar el campo del sitio web? Ahora mismo tenemos que copiarlo y pegarlo, lo que nos ralentiza mucho.
Parece que has añadido un campo de usuario. Por desgracia, no tenemos forma de saber si son URLs o no.
¿El campo ‘Sitio web’? Ese no es un campo personalizado (igual que aquí en Meta). Los otros dos sí lo son, pero no necesito que estén enlazados directamente.
Tiene sentido que el campo estándar del sitio web sea activo. Sería genial si incluyera seguimiento de clics.
Creo que deberías poder hacer que tus campos personalizados sean clicable mediante un componente de tema.
Doble clic, Control + C, Control + T, Control + V, Intro
¡Mi culpa! Revisé aquí en Meta y el usuario que vi no tenía un sitio web. Además, me confundí con los otros campos de usuario justo debajo. Esto vinculará el sitio web para facilitar la revisión:
Después de pensarlo un poco más, una ventana de reflexión de 24 horas parece adecuada para sitios más pequeños, pero me preocupa que los usuarios aún puedan abrumar a los moderadores en un sitio grande.
¿Qué opinas de tener una variable para la ventana de no señalable (o al menos que sea configurable en un plugin)? Cualquier cosa que podamos hacer para reducir la posible carga sobre los moderadores la considero un éxito.
Otro tema no relacionado: los usuarios altamente confiables pueden ser vistos como si tuvieran poderes de “moderador” con la capacidad de ocultar una publicación con una sola señalización. El antiguo número mínimo requerido para ocultar una publicación podría seguir siendo deseable como opción, para que ningún miembro de la comunidad pueda actuar como censor.
Sí, tras mucho ir y venir, en realidad no me opongo a volver a incluir el número mínimo. Me gustaría asegurarme de que el cliente de @featheredtoast haya probado primero los otros ajustes y esté seguro de que esto sería útil.
@Roman, ¿podríamos hacer que esa ventana de 24 horas sea configurable?
Hecho aquí:
Se puede habilitar o deshabilitar con la configuración high_trust_flaggers_auto_hide_posts.
Se puede configurar usando la configuración cooldown_hours_until_reflag (por defecto 24 horas).
