Reply Pilot Web App

Tato stranka popisuje modul reply-pilot-app/, ktery po rozdeleni architektury funguje primarne jako frontend/BFF vrstva nad reply-pilot-be.

UX/UI pravidla pro obrazovky, nadpisy, formulare a navigaci jsou v UX/UI Principles.

Co je soucasti

  • Flask aplikace v balicku reply_pilot_app/
  • HTTP klient pro reply-pilot-be
  • HTTP klient pro reply-pilot-search
  • dashboard s kalendarem, filtry a draft formularem
  • search stranka nad party/activity fulltextem
  • signpost prehledy pro firmy, osoby, emaily a tasky
  • rucni zalozeni samotne firmy
  • sprava typed AI promptu pro email reply a import wizard workflow
  • GET /healthz pro monitoring
  • Docker image a Compose runtime s non-root uzivatelem

Runtime

  • aplikace bezi v kontejneru jako non-root uzivatel
  • runtime UID:GID se do Compose predava pres HOST_UID a HOST_GID
  • lokalni mounty jsou data -> /app/data, logs -> /app/logs, reply-pilot-app/conf -> /app/conf
  • aplikace se na backend napojuje pres sdilenou Docker sit reply-pilot-internal
  • hlavni runtime zavislost je BACKEND_API_BASE_URL, defaultne http://reply-pilot-be:5000
  • footer pouzije DOCUMENTATION_URL jako explicitni override; bez nej na localhost a 127.0.0.1 odkazuje na lokalni docs :9095, jinak na https://reply-pilot-docs.mathbox.90.cz
  • fulltext vola pres SEARCH_API_BASE_URL, defaultne http://reply-pilot-search:5000
  • mount conf/ zustava read-only
  • aktivni log se lokalne zapisuje do reply-pilot-app/logs/reply-pilot-app.log
  • image modulu se jmenuje reply-pilot-app:latest
  • operacni skripty jsou app-start.sh, app-stop.sh, app-deploy.sh

Konfigurace

Hlavni konfigurace je pres promenne prostredi:

  • APP_PORT
  • BACKEND_API_BASE_URL
  • BACKEND_TIMEOUT_SECONDS
  • SEARCH_API_BASE_URL
  • SEARCH_TIMEOUT_SECONDS
  • DOCUMENTATION_URL
  • APP_DATA_DIR
  • HOST_HTTP_PORT
  • APP_TIMEZONE
  • FLASK_SECRET_KEY
  • REPLY_PILOT_DB_URL
  • EMAILS_DATA_FILE
  • LOG_FILE
  • LOG_LEVEL
  • MAX_EMAILS
  • HOST_UID
  • HOST_GID

Zdroj dat

Ve standardnim runtime si appka taha inbox, detail threadu, sync i draft akce z reply-pilot-be.

Manualni vytvoreni tasku z e-mailoveho vlakna zustava z pohledu UI stejne: formular, vyber firmy, vyber assignee a AI draft pripravuje appka. Pokud je nastavene BACKEND_API_BASE_URL, samotne zalozeni Email Thread Reply tasku probiha pres backend endpoint POST /api/email-threads/<email_id>/reply-tasks. Backend pak vytvori Jira issue i lokalni task_jira_email_thread_reply vazbu a pri duplicate odpovedi vraci existujici task, na ktery appka presmeruje.

Rucni zalozeni firmy probiha z odkazu Nova spolecnost na rozcestniku. Appka zobrazi jednopage formular pro samotnou spolecnost a pri ulozeni vola backend endpoint POST /api/companies. Pri lokalni validaci se chyby ukazuji primo u konkretnich poli; pri duplicitach backend vraci kandidaty a appka zustava na formulari.

Fulltext si appka taha z reply-pilot-search, ktery vraci vysledky s linkem na detail firmy, osoby, emailu nebo obecne aktivity.

Pokud je zapnute SIMPLE_AUTH_ENABLED, app navic zapisuje pouzite rp_nonce do reply-pilot-db, aby replay protection nebyla lokalni ani file-based.

Ve stejne DB si app uklada typed AI prompty do tabulek public.ai_prompt_type a public.ai_prompt. Reply workflow filtruje typ EMAIL_REPLAY, lead import wizard filtruje typ IMPORT_WIZARD.

Legacy fallback lokalniho rezimu je zachovany kvuli testum a postupne migraci:

  • BACKEND_API_BASE_URL prazdne -> app bezi jako puvodni all-in-one lokalni rezim
  • BACKEND_API_BASE_URL nastavene -> app vola backend a sama nepracuje primo s Gmail/OpenAI
  • u vytvareni Email Thread Reply tasku zustava lokalni Jira+DB cesta jen jako legacy fallback bez backend URL

Endpointy

  • / dashboard
  • /search fulltext nad emaily, party a activity modely
  • /companies/new rucni zalozeni firmy pres backend API
  • /companies/<party_id> detail firmy z party modelu
  • /companies/<party_id>/contacts/new pridani kontaktu firmy pres backend API
  • /companies/<party_id>/contacts/<contact_mech_id>/edit uprava vazby kontaktu firmy
  • /companies/<party_id>/contacts/<contact_mech_id>/remove potvrzeni odebrani kontaktu firmy
  • /companies/<party_id>/identifiers/new pridani identifikace firmy
  • /companies/<party_id>/identifiers/<identifier_id>/remove potvrzeni odebrani identifikace firmy
  • /companies/<company_id>/people/<person_id>/remove potvrzeni odebrani vazby osoby na firmu
  • /people/new rucni zalozeni osoby, volitelne s company_id
  • /people/<party_id> detail osoby z party modelu
  • /people/<party_id>/edit editace identity osoby
  • /people/<party_id>/contacts/new pridani kontaktu osoby
  • /people/<party_id>/contacts/<contact_mech_id>/edit uprava vazby kontaktu osoby
  • /people/<party_id>/contacts/<contact_mech_id>/remove potvrzeni odebrani kontaktu osoby
  • /emails/<activity_id> detail emailu z activity modelu
  • /activities/<activity_id> detail ne-emailove aktivity
  • /tasks prehled JIRA tasku
  • /tasks/<task_id> detail tasku s navazanymi emailovymi vlakny
  • /ai-prompty CRUD sprava typed promptu s filtrem podle workflow typu
  • /api/emails JSON vystup pro dalsi integrace
  • /healthz health endpoint
  • /drafts placeholder POST endpoint pro dalsi navazujici logiku

Party CRUD UI

Detail firmy je pracovni prehled se sekcemi Identita, Identifikace, Kontakty firmy, Osoby a E-mailova vlakna. Editovatelne sekce maji radkove akce, ale samotne formulare jsou samostatne stranky ve stylu CTA form.

Detail osoby pouziva stejne objektove schema jako firma: H1 je jmeno osoby a H2 je Osoba - Prehled, Osoba - Aktivity nebo Osoba - Editovat. Prehled osoby obsahuje Identita, Kontakty osoby a Spolecnosti. Aktivity osoby i firmy pouzivaji timeline layout.

Appka nove mutace osob, kontaktu, identifikaci a vazeb neposila primo do DB, ale vola backend REST API. Po uspesne mutaci presmeruje zpet na relevantni detail. Odebrani kontaktu, identifikace nebo vazby osoby na firmu vzdy vede pres potvrzovaci stranku; GET nic nemeni.