Плагин Bitrix24
Поддерживаются внутренние чаты Bitrix24. Открытые линии, очередь клиентских обращений и передача оператору не поддерживаются.
Плагин Bitrix24 подключает вашего агента к Bitrix24 как внутренний мессенджер для сотрудников. Сотрудники пишут агенту так же, как написали бы коллеге, а агент отвечает прямо в чате Bitrix24.
[!WARNING] Bitrix24 здесь — это внутренний мессенджер для сотрудников, как Telegram или Slack для персонала. Это не клиентский омниканал: нет Открытых линий, нет очереди клиентских обращений и нет передачи диалога оператору. Не используйте этот плагин как фронт клиентской поддержки.
Плагин работает напрямую в Linux (без контейнеров) и общается со шлюзом по контракту
aihummer.connector.v1. Поведение канала для конечного пользователя — на странице
канала Bitrix24; эта страница про сам плагин.
Описанные ниже медиа и общее OAuth-подключение требуют подписанного Core 1.4.15 и отдельно подписанного коннектора 1.1.1 после публикации в каталоге и обновления. Установленный коннектор 1.1.0 не подтверждает доступность этих возможностей.
Факты
| Поле | Значение |
|---|---|
| Версия | 1.1.1 |
| Порт | 8810 |
| Среда | без контейнеров (systemd) |
Что это такое
Двусторонний мост между чатом Bitrix24 и AiHummer. Каждый агент аутентифицируется своей отдельной OAuth-учётной записью, а не общим bot-аккаунтом, поэтому в Bitrix24 агент отображается как отдельный коллега, а не как общий бот. Доступ следует ACL по дереву подразделений организации, так что доступ агента соответствует организационной структуре в Bitrix24.
Укажите отдельных пользователей портала в BITRIX24_AGENT_USER_IDS, а портал — в BITRIX24_PORTAL. Маршрутизация по отделам ограничивает допуск сотрудников; учётная запись агента не подменяет инициатора задачи. Необязательное существующее автоматическое подключение использует BITRIX24_ADMIN_LOGIN / BITRIX24_ADMIN_PASSWORD.
При указанных версиях BITRIX24_VAULT_CONNECTIONS выбирает для канала существующее действующее OAuth-подключение в автономном режиме, принадлежащее регистрирующему пользователю. Используйте поддерживаемое управление нативным хранилищем и подключениями; тот же ID учётных данных выбирается в привязках инструментов. Настоящий владелец регистрирует работающий коннектор в его рабочем пространстве через /v1/admin/connections/channel с отдельным ключом connection-token. В секретной настройке BITRIX24_VAULT_CONNECTIONS задайте endpoint и apiKey по ID пользователя-агента; никогда не помещайте их в профили или запросы агенту. Только хранилище обновляет токены; инструменты сохраняют проверки инициатора и общего доступа. См. OAuth2.
Как используется
- Входящие: опрос читает сообщения. Медиа скачивается байтами и регистрируется через
/v1/inbound/media; агент получаетmedia_id, а не только URL или сведения о файле. - Исходящие:
Deliverпереводит Markdown в BB-code и загружает настоящие байты черезim.v2.File.upload. Подтверждение медиа требует настоящихFILE_IDи ID сообщений; текст или ссылка не являются квитанцией файла.
Сохраняйте долговечный журнал доставки при обновлении. Повтор подтверждённой операции возвращает прежнюю квитанцию. Частичный или неизвестный эффект автоматически не отправляется повторно; проверьте его перед повтором.
сотрудник ─▶ чат Bitrix24 ─▶ pull-опрос ─▶ шлюз (маршрутизатор · обработка) ─▶ Deliver (Markdown→BB-code, идемпотентно) ─▶ Bitrix24
Поддерживаемые возможности
- Реакции и @-упоминания.
- Набор и ответы, если аккаунт и площадка поддерживают
im.dialog.writingиREPLY_ID. - Входящие изображения, аудио, голос и файлы с учётом требований к версиям выше.
- Редактирование/удаление сообщений — только у прежних интеграций с отдельной идентичностью бота; для обычного OAuth-пользователя они не объявляются.
Ограничения
[!WARNING] Интерактивные клавиатуры, кнопки и треды не поддерживаются.
Созданный или подготовленный файл ещё не означает подтверждённую доставку. Частичные, неуспешные и неизвестные результаты должны оставаться видимыми.
Установка
Установите Bitrix24 в один клик из маркетплейса в админ-панели. Deployer
скачивает плагин, выполняет шаг установки, генерирует изолированный
systemd-юнит и считает установку успешной только после ответа /healthz — см.
Установка и обновления. Затем вы
подключаете OAuth-учётную запись каждого агента и сопоставляете ACL по дереву
подразделений.
Безопасность и ограничения
- Только внутренний мессенджер для сотрудников — не клиентский омниканал.
- Отдельная OAuth-учётная запись на каждого агента — агенты не общие bot-аккаунты.
- ACL по дереву подразделений — доступ соответствует организационной структуре.
- Без контейнеров — работает под systemd, не в контейнере.