Andrey 7db1a3de88 🚑 fix(calls): show Accept button for incoming audio call + load DS tokens on call page
On the client call page an incoming invite never showed Принять — only
Отменить. resolveAudioCallViewMode returned "ringing" for REQUESTED/RINGING
before start, but ringing renders a single Отменить button. An invite is an
incoming call for the client (the staff initiates it), so it must be incoming
which renders the Принять/Отклонить pair. AudioCallStage now also passes
onDecline, which the incoming PairBar needs.

The call page also missed the design tokens that audio-call.css consumes
(--font-sans, --radius-4xl/pill/lg, --success/--error): web-chat never defined
them, so the audio scene fell back to inherited system font and a 28px radius.
Added the tokens to web-chat styles.css :root straight from the baseline
(typography/effects tokens); no external webfont per ADR-HUB-0013.
2026-07-31 22:39:10 +03:00
2026-06-17 18:14:16 +03:00
2026-06-26 15:10:36 +03:00

CustoCRM

Canonical implementation workspace for hub.edevs.tech.

Local start

Copy-Item .env.example .env
.\scripts\start.ps1

По умолчанию локально запускается облачный режим. Коробочный режим запускается тем же штатным контуром, но с явным признаком поставки:

.\scripts\start.ps1 -Mode Cloud
.\scripts\start.ps1 -Mode SelfHosted

Приложение не определяет режим по домену, числу организаций или данным тарифа. Единственный источник — CUS_DELIVERY_MODE со значением CLOUD или SELF_HOSTED. В production переменная обязательна; шаблон коробочного экземпляра env.example уже содержит SELF_HOSTED.

The local compose stack contains:

  • isolated app, platform, and loopback-only admin Django runtimes;
  • background worker;
  • PostgreSQL;
  • Redis;
  • Internal Hub UI;
  • Web Chat UI;
  • local Nginx reverse proxy.

No production secrets are stored in the repository.

Default local URLs:

  • App gateway: http://app.localhost/
  • Platform health: http://platform.localhost/api/v1/health/live/
  • Django admin (loopback only): http://127.0.0.1:18001/admin/
  • Internal Hub UI (direct Vite): http://localhost:5173
  • Web Chat: http://localhost:5175
  • App API (direct): http://localhost:8010/api/v1

Local accounts (TOTP disabled). These credentials are fixed — do not change them:

  • OWNER — owner@edevs.tech / Owner-Local-2026
  • OPERATOR — a.kotova@edevs.tech / Operator-Local-2026

Bootstrap the organization and both accounts:

docker compose run --rm backend-app python manage.py bootstrap_owner --email owner@edevs.tech --password Owner-Local-2026 --name "Иван Петров"

Optional demo seed

The demo seed is a Django management command (seed_demo) that loads a full fictional dataset for a Russian IIoT vendor company «Северная Верфь» (products «Вектор» and «Репер»): organization with logo, staff with access profiles, product catalog with offers and prices, channels and AI agents, knowledge base with file attachments, conversations, orders, external sales, support contracts and a public help-center portal, calls, and notifications. It is idempotent and never runs during start.ps1, docker compose up, or migrations.

The editable data lives in apps/backend/hub_platform/identity/demo_seed/data/ (one JSON manifest per domain, plus media/ for attachments). The command is baked into the backend image, so the same dataset works for local testing and cloud installation.

Run it only after the local dev stack is running:

.\scripts\seed-demo.ps1

Or directly via management command (dry-run by default, --apply to write):

python manage.py seed_demo --apply

The demo-seed one-shot service is defined only by compose.dev.yaml. Outside DEBUG (e.g. cloud installation) the command requires --force. Production compose has no seed service.

Tests

All suites run in Docker, so no manual environment is required — the test runners auto-detect themselves and relax production hardening (secret-key fail-fast, SSL redirect, throttling) for the duration of the run.

Run everything (backend tests, frontend unit tests, typechecks):

.\scripts\check.ps1

Individual suites:

# Backend (pytest + pytest-django)
docker compose run --rm backend-app pytest

# Frontend unit tests (vitest)
docker compose run --rm frontend npm run test

# End-to-end (Playwright, internal-ui) — auto-starts the dev server
npx playwright install chromium   # one-time
npx playwright test --project=internal-ui

Backend pytest configuration lives in apps/backend/pytest.ini (it must sit next to manage.py so it is also visible inside the backend container).

Languages
Python 54.4%
TypeScript 35.6%
CSS 8.2%
Shell 0.8%
JavaScript 0.6%
Other 0.3%