If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?
End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue
This is an interesting use case and I’d like to help you get it working.
Actions for reviewable types are returned from the build_actions method.
What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.
That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.
Robin,
Actualmente estoy preparando una PR para el plugin de OAuth de Discord, principalmente para almacenar más información del usuario de Discord en Discourse. Estoy intentando usar tu modelo ReviewableUser para mantener la funcionalidad que implementa la aprobación automatizada.
Dado que la implementación actualmente crea una revisión para nuevos usuarios de forma asíncrona, necesito verificar si se ha creado dicha revisión y eliminarla.
Desafortunadamente, estoy obteniendo un error muy extraño de Ruby y me preguntaba si te ha ocurrido algo similar.
El código es:
def after_create_account(user, auth)
super
data = auth[:extra_data]
if !user.approved && data[:auto_approve]
user.approved = true
user.approved_by_id = Discourse.system_user.id
if reviewable_user = ReviewableUser.find_by(target: user)
reviewable_user.set_approved_fields!(user, Discourse.system_user)
end
end
end
En cuanto se ejecuta ReviewUser.find_by, obtengo una excepción:
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
Aunque pensé que estaba avanzando bien en Ruby, no tengo claro por qué está ocurriendo esto.
¿Podría ser un problema de rutas? He probado varios require, pero eso solo complica más las cosas.
Es muy similar a patrones similares en otras partes del código principal. ¡Agradezco mucho cualquier opinión!
El repositorio está aquí si lo necesitas: discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
¡Ese error constante no es muy informativo, ¿verdad?! Creo que tiene que ver con los motores de Rails y los espacios de nombres. Una cosa rápida que podrías probar es ::ReviewableUser con dos dos puntos antes. Eso le indica que use el espacio de nombres raíz, no el del motor.
Este código también parece un poco desactualizado para la API de reviewable. Debería ser algo así:
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
Eso resolvió el error. Asumo que, como no podía encontrar la clase antes, la estaba tratando como una constante? De todos modos, eso lo ha solucionado, brillante, ¡muchas gracias! ¡Ya estoy desatascado!
La razón por la que tenía esto:
user.approved = true
user.approved_by_id = Discourse.system_user.id
antes de:
reviewable.perform(:approve, Discourse.system_user)
es porque la adición a la cola de revisión es asíncrona. En el trabajo, la revisión solo se crea si approve es falso (discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub):
if user = User.find_by(id: args[:user_id])
return if user.approved?
@reviewable = ReviewableUser.needs_review!(
target: user,
created_by: Discourse.system_user,
reviewable_by_moderator: true,
payload: {
username: user.username,
name: user.name,
email: user.email
}
)
¿Existe el riesgo de que el trabajo se ejecute después de que hayas comprobado la entrada de revisión?
El resultado es que la entrada de revisión parece no existir, pero el trabajo simplemente está esperando para ejecutarse. Luego el trabajo se ejecuta y crea la entrada de revisión, y has perdido la oportunidad de eliminarla porque tu código para probar esto ya se había ejecutado.
¿Es una condición de carrera potencial?
Establece approved en true antes de verificar la entrada de revisión y habrás resuelto el problema (porque una revisión nunca se creará después de esto, ya que es una dependencia).
Me encontré con este problema al probar mi código: en desarrollo funcionaba, pero en producción falló porque las cosas se ejecutaron en un orden diferente.
Nota: Agradezco que no hayas escrito esto para soportar este caso de uso, pero creo que es importante permitir que los plugins puedan aprobar automáticamente a nuevos usuarios en circunstancias especiales (por ejemplo, como el plugin de Discord que lo hace si el usuario es miembro de un gremio de confianza).
De hecho, el registro revisable se crea de forma asíncrona, lo cual es problemático en esta situación, ya que iniciar sesión creará el usuario y es posible que el registro de aprobación aún no exista.
Una solución mejor sería no crear el registro revisable en esta situación; sin embargo, requeriría cambios en el núcleo para funcionar correctamente. Podría funcionar de la siguiente manera:
skip_approval: true.Gracias, Robin, sí.
Por ahora he optado por mi solución alternativa, consciente de que habrá que abordarla antes de que se elimine el acceso directo a la API.
¿Hay interés por parte del equipo en priorizar esto antes de que se elimine el acceso de escritura directo a user.approve?
Creo que ese cambio romperá la función actual de autoaprobación de Guild confiable en el plugin de inicio de sesión de Auth de Discord (incluso sin la PR que acabo de abrir para ese plugin). @featheredtoast
Estaría encantado de actualizar mi PR con soporte para ese cambio si se implementa.
No veo que lo eliminemos pronto. No quiero depender de él para siempre, pero debería funcionar bien por un tiempo.
La cola está muy bien y la función de ‘agrupar por tema’ también es útil.
Sin embargo, por lo que puedo ver, no hay forma de seleccionar y procesar publicaciones en masa. Cada publicación debe procesarse individualmente.
¡La selección y el procesamiento en masa serían un gran ahorro de tiempo!
Creo que sería una mejora excelente. Para ser justos, la cola de banderas nunca tuvo operaciones masivas, así que no es como si esto fuera una regresión.
Además, algunas operaciones como “Suspender” son un poco extrañas cuando se trabajan varias filas. Tendrían que limitarse a las operaciones básicas para tener algún sentido.
Encontré un pequeño problema: alguien publicó en una categoría que requiere aprobación, por lo que aparece en la cola de revisión. Publicó en la categoría incorrecta, así que intenté cambiarla desde la cola de revisión. No hubo problema, excepto que la categoría a la que intento moverla requiere una etiqueta específica, pero esa etiqueta está restringida a la nueva categoría. Como la publicación en la cola de revisión aún parece estar en la categoría original (que no permite dicha etiqueta), me quedo atascado. Es bastante fácil aprobar la publicación y cambiarla después, pero parece algo que debería corregirse.
Sé que esto debería estar solucionado, pero las URL aún no se están agregando a la lista de filtradas. Probablemente ni siquiera importe realmente, ya que la acción para las URL filtradas dice
¿Solo para confirmar que has actualizado a la versión correcta? Deberían ser filtrados si no son compatibles con onebox o son internos.
Sí, estoy en la v2.4.0.beta2 +66. La próxima vez que ocurra, haré una copia del post.
Sí, después de hacer clic en “Eliminar usuario” en la cola de revisión, el correo electrónico y la dirección IP se agregaron a las listas filtradas, pero no las URLs. El mensaje era:
¿Necesita [Servicio de redacción académica](https://myassignmenthelp.com/uk/academic-writing-service.html) en línea? Ofrecemos el mejor servicio de redacción académica del mundo a través de Myassignmenthelp.com. Servicio profesional de redacción académica con una amplia gama de opciones para estudiantes al mejor precio.
¿Recuerdo correctamente que las URLs nunca se han añadido automáticamente a la lista de filtrados? Bueno, supongo que sí, revisé mi instancia y hay un montón de URLs allí 
Ah, sí, me acordé. En realidad no hacen nada, solo son informativas.
Puedes agregar esos nombres de dominio a las palabras vigiladas para que no se puedan ingresar, pero tendrás que hacerlo tú mismo.
Por eso sería bueno que se añadieran a la lista de vigilancia: incluso si no se toma ninguna acción automática sobre las URLs, nos permitiría ver qué spam se está publicando. Ten en cuenta que los moderadores pueden usar la cola de revisión, pero no pueden (creo) añadir palabras vigiladas.
Algunos comentarios menores sobre la experiencia de usuario: sería genial si la cola de revisiones recordara mis configuraciones. Dado que trabajamos con un equipo de moderadores, personalmente me interesa principalmente ver las nuevas denuncias y las ordeno por ‘Fecha de creación’, pero esta configuración no se guarda.
Esa no es una mala sugerencia. Por ahora, afortunadamente, existe una solución alternativa: los filtros de búsqueda se guardan en la cadena de consulta (URL). Si guardas un filtro en tus marcadores, siempre podrás volver a él.
