Tienes razón. El error de clasificación en la cola de revisión ocurre porque hay elementos revisables de Akismet en la base de datos después de que se eliminó el plugin. Veo dos soluciones posibles aquí:
Proporcionar una tarea de rake para eliminar estas filas de la base de datos antes de que el usuario decida eliminar el plugin permanentemente.
Aplicar un ámbito predeterminado a la clase Reviewable que excluya estas filas si el plugin está deshabilitado.
¿Ocurre cuando la publicación está esperando revisión? ¿O después de rechazarla? Como mencioné antes, las subidas de publicaciones en cola rechazadas son eliminadas automáticamente por el sistema.
Creo que la desinstalación de plugins es poco común y que la cuestión del ámbito predeterminado es más propensa a introducir errores.
Creo que sería razonable si agregáramos una tarea de Rake y la incluyéramos en el README, bajo una sección de “desinstalación”, con instrucciones para ejecutarla y eliminar los registros antiguos. ¡Hagámoslo!
He intentado desactivar ‘notificar sobre publicaciones en cola después’ estableciéndolo en 0 y también en 2000000000. Aun así, sigo recibiendo muchas notificaciones frecuentes de ‘x elementos necesitan ser revisados’.
El sistema los está enviando porque hay elementos pendientes en la cola. La configuración que modificaste es para recordatorios de publicaciones en cola; establece notify_about_flags_after en 0 en su lugar.
Gracias @Roman: puedo confirmar que modificar notify_about_flags_after a 0 detuvo las notificaciones
¡Realmente agradezco que hayas añadido la tarea de rake para esto! Reinstalaré Akismet y ejecutaré la tarea de rake más tarde hoy, cuando el tráfico esté en su punto más bajo, y luego actualizaré esta publicación con los resultados.
Parece que los usuarios cuyos publicaciones van directamente a la cola de revisión pueden eludir bastantes límites de velocidad para la creación de temas y publicaciones/respuestas.
Opciones de límite de velocidad que parecen eludibles:
límite de velocidad para crear tema, límite de velocidad para que usuarios nuevos creen temas, máximo de temas por día, límite de velocidad para crear publicación, límite de velocidad para que usuarios nuevos creen publicaciones, minutos entre publicaciones únicas, máximo de respuestas consecutivas.
Opciones para enviar temas y publicaciones directamente a la cola de revisión:
‘aprobar conteo de publicaciones’ (usuarios nuevos que necesitan que sus primeros temas/publicaciones sean aprobados), así como las opciones individuales de categoría de ‘Requiere aprobación del moderador para todos los nuevos temas’ y muy probablemente (solo he probado la opción de nuevos temas) ‘Requiere aprobación del moderador para todas las nuevas respuestas’.**
¡Ah, ya veo! Gracias por la explicación. Solo compartiré mis experiencias al respecto como referencia.
Sin que se apliquen los límites, se permite a los nuevos usuarios (con aprobación basada en la cantidad de publicaciones) inundar libremente la cola de revisión con pocos o ningún límite, mientras que las cuentas antiguas y de confianza están sujetas a límites de velocidad. Excepto cuando se habilitan las opciones de categoría para aprobar todos los temas o respuestas, en cuyo caso los usuarios antiguos y de confianza tampoco tienen límites o tienen límites mínimos.
Sería bastante trabajo, pero factible aprobar todos los nuevos temas, así como los temas/publicaciones iniciales creados por nuevos usuarios (si están sujetos a límites de velocidad), pero en mi caso es casi inviable cuando los usuarios pueden inundar la cola.
De todos modos, muchas gracias por la aclaración de que esto es así por diseño. Es muy útil. Creo que revisaré mi estrategia y desactivaré las opciones que envían temas o publicaciones directamente a la cola de revisión, reservándola principalmente para contenido marcado. Luego, simplemente moderar las envíos en vivo sujetos a límites de velocidad después de ocurridos debería funcionar bien y ser más dinámico para los usuarios también.
Recientemente configuré la opción de sitio solo por invitación y ahora hay un elemento en la cola de revisión generado por el sistema para una cuenta de usuario, marcado como Requiere aprobación.
Lo extraño es que se trata de una cuenta existente (de 4 años) con múltiples publicaciones y nivel TL2, pero no ha estado activa recientemente (la última publicación fue hace 2 años). Sin embargo, ha iniciado sesión hoy, tras lo cual se generó la bandera de revisión.
Aún no he utilizado la opción Aprobar usuario y el elemento sigue en la cola de revisión, pero parece que la cuenta está habilitada y puede usar el foro (como debería).
Parece que la cola de revisión está identificando las cuentas reactivadas recientemente como nuevas y las marca para revisión cuando solo por invitación está activado.
Edición: esto también acaba de ocurrir con una cuenta muy reciente, creada solo unos días antes de habilitar esta configuración.
Creo que ya he visto esto antes cuando se cambia a modo solo por invitación. En algunas situaciones, Discourse piensa que necesitas aprobar al usuario porque obtuvo acceso al sitio registrándose de forma regular. Cuando se cambia ese interruptor, su registro no tiene establecida la marca “Aprobado”.
He investigado esto más a fondo y lo único que tienen en común estas cuentas (cuatro en total) es que todas iniciaron sesión utilizando una de las rutas de inicio de sesión con correo electrónico (a través de forgot_password o directamente mediante email_login) después de que se estableció invite_only.
¿Se ha considerado añadir la opción de suspender a los temas/publicaciones en revisión marcados por Akismet? Se ha sugerido en nuestra instancia, simplemente porque usamos SSO, por lo que eliminar miembros rara vez es efectivo; el miembro puede volver a iniciar sesión en su cuenta en el proveedor principal y accederá instantáneamente a los foros para continuar. La suspensión les dificulta las cosas, ya que tendrían que crear una nueva cuenta en el proveedor con una nueva dirección de correo electrónico.
Sé que es una solicitud un poco extraña, pero una que mis moderadores preguntan con bastante frecuencia. Hoy en día, ellos van manualmente por el sistema para suspender al usuario, lo que les genera un esfuerzo adicional, pero vale la pena porque el usuario finalmente no está dispuesto a desechar otra dirección de correo electrónico.