Usamos una instancia alojada de Discourse y hacemos uso del plugin de Automatización proporcionado con su gama de scripts y desencadenadores, sin embargo, estamos teniendo problemas para recibir PMs del script ‘Programar PM con resultados del explorador de datos’.
Parece que el desencadenador de Automatización está funcionando y la consulta del explorador de datos se está ejecutando (esta consulta funciona y produce resultados cuando se ejecuta manualmente), sin embargo, no estamos recibiendo ningún PM después de esto. He probado conmigo mismo como destinatario y también con el grupo ‘Admin’, pero en ambos casos no se reciben PMs.
No estoy seguro si me estoy perdiendo algo obvio aquí, pero cualquier ayuda sería apreciada.
Tras un poco más de investigación, creo que puede estar relacionado con el tipo de consulta que intentas ejecutar. Acabo de intentarlo con una muy simple y he conseguido que funcione y envíe un mensaje privado. ¿Podrías compartir tu consulta?
Gracias por investigar esto.
La consulta no es totalmente simple y se ve así:
WITH
ua AS (
SELECT target_topic_id, COUNT(id) FROM user_actions
WHERE action_type = 15
GROUP BY target_topic_id
)
SELECT
t.id,
t.title,
t.created_at,
t.last_posted_at,
t.views,
t.posts_count,
t.user_id,
t.last_post_user_id
FROM topics t
INNER JOIN users us ON us.id = t.user_id
LEFT JOIN ua ON ua.target_topic_id = t.id
WHERE t.deleted_at IS NULL
AND t.closed = false
AND t.archived = false
AND t.visible = true
AND ua.target_topic_id IS NULL
AND us.username_lower != 'system'
AND t.created_at > now() - INTERVAL '7' DAY
ORDER BY created_at DESC
Como digo, se ejecuta manualmente y produce resultados.
Creo que tiene que ver con la magia de estilo user_id que hace el explorador de datos al convertirlos de IDs simples a enlaces utilizables. Si ejecuto tu informe tal como está, da error como estás viendo, pero si elimino tanto t.user_id como t.last_post_user_id del SELECT, sí funciona.
Si los convierto en nombres de usuario simples, también parece funcionar correctamente a través de la automatización:
WITH
ua AS (
SELECT target_topic_id, COUNT(id) FROM user_actions
WHERE action_type = 15
GROUP BY target_topic_id
)
SELECT
t.id,
t.title,
t.created_at,
t.last_posted_at,
t.views,
t.posts_count,
us.username,
u2.username
FROM topics t
INNER JOIN users us ON us.id = t.user_id
LEFT JOIN ua ON ua.target_topic_id = t.id
JOIN users u2 ON u2.id = t.last_post_user_id
WHERE t.deleted_at IS NULL
AND t.closed = false
AND t.archived = false
AND t.visible = true
AND ua.target_topic_id IS NULL
AND us.username_lower != 'system'
AND t.created_at > now() - INTERVAL '7' DAY
ORDER BY created_at DESC
Aunque también hemos contactado a alguien más experto para que lo revise con más detalle.
Aunque por separado, no estoy seguro de que tu consulta haga lo que quieres. ¿Está relacionada de alguna manera con la Solución, ya que veo muchos PM en mis resultados?
related = relations.dig(colrender[col_index].to_sym) if col_index < colrender.size
La condición if del final es incorrecta: colrender se supone que es disperso, no empaquetado. Contendrá nulos si algunas, pero no todas, las columnas proporcionan datos de renderizado adicionales.
La comprobación correcta probablemente sería unless colrender[col_index].nil?
Además, este código parece descuidar los tipos de renderizado url, reltime y html porque no son clases de ActiveRecord.
