Мы используем размещенный экземпляр Discourse и задействуем предоставляемый плагин Automation с набором скриптов и триггеров, однако у нас возникают проблемы с получением личных сообщений от скрипта «Schedule PM with data explorer results».
Похоже, что триггер Automation работает, и запрос Data Explorer выполняется (этот запрос работает и выдаёт результаты при ручном запуске), но после этого мы не получаем никаких личных сообщений. Я пробовал указаться в качестве получателя сам, а также группу «Admin», но в обоих случаях личные сообщения не приходят.
Не уверен, что упускаю что-то очевидное, но любая помощь будет очень кстати.
После небольшого дополнительного расследования я думаю, что это может быть связано с типом запроса, который вы пытаетесь выполнить. Я только что попробовал очень простой запрос, и мне удалось запустить его и отправить личное сообщение. Не могли бы вы поделиться тем, какой у вас запрос?
Спасибо за проверку.
Запрос не совсем простой и выглядит так:
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
Как я уже говорил, он запускается вручную и выдаёт результаты.
Думаю, это связано с «магией» user_id, которую Data Explorer применяет при преобразовании обычных идентификаторов в рабочие ссылки. Если запустить ваш отчет как есть, возникнет ошибка, точно такая же, как у вас, но если убрать из SELECT оба поля t.user_id и t.last_post_user_id, всё работает.
Если же заменить их на обычные имена пользователей, автоматизация тоже работает корректно:
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
Кроме того, мы уже обратились к более опытному специалисту, чтобы он подробнее разобрался в ситуации.
Отдельно отмечу: не уверен, что ваш запрос делает именно то, что вы задумали. Это как-то связано с решением (Solution), поскольку в результатах я вижу много личных сообщений (PM)?
related = relations.dig(colrender[col_index].to_sym) if col_index < colrender.size
Условие if в конце неверно: colrender должен быть разреженным массивом, а не упакованным. В нём будут присутствовать значения null, если дополнительные данные для рендеринга предоставлены не для всех столбцов.
Правильная проверка, вероятно, должна выглядеть так: unless colrender[col_index].nil?
Кроме того, этот код, похоже, игнорирует типы рендеринга url, reltime и html, поскольку они не являются классами ActiveRecord.
