Una sugerencia para el sistema de revisiones: al aprobar una publicación que desactiva el silencio de un usuario, ¿podrían agregar una Nota de Usuario para el evento? Algo como '@nombre_de_usuario ha desactivado el silencio de esta cuenta' sería muy útil. Por ahora, solo vemos la mitad de la historia en las notas.
3 Me gusta
Mejor borrarlos por completo, eso es lo que yo hago. Por lo general, están equivocados de todos modos y no me gustan las notas ruidosas que no aportan información útil.
2 Me gusta
Desde la cola de revisión, para el tipo ‘Publicación en cola’, si intento eliminar a un usuario que tiene bastantes publicaciones, obtengo un error de tiempo de espera 502.
No estoy seguro de cuál es el límite superior, pero según las pruebas de hoy, la cuenta más pequeña que probé y que no funcionó tenía 288 publicaciones.
Por ejemplo: en el escenario en el que una publicación ha sido marcada (tipo: Publicación en cola) porque contiene una palabra de la lista de Palabras vigiladas → Requiere aprobación.
Actualmente, las opciones disponibles son:
Aprobar publicación | Rechazar publicación | Eliminar usuario | Editar
Creo que agregar las opciones de silenciar y suspender a estos tipos de publicaciones en cola sería muy útil. Por ejemplo: rechazar publicación + silenciar o suspender. Esto daría a los administradores la opción de silenciar o suspender a un usuario o eliminarlo del historial directamente desde la cola de revisión.
Además, si eliminar usuarios con más de x publicaciones desde la cola de revisión no es viable debido a errores 502, tener suspender y silenciar como opciones alternativas sería realmente excelente.
3 Me gusta
Más información:
Al abrir ‘Agrupado por tema’ desde la cola de revisión, obtengo este error:
Error del servidor
Al intentar cargar /review/topics
Código de error: 500 Error interno del servidor
Tenga en cuenta que hay ~30k elementos en la cola de revisión; muchos de los elementos más antiguos fueron agregados por Akismet antes de que lo desinstalara.
–
Problema de desplazamiento/paginación (probablemente debería haberlo publicado aquí en su lugar): Review Queue Pagination/Infinite Scrolling after Taking an Action
–
En cuanto a los elementos (tipo: Publicación en cola) y al obtener un tiempo de espera 502 al usar la opción de eliminar usuario. Puedo confirmar el error con una cuenta que tiene 166 publicaciones.
–
Ideas:
-
Sería un ahorro de tiempo útil tener un enlace directo a la página de administración del usuario desde la cola de revisión en algún lugar.
-
Creo que actualmente no es posible optar por no recibir el correo electrónico de recordatorio diario de “x elementos necesitan ser revisados”. Sería útil poder darse de baja.
2 Me gusta
¿Podrías revisar tus /logs y decirnos cuál es el error?
3 Me gusta
Ok, creo que esto es todo:
ActiveRecord::SubclassNotFound (El mecanismo de herencia de tabla única no pudo localizar la subclase: ‘ReviewableAkismetPost’. Este error se produce porque la columna ‘type’ está reservada para almacenar la clase en caso de herencia. Cambie el nombre de esta columna si no tenía la intención de usarla para almacenar la clase de herencia, o sobrescriba Reviewable.inheritance_column para usar otra columna para esa información.)
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.3/lib/active_record/inheritance.rb:234:in `rescue in find_sti_class’
2 Me gusta
¿Puedes confirmar si tu plugin Akismet es la versión más reciente y, si no lo es, actualizarlo?
4 Me gusta
Quizás no se puedan leer elementos antiguos agregados por otros tipos de revisión si desaparece la definición del elemento revisable (como al desinstalar un complemento). Parece que los errores comenzaron a ocurrir después de la desinstalación:
4 Me gusta
Puedo confirmar que Akismet está actualmente desinstalado; lo eliminé hace bastante tiempo.
1 me gusta
¡Oh, eso es interesante, como sospecha @featheredtoast! @Roman, ¿cómo crees que deberíamos manejar esto si los registros están ahí pero el complemento se ha eliminado?
4 Me gusta
Creo que es posible determinar qué tipos revisables deben filtrarse haciendo algo como esto:
class Reviewable < ActiveRecord::Base
def self.exclude_types
db_types = Reviewable.distinct.pluck(:type)
@exclude_types ||= db_types - Reviewable.types
end
...
end
Luego podemos usar esos tipos para aplicar un alcance predeterminado. Probablemente tendremos que agregar un índice de type a la tabla.
5 Me gusta
@Roman, ¿puedes encargarte de eso cuando tengas un momento?
5 Me gusta
Recibimos muchas imágenes invisibles en la cola de revisión. Algunas funcionan bien, es casi un 50/50. Algunas muestran algo como esto al inspeccionarlas y no se visualiza nada:
src="/images/transparent.png" alt="" data-orig-src="upload://fwf1zrfwefWEqGer2W3xz1ed.jpeg"
Ocurre tanto en instancias que usan CDN + S3 como en aquellas que solo usan almacenamiento local.
1 me gusta
Sí, el problema solo afecta a las publicaciones en cola.
Tengo una PR con una corrección pendiente de revisión, por lo que las imágenes deberían volver a aparecer pronto.
Te avisaré después de que la hayamos fusionado.
4 Me gusta
La corrección ya está disponible en tests-passed y stable.
Sin embargo, todavía hay otro problema: las imágenes de publicaciones en cola rechazadas no se muestran en la cola de revisión. El sistema las elimina automáticamente, ya que no es necesario conservarla. Planeamos reemplazarlas con un texto que explique esto.
8 Me gusta
¡Muchas gracias por solucionarlo, @Roman!
Otra cosa que podría ser un error en tests-passed: Escenario: Aceptar una publicación en la cola de revisión y luego volver atrás y rechazarla. La publicación seguirá apareciendo en la lista y será visible en el sitio.
Edición: Los dos últimos párrafos de este comentario también explican otro problema posible relacionado con algunas opciones de la cola de revisión y los límites de velocidad a nivel del sitio: Discourse No Bump - #27
1 me gusta
Otra cosa que he notado sobre la ‘gestión automática de la antigüedad en cola’. Tengo muchos elementos antiguos en algunas colas de revisión que son significativamente más viejos que la configuración de días de ‘gestión automática de la antigüedad en cola’ (usando la predeterminada) y que no parecen estar siendo gestionados automáticamente. No parece que ningún elemento esté siendo gestionado automáticamente. No estoy seguro de si estoy pasando por alto algo.
Además, al ordenar la cola de revisión por ‘Fecha de creación (inverso)’, obtengo un error 500. Todos los demás filtros de ‘ordenar por’ funcionan correctamente.
1 me gusta
¿Puedes revisar tus registros y decirnos cuál es el error al cambiar el orden de clasificación?
3 Me gusta
Gracias @eviltrout, sí, claro. Este es el error que veo:
ActiveRecord::SubclassNotFound (El mecanismo de herencia de tabla única no pudo encontrar la subclase: ‘ReviewableAkismetPost’. Este error se produce porque la columna ‘type’ está reservada para almacenar la clase en caso de herencia. Cambia el nombre de esta columna si no tenías la intención de usarla para almacenar la clase de herencia o sobrescribe Reviewable.inheritance_column para usar otra columna para esa información.)
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.3.1/lib/active_record/inheritance.rb:234:in `rescue in find_sti_class’
Ten en cuenta que el complemento Akismet fue eliminado hace bastante tiempo en este foro en particular.
2 Me gusta
Ah, así que sigue relacionado con eso. @Roman, parece que aún podría haber un error aquí relacionado con la presencia de esos tipos de revisión antiguos en la base de datos.
4 Me gusta