Utilizziamo un’istanza ospitata di Discourse e facciamo uso del plugin Automation fornito con la sua gamma di script e trigger, tuttavia stiamo riscontrando problemi nel ricevere messaggi privati dallo script ‘Schedule PM with data explorer results’.
Sembra che il trigger di Automation funzioni e che la query di Data Explorer venga eseguita (questa query funziona e produce risultati quando eseguita manualmente), tuttavia non riceviamo alcun messaggio privato in seguito. Ho provato con me stesso come destinatario e anche con il gruppo ‘Admin’, ma in entrambi i casi non vengono ricevuti messaggi privati.
Non sono sicuro se mi stia sfuggendo qualcosa di ovvio, ma qualsiasi aiuto sarebbe apprezzato.
Dopo ulteriori indagini, penso che potrebbe essere collegato al tipo di query che stai cercando di eseguire. Ho appena provato con una molto semplice e sono riuscito a eseguirla e inviare un PM. Potresti condividere la tua query?
Grazie per aver esaminato la questione.
La query non è del tutto semplice e si presenta così:
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
Come dicevo, viene eseguita manualmente e produce risultati.
Penso che abbia a che fare con la magia dello stile user_id che l’esploratore di dati fa quando li converte da ID grezzi a collegamenti utilizzabili. Se eseguo il tuo report così com’è, si verifica un errore proprio come stai vedendo, ma se rimuovo sia t.user_id che t.last_post_user_id dalla SELECT, funziona.
Se li converto in nomi utente semplici, sembra funzionare correttamente anche attraverso l’automazione:
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
Anche se abbiamo segnalato la cosa a qualcuno più esperto per dare un’occhiata più in dettaglio.
Anche se separatamente, non sono sicuro che la tua query faccia quello che vuoi. È in qualche modo correlata alla Soluzione, dato che vedo molti PM nei miei risultati?
related = relations.dig(colrender[col_index].to_sym) if col_index < colrender.size
La condizione if alla fine è errata: colrender dovrebbe essere sparso, non compatto. Conterrà valori null se alcune, ma non tutte, le colonne forniscono dati di rendering aggiuntivi.
Il controllo corretto sarebbe probabilmente unless colrender[col_index].nil?
Inoltre, questo codice sembra trascurare i tipi di rendering url, reltime e html perché non sono classi ActiveRecord.
Per quanto mi riguarda, sembra che non riesca a far scattare correttamente questo script di automazione, indipendentemente dalla query dell’esploratore di dati. Ad esempio:
