Интеграции

Поток аутентификации

Ключевая связь — User.supabase_uid = JWT sub. Это единственная привязка между записью в Supabase Auth и записью пользователя в Django.

Роль (User.role) живёт в Django, но дублируется в app_metadata.role в Supabase Auth (через Edge Function set-role) — фронт читает её из JWT, чтобы не дёргать Django ради проверки доступа к маршруту.

Класс SupabaseAuthentication

Лежит в garden/modules/shared/auth/rest.py. Подключается через DEFAULT_AUTHENTICATION_CLASSES в DRF-настройках. Действие на каждый запрос:

1. Достать Authorization: Bearer <jwt>.
2. Проверить подпись JWT публичным ключом Supabase.
3. Проверить exp.
4. Достать sub → найти User.supabase_uid.
5. Если пользователя нет — 401.

Failsafe для авто-создания пользователя (когда auth-sync ещё не успел сработать) реализован в auth-sync Edge Function — Django сам ничего не создаёт по запросу.

Владение базой данных

Schema owner — Django. Все миграции живут в garden/modules/*/migrations/. PostgreSQL запущен в Supabase (это просто контейнер). Когда Django применяет миграцию — таблица появляется в той же БД, к которой ходят и Supabase Auth, и SQLAlchemy-зеркала бота.

Когда нужна новая модель: создать в Django → python manage.py makemigrations && migrate → обновить SQLAlchemy-модели в боте в режиме read-only.

Файловое хранилище

Файлы (фотографии работ, документы) хранятся в Supabase Storage. Это S3-совместимое хранилище.

Два URL-контекста.

Метаданные файла лежат в Django (модель FileAttachment):

• bucket, object_key — где лежит файл в Storage.
• original_filename, content_type, size, checksum_sha256, width, height — метаданные.

URL не хранится — генерируется на лету через FileAttachment.build_presigned_url(expires_seconds=3600). Это даёт короткоживущие подписанные ссылки без раздачи прямого доступа к bucket.

Email через Resend

Платформа использует Resend API (HTTP) как единственного email-провайдера. Письма отправляются из двух мест.

Транзакционные письма (приглашение клиента, сброс пароля, смена email) идут через Edge Function send-email. Шаблоны написаны на React Email (TSX) и лежат в supabase/functions/send-email/templates/.

Бизнес-уведомления (work_started, work_completed, report_*) идут напрямую из Django. Транспорт — EmailBackend в garden/modules/notification/backends/email.py. Шаблоны — MJML, лежат в garden/modules/notification/templates/notification/email/.

Webhook от Resend (POST /api/webhooks/resend/) принимает события доставки (email.sent, email.delivered, email.opened, email.bounced, email.complained) и обновляет статус соответствующего ReportDelivery через DeliveryStatusService.

Telegram → Garden → Telegram

Двусторонняя интеграция реализована через Redis Stream и webhook.

Бот никогда не лезет в Django напрямую — он только читает БД (для зеркальных моделей) и постит webhook о статусе доставки. Решение «куда отправить» принимает Django.

Chatwoot

Chatwoot — внешняя платформа для клиентского обслуживания. Интеграция работает в обе стороны.

Входящие сообщения (клиент → компания):

1. Клиент пишет в Telegram-бот.
2. Бот пересылает сообщение в Chatwoot через его API.
3. Связь «клиент в Telegram ↔ контакт в Chatwoot» хранится в Django: модель ChatwootContact (garden/modules/communication/models.py).

Исходящие ответы (оператор → клиент):

1. Оператор пишет ответ в Chatwoot.
2. Chatwoot отправляет webhook на бот (POST /webhook/chatwoot/...).
3. Бот отправляет сообщение в Telegram.

Webhooks — кто куда

Сводная таблица всех вебхуков, которые Garden принимает или отправляет.