Usamos uma instância hospedada do Discourse e fazemos uso do plugin Automation fornecido com sua gama de scripts e gatilhos, no entanto, estamos tendo problemas para receber PMs do script ‘Schedule PM with data explorer results’.
Parece que o gatilho de Automação está funcionando e a consulta do Data Explorer está sendo executada (esta consulta funciona e produz resultados quando executada manualmente), no entanto, não estamos recebendo nenhuma PM após isso. Tentei comigo mesmo como destinatário e também com o grupo ‘Admin’, mas em ambos os casos nenhuma PM é recebida.
Não tenho certeza se estou perdendo algo óbvio aqui, mas qualquer ajuda seria apreciada.
Após um pouco mais de investigação, acho que pode estar relacionado ao tipo de consulta que você está tentando executar. Acabei de tentar com uma bem simples e consegui executá-la e enviar uma mensagem privada. Você poderia compartilhar qual é a sua consulta?
Obrigado por investigar isso.
A consulta não é totalmente simples e se parece com isto:
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 eu disse, ela é executada manualmente e produz resultados.
Acho que tem a ver com a mágica de estilo user_id que o explorador de dados faz ao convertê-los de IDs brutos para links utilizáveis. Se eu executar seu relatório como está, ele dá erro como você está vendo, mas se eu remover t.user_id e t.last_post_user_id do SELECT, ele funciona.
Se eu converter esses para nomes de usuário simples, também parece funcionar corretamente através da automação:
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
Embora também tenhamos contatado alguém mais experiente para analisar com mais detalhes.
Embora separadamente, não tenho certeza se sua consulta faz o que você quer. Está de alguma forma relacionada à Solução, pois estou vendo muitos PMs nos meus resultados?
Obrigado, vou tentar com alterações no ID do usuário.
Eu não escrevi essa consulta originalmente, então ainda não determinei se ela nos dará o que queremos de qualquer maneira, então provavelmente a reescreverei.
related = relations.dig(colrender[col_index].to_sym) if col_index < colrender.size
A condição if no final está incorreta: colrender deveria ser esparso, não empacotado. Ele conterá nulos se algumas, mas não todas, as colunas fornecerem dados de renderização adicionais.
A verificação correta provavelmente seria unless colrender[col_index].nil?
Além disso, este código parece negligenciar os tipos de renderização url, reltime e html porque eles não são classes ActiveRecord.
