The delete user action is found under different top level buttons depending on the type of flag. It would be nice if the Delete button always had a delete user sub action.
And btw, URLs are added to the screened list if you delete from a manually flagged review, just not from user posted too fast reviews.
I just had some odd things happen relating to flagging of a post in a personal message. Two people are in the message (myself and a new moderator I am in the process of onboarding). We were testing out flagging, and she flagged one of her own posts. Both of us received the notification that our message was flagged as spam and that we should edit and fix it, and neither of us could directly reverse the flagging action directly in the post. It also did not show up in the review queue.
While the post was hidden, I selected the post admin wrench but was unable to use it because it was somehow behind the post content. See screenshot.
Only when I edited the post did it get unhidden.
So… several issues:
I’ve been loving the improvements here - I’ve finally had a chance to collect my thoughts and accumulate a bit of feedback about this:
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).
