Интеграции и Telegram

Интеграция Odoo с Telegram: отчёты и операционные сценарии

Telegram может быть лёгким интерфейсом чтения отчётов из Odoo или операционным интерфейсом, который изменяет ERP-данные. Во втором случае недостаточно проверить только идентификатор пользователя Telegram: нужны прикладная авторизация, ограничения доступных объектов и подтверждение опасных действий. Это инженерный вывод из двух реализованных сценариев.

Краткий ответ

Сценарий отчётности обычно требует идентификации пользователя, ограничения доступного контекста и операций только на чтение. Операционный сценарий добавляет отдельные требования к авторизации записи, ограничениям на объекты и подтверждению опасных действий. Этот набор мер задаёт инженерную границу, но сам по себе не гарантирует безопасность системы.

Применимость

Основная система Buildflow работает на Odoo 17 Community, а Telegram-компонент создавался как отдельное Python-приложение. Материалы не связывают его с конкретным рабочим экземпляром Odoo. Atkinternal работает на Odoo 18 Enterprise с Enterprise Planning.

Два сценария Odoo + Telegram

Отчётный сценарийОперационный сценарий
ПримерBuildflowAtkinternal
Чтение данныхДаДа
Запись данныхНет в опубликованном функциональном контуреДа
ИдентификацияTelegram ID → пользователь OdooTelegram ID → пользователь Odoo
Проверка разрешенийОграничение по доступному контекстуПрикладная проверка до операции
Подтверждение записиНе применимоДля изменения и удаления
Основной рискРаскрытие данныхНесанкционированное изменение

Сценарий 1: отчётность и чтение на примере Buildflow

Опыт проекта

Telegram-компонент был отдельным Python-приложением с пакетом estimate_reports_bot, отдельным odoo_client и запускался процессом python -m estimate_reports_bot. На этапе разработки он работал с тестовым контуром Odoo.

Пользователь выбирал подрядчика, проект или корпус и получал соответствующий отчёт. Odoo оставалась системой-источником, а Telegram предоставлял мобильный интерфейс запроса и чтения. Публично описанный функциональный контур относится к отчётности и чтению данных.

Telegram ID сопоставлялся с пользователем Odoo. Доступ предназначался только для авторизованных Telegram-пользователей и ограничивался компанией, подрядчиком и проектом. Неавторизованный пользователь не получал данные или функции. Использованная Telegram-библиотека и протокол соединения с Odoo в материалах не зафиксированы.

  1. Пользователь TelegramВыбирает компанию, подрядчика, проект или корпус.
  2. Сопоставление пользователяTelegram ID связывается с пользователем Odoo; доступный контекст ограничивается.
  3. Python-приложениеЗапрашивает данные через отдельный odoo_client.
  4. OdooВозвращает данные отчёта как система-источник.
  5. TelegramПоказывает ограниченный отчёт на телефоне.
Сценарий отчётности: интерфейс Telegram не становится владельцем ERP-данных.

Подробнее: Buildflow — отчёты из Odoo в Telegram.

Сценарий 2: операции записи на примере Atkinternal

Опыт проекта

Atkinternal работает с Odoo 18 Enterprise Planning через XML-RPC. Вызовы Odoo аутентифицируются отдельным техническим пользователем бота. Telegram-пользователь сопоставляется с пользователем Odoo через x_telegram_user_id; после идентификации бот сохраняет связь с найденным пользователем Odoo в состоянии диалога. Это сопоставление используется прикладным слоем авторизации; данных о переключении ORM-контекста на связанного пользователя Odoo нет.

Для поиска доступности используется связь hr.employee.resource_id → planning.slot.resource_id. Бот поддерживает четыре подтверждённых сценария:

  • поиск свободных сотрудников и ресурсов;
  • создание planning.slot;
  • изменение planning.slot;
  • удаление planning.slot.

В Python-приложении использовались классы Application, MessageHandler и CallbackQueryHandler. Название библиотеки не указано, поскольку оно не зафиксировано в проверенных материалах.

  1. Пользователь TelegramВыбирает период и операцию Planning.
  2. Прикладная авторизацияx_telegram_user_id определяет связанного пользователя Odoo.
  3. Ограничение объектаПроверяется разрешённость операции и признак слота, созданного ботом.
  4. ПодтверждениеИзменение и удаление требуют явного подтверждения.
  5. XML-RPC → Odoo 18Технический пользователь выполняет read, create, write или unlink.
  6. ОтветРезультат или отказ в доступе возвращается пользователю.
Операционный сценарий: прикладная авторизация, ограничение объекта и подтверждение выполняются до изменения данных Planning.

Подробнее: планирование загрузки через Telegram в Atkinternal.

Безопасность операций записи

В Atkinternal бот мог редактировать и удалять только записи planning.slot с признаком x_is_telegram_bot=True. Прикладной слой проверял разрешённость операции для сопоставленного пользователя, а изменение и удаление требовали подтверждения до write или unlink. При отказе пользователь получал соответствующее сообщение.

Встроенная безопасность Odoo

Odoo проверяет права доступа и record rules для пользователя, под которым выполняется ORM-операция. В Atkinternal таким пользователем для XML-RPC был технический пользователь бота. Сопоставление Telegram ID с пользователем Odoo относилось к отдельному прикладному уровню авторизации и не означает автоматического применения ACL связанного пользователя.

Рекомендация автора

Для бота с записью разделяйте как минимум четыре решения: кто пользователь Telegram, с каким пользователем Odoo он связан, какие объекты ему доступны и какое действие требует подтверждения. Один список разрешённых Telegram ID не выражает права на конкретные записи ERP.

Что не стоит переносить в Telegram автоматически

Telegram удобен для короткого выбора, уведомления, просмотра компактного отчёта и ограниченной операции. Сложные формы, массовое редактирование, сравнение документов и сценарии с большим числом связанных объектов обычно понятнее оставить в Odoo. Это инженерная рекомендация, а не ограничение Telegram или Odoo.

Документация Telegram отдельно указывает, что серверная часть должна проверять валидность команды и авторизацию пользователя независимо от команд, показанных в интерфейсе. Видимость кнопки или команды не является контролем доступа.

Источники

  1. Odoo 18: External API — аутентификация и вызовы моделей через XML-RPC.
  2. Odoo 18: Restrict access to data — права доступа, record rules и ORM-операции.
  3. Telegram Bot API — официальный API и идентификаторы пользователей Telegram.
  4. Telegram Bot Features — команды, области видимости интерфейса и авторизация на серверной стороне.
  5. Кейс Buildflow Telegram — публичный контур отчётности и результат.
  6. Кейс Atkinternal — операции Planning и интерфейсные сценарии.

Нужен Telegram-интерфейс к Odoo?

Сначала определим контур чтения и записи, сопоставление пользователей и ограничения операций.

Обсудить сценарий