Я знаю, что это происходит, когда кто-то из Discourse ставит лайк теме о баге, опубликованной в Contribute > Bug. Вы используете для этого веб-сервис и просто отслеживаете первый лайк на новом посте, проверяя, чтобы его не ставили несколько раз одним и тем же пользователем из CDCK?
SELECT distinct p.user_id, p.created_at granted_at, p.id post_id
FROM badge_posts p
JOIN topics t ON t.id = p.topic_id
JOIN post_actions pa ON pa.post_id = p.id AND
post_action_type_id = (
SELECT id FROM post_action_types WHERE name_key = 'like'
) AND
pa.user_id IN (
SELECT gu.user_id
FROM group_users gu
WHERE gu.group_id = ( SELECT id FROM groups WHERE name ilike 'team' )
)
WHERE category_id = (
SELECT id FROM categories WHERE name ilike 'bug'
) AND p.post_number = 1
(Кстати, я также создал аналогичные значки, которые срабатывают при определённой реакции от конкретной группы )
@JammyDodger это потрясающе! У меня пока не было времени заняться запросами пользовательских значков, но, возможно, это наконец даст мне возможность начать.
Если можно спросить, как вы обрабатываете сообщения об ошибках внутри компании, помимо значка? По крайней мере, в контексте Meta? Вы вручную добавляете их в какую-то очередь ошибок? Используете ли вы плагин для отправки их в очередь ошибок прямо из темы?
Меня также интересует, как организована работа с сообщениями об ошибках и запросами на новые функции в Discourse и как вы связываете это с вашей системой разработки/внутренними системами.
Это действительно очень увлекательно. А если вам нужна идея или совет, примеров в сети множество.
Категория Contribute > Bug является важной частью нашей очереди ошибок. Чтобы избежать дублирования, мы часто решаем проблему непосредственно в теме Meta (используя личные сообщения, упоминания @ и назначения) и действительно переносим вопросы в раздел команды только в том случае, если требуется дополнительное обсуждение или участие других. Мы также получаем отчеты об ошибках через каналы поддержки клиентов, которые также часто решаются «в рамках темы», если нет нескольких отчетов или уже существует публичный отчет (в этом случае обычно используется один основной отчет, чтобы не разделять обсуждение слишком сильно, а остальные связаны с ним перекрестными ссылками). Для тех случаев, которые мы обнаруживаем сами, у нас есть несколько внутренних тем, которые мы используем для фиксации небольших задач, готовых к выполнению кем-либо, а для более крупных задач мы создаем отдельные темы таким же образом, как и в публичной категории Contribute > Bug.
Обычно процесс выглядит так: поступает отчет, и один из нас пытается воспроизвести ошибку и собрать необходимые дополнительные сведения. После подтверждения мы отправляем сигнал группы @mention соответствующей группе/человеку, чтобы назначить приоритет и распределить задачу. После внесения исправления мы публикуем пост в теме, чтобы закрыть её (с небольшой задержкой таймера темы, чтобы сначала убедиться, что всё работает как задумано ).
С категорией Contribute > Feature дело обстоит немного иначе, так как там обычно требуется больше внутренних обсуждений. Мы стараемся минимизировать использование личных сообщений в этих публичных темах и оставляем их для коротких заметок и привлечения внимания к темам, которые набирают популярность (снова используя упоминания @ ). Таким образом мы не разбиваем обсуждение на слишком много мест. Менеджеры продукта также любят участвовать в этих обсуждениях публично, чтобы изучить различные варианты использования и оценить возможности (а также чтобы люди знали о наших мыслях по этому вопросу, так как мы стремимся к прозрачности, где это возможно ). Если предложение из категории Contribute > Feature становится тем, что мы серьезно рассматриваем, для него создается внутренняя тема, где разработчики, дизайнеры, менеджеры продукта, любопытные модераторы сообщества и другие могут внести свои идеи и макеты того, как, по их мнению, это можно лучше всего реализовать (с перекрестными ссылками на тему Meta, чтобы связать их вместе).
Теперь, когда я всё это написал, не уверен, что это было полезно… Но дайте знать, если вы хотите узнать что-то еще.