Интеграции с трекерами

Интеграция с трекером даёт две вещи: команда обращается к Buff там, где уже работает — в тикете, в задаче, в обсуждении pull request, — вопрос задают комментарием, ответ приходит туда же; а модель в «Спросить» и в глубоком исследовании читает ваш трекер как источник — как именно.

Все трекерные интеграции ведут себя одинаково; отличается только то, чего в конкретном трекере нет. Различия — в таблице ниже.

Как обратиться к боту

Работа запускается только прямым обращением. Это решение, а не ограничение: метки и статусы меняют правила автоматизации и массовые правки, и запуск по ним означал бы работу, которую никто не заказывал, но кто-то оплатил.

Обратиться можно двумя способами, оба работают везде:

Полезные подробности:

• Регистр не важен. @Buff, @BUFFBOT, /Research — всё это обращения.
• Псевдоним. Кроме учётной записи бота работает короткое имя из настройки подключения (mention_alias), обычно @buff.
• Автодополнение трекера тоже подходит: вставленное упоминание распознаётся, как и набранное руками.
• Текст вокруг обращения учитывается — можно сначала описать контекст, а потом попросить.
• Повторное обращение в том же тикете продолжает тот же разговор: можно уточнять, не начиная с нуля.
• Чужие обращения бот не перехватывает: @buffalo — это другой человек.

Что можно попросить

Без команды это вопрос: самый частый случай и потому умолчание.

Область видимости — это контроль доступа

У каждого подключения есть список: репозитории или ключи проектов, где бот работает. Список действует в обе стороны — в неотмеченных местах бот не читает обращения и не пишет ответы.

Права учётной записи бота в трекере — внешняя граница, список — внутренняя. Разумно иметь обе: доступ бота ограничен тем, что ему выдали, а внутри — тем, что вы отметили.

Кто может спрашивать бота

Список мест говорит, где бот отвечает. Кто из людей может к нему обращаться — отдельная настройка подключения «Кто может спрашивать бота» (коннектор v0.18.0 и новее):

• правила, по одному на строку: логин (petrov), адрес (petrov@company.ru), домен (@company.ru) или регулярное выражение (/^dev-.+@company\.ru$/);
• «Участники организации Buff» — спрашивать могут те, чей адрес в системе совпадает с адресом участника вашей организации в Buff; при едином входе — любой адрес на подтверждённых доменах организации.

Пустой список и снятая галочка — спрашивают все, как раньше. Автору, которого правила не пускают, бот вежливо отвечает, что спросить можно в Buff, и даёт ссылку; ничего не запускается и не списывается. Каждый запрос и каждый отказ записываются в журнал аудита — без текста вопроса.

Логин и адрес бот берёт из самой системы, и показывают их не все: у Jira Cloud, Confluence Cloud, Notion и Google Диска логина нет — только адрес, если человек его не скрыл; GitHub, GitLab и Gitea показывают адрес, только если он открыт в профиле; Redmine — только токену администратора; у Bitbucket Cloud адреса нет. Figma не показывает ни того, ни другого: при заданных правилах спросить из неё не сможет никто.

Ответ публикуется так же закрыто, как задан вопрос: на внутреннюю заметку GitLab — внутренней заметкой, на закрытую заметку Redmine — закрытой, на комментарий Jira для роли или группы — для той же роли или группы, на внутренний комментарий Jira Service Management — внутренним. Документ к закрытому вопросу к задаче не прикладывается (вложение увидели бы все) — он остаётся в Buff по ссылке.

Ответ по коду того места, где спросили

Вопрос, заданный в обсуждении pull request, — это вопрос про код этой ветки. Интеграция передаёт ветку вместе с обращением, платформа подтягивает её из вашего репозитория и считает ответ на ней.

Чтобы это работало, репозиторий должен быть подключён к Buff как источник кода — тем же коннектором, в разделе «Репозитории». Если он не подключён, бот всё равно ответит по основной ветке проекта и прямо скажет об этом в тикете: ответ, посчитанный по другому коду и выданный за ответ на этот pull request, хуже, чем никакого.

Что бот пишет в тикет

1. Сразу — короткое «принял, работаю»: исследование идёт минутами, и без этого непонятно, услышал ли бот вообще.
2. Ссылку — на обсуждение, черновик или исследование в Buff. Там, где трекер умеет хранить ссылки отдельно (Jira), она попадает в блок ссылок тикета, а не тонет в ленте комментариев.
3. Результат — готовый ответ комментарием. Для исследования — ещё и сам документ: там, где трекер принимает вложения, PDF прикладывается к тикету.

Если данных не хватает, бот задаст уточняющий вопрос в том же тикете и дождётся ответа. Если что-то не получилось — тоже напишет: молчание читалось бы как поломка.

Статусы, метки, исполнителей и поля бот не трогает никогда. Ни одна трекерная интеграция не имеет для этого инструмента: единственный пишущий инструмент — комментарий, и модели он не отдаётся.

Назначение задачи боту

Назначение — пограничный случай: задача действительно адресована боту, но назначают и по правилам маршрутизации, когда работу никто не заказывал. Поэтому оно выключено по умолчанию и включается галочкой «Принимать задачи, назначенные боту» — если у вас назначает человек осознанно.

События: опрос и вебхуки

Опрос работает всегда. Каждое подключение читает свой трекер по своему интервалу — по умолчанию раз в 20 секунд; интеграция может предложить иной, а поле «Интервал опроса» у подключения решает окончательно. Для этого не нужно открывать наружу ни одного порта — соединение исходящее. Для закрытого периметра это рабочий режим по умолчанию.

Вебхуки только ускоряют доставку. Приёмник принадлежит коннектору — один адрес на все подключения, настраивается в разделе «Подключение». У самого подключения есть только выключатель: ссылку с секретом выдаёт коннектор, придумывать её не нужно.

Куда вставлять ссылку и на какие события подписываться:

Старые обращения бот не разгребает. Отсчёт для нового подключения начинается с момента, когда вы его включили: тикеты, написанные до этого, не будут внезапно отвечены задним числом.

Какой трекер что умеет

Кроме трекеров в каталоге есть источники знаний — Confluence, Notion, Google Диск, Figma и файлы на диске: там бот не ведёт задачи, а читает написанное командой и отвечает в обсуждении страницы; есть интеграция «Интернет» и возможность принести свой сервер MCP. Отдельные страницы: «Источники знаний», «Интернет», «Свои MCP-серверы».

У Bitbucket Data Center своего трекера задач нет — интеграция живёт в pull request. У Bitbucket Cloud трекер задач Atlassian из API убрал (410 Gone) — интеграция, как и у Data Center, живёт в pull request. Если задачи у вас в Jira или Redmine, поставьте рядом их интеграцию: подключений может быть сколько угодно, и у каждого свой проект разработки или пространство.

Что уходит к нам из трекера

Только то, без чего запрос не выполнить, и только по прямому обращению:

• текст обращения (без остального содержимого тикета — его модель читает инструментом, когда он ей нужен);
• заголовок и ссылка на тикет, ключ тикета, имя автора обращения;
• для вопроса из pull request — имя ветки и репозитория.

Токен трекера не уходит никогда: запросы к трекеру делает коннектор изнутри вашей сети.

Если что-то не работает