# Telegram-бот как канал администрирования

Менеджер видит заявки только в Telegram, а на сервере соседствуют чужие боевые сайты, поэтому всё администрирование — настройка тем (`/setup`), ежедневные бэкапы с копией администратору в личку, восстановление базы — делает процесс api через бота, который читает обновления long polling'ом. Ни cron на хосте, ни входящего webhook'а, ни админки: на сервере меняется только наш каталог и один конфиг nginx.

## Considered Options

- Cron на хосте + ручное восстановление по ssh — трогает общий crontab сервера, и восстановление требует доступа по ssh.
- Webhook вместо polling — нужен публичный эндпоинт и секрет, а выигрыша при нашем трафике нет.
- Отдельный скрипт `tg:setup` через `getUpdates` — конфликтует с polling работающего api, заменён командой `/setup`.

## Consequences

- У бота один поток обновлений: никакой другой процесс не должен вызывать `getUpdates` с этим токеном.
- Если Telegram недоступен целиком, о сбоях узнаём только из `docker-compose logs api`.
- Восстановление из копии удаляет заявки, пришедшие после неё; бот перечисляет их в подтверждении и сохраняет текущую базу как `pre-restore`.