Problem:
- Data already exists in DB in propertyName format at payload.send_to_form_approve.draft
- We were trying to convert from wizard_answers instead of using existing data
- Form was empty because we ignored the correct data structure
Solution:
1. Added priority check for payload.send_to_form_approve.draft:
- If exists, use it directly (PRIORITY 1)
- If not, fall back to conversion from wizard_answers (PRIORITY 2)
2. Direct usage of send_to_form_approve.draft:
- Extract propertyName structure directly from draft
- Preserve all fields: applicant, case, contract_or_service, offenders, claim, meta, attachments
- Use unified_id from draft.meta or fallback to claim/formData
3. Enhanced logging:
- Logs if send_to_form_approve.draft found
- Logs draft data structure
- Logs result structure
Files:
- frontend/src/pages/ClaimForm.tsx: Use send_to_form_approve.draft directly
Problem:
- Data comes from DB in wizard_answers format (answers to wizard questions)
- Form confirmation expects propertyName format (structured data)
- transformDraftToClaimPlanFormat tried to extract propertyName from DB, but it doesn't exist
- Form shows empty because propertyName structure is empty
Solution:
1. Added complete field mapping from wizard_answers to propertyName:
- answersParsed.item → contract_or_service.subject
- answersParsed.price → contract_or_service.amount_paid (normalized)
- answersParsed.place_date → contract_or_service.agreement_date
- answersParsed.cancel_date → contract_or_service.period_start
- answersParsed.steps_taken → claim.description
- answersParsed.expectation → claim.reason
- payload.problem_description → claim.description and contract.subject
2. Added applicant data extraction:
- phone from claim.phone, payload.phone, body.phone, or formData.phone
- email from claim.email, payload.email, body.email, or formData.email
- Other applicant fields (FIO, birth_date, INN) will be filled in confirmation form
3. Added default values:
- case.category = 'consumer'
- case.direction = 'web_form'
4. Enhanced logging:
- Logs what data exists in DB
- Logs wizard_answers keys
- Logs conversion process
Files:
- frontend/src/pages/ClaimForm.tsx: Complete wizard_answers conversion
Problem:
- Data comes from DB in wizard_answers format (answers to wizard questions)
- Form confirmation expects propertyName format (structured data: applicant, case, contract_or_service)
- transformDraftToClaimPlanFormat tried to extract propertyName data from DB, but it doesn't exist there
- Form shows empty because propertyName structure is empty
Solution:
1. Added wizard_answers parsing from multiple sources:
- body.answers, payload.answers
- body.wizard_answers, payload.wizard_answers
2. Added basic field mapping from wizard_answers to propertyName:
- answersParsed.item → contract_or_service.subject
- answersParsed.price → contract_or_service.amount_paid
- answersParsed.place_date → contract_or_service.agreement_date
- answersParsed.steps_taken → claim.description
3. Added logging to debug data flow:
- Logs what data exists in DB
- Logs wizard_answers parsing
- Logs conversion process
Note: This is a basic mapping. Full conversion requires complete field mapping from wizard_answers to propertyName structure.
Files:
- frontend/src/pages/ClaimForm.tsx: Added wizard_answers conversion
Problem:
- Line 77 tried to access formData.case.meta
- formData structure changed to propertyName format
- formData.case doesn't exist, causing runtime error
- Form shows blank screen due to crash
Solution:
- Removed incorrect formData.case.meta access
- Added proper logging for formData and propertyName structure
- Form should now render correctly
Files:
- frontend/src/components/form/StepClaimConfirmation.tsx: Fixed formData access
Problem:
- When data comes as { propertyName: {...}, ... }, dataCandidate was set to propertyName object
- normalizeData expects { propertyName: {...} } format, not just propertyName
- Data normalization failed because structure didn't match
Solution:
- Changed logic to use entire injected object when propertyName exists
- This ensures normalizeData receives correct structure
- Data should now normalize correctly and populate form fields
Files:
- frontend/src/components/form/generateConfirmationFormHTML.ts: Fixed data extraction logic
Problem:
- Data was being passed in normalized 'case' format
- generateConfirmationFormHTML expects propertyName format for normalization
- Form fields were empty because normalization didn't work correctly
Solution:
- Changed StepClaimConfirmation to pass data in propertyName format
- This matches the structure expected by normalizeData function
- Function can now properly normalize data from propertyName to case format
- All fields should now populate correctly
Files:
- frontend/src/components/form/StepClaimConfirmation.tsx: Changed data format to propertyName
Problem:
- Form iframe was too small (800px fixed height)
- Only spinner visible, form content not fully visible
Solution:
1. Increased iframe container:
- Changed Card bodyStyle to use calc(100vh - 200px)
- Set minHeight to 800px
- Made iframe flex: 1 to fill available space
2. Added auto-resize functionality:
- Form sends iframe_resize messages with height
- Parent component listens and adjusts iframe height
- ResizeObserver watches for content changes
- Window resize handler updates iframe size
3. Improved iframe styling:
- Added sandbox attributes for security
- Made height responsive (100% of container)
- Minimum height ensures form is always visible
Files:
- frontend/src/components/form/StepClaimConfirmation.tsx: Increased iframe size, added resize handler
- frontend/src/components/form/generateConfirmationFormHTML.ts: Added auto-resize messaging
Problem:
- caseObj was declared twice: once at line 6 and again at line 270
- Caused esbuild compilation error
Solution:
- Removed first declaration at line 6
- Updated smsInputData extraction to handle multiple data formats
- caseObj is now only declared after normalization at line 270
Files:
- frontend/src/components/form/generateConfirmationFormHTML.ts: Fixed duplicate declaration
Problem:
- Form didn't handle data in propertyName format from n8n
- Missing normalization logic from n8n Code node
Solution:
1. Added normalizeData function in TypeScript:
- Handles propertyName format (new format from n8n)
- Handles old format (applicant, case, contract_or_service)
- Handles case format (current structure)
- Converts field names (first_name -> firstname, etc.)
- Normalizes money values
- Extracts attachments_names
2. Added normalizeData function in JavaScript:
- Same logic as TypeScript version
- Handles data extraction from multiple sources:
* propertyName (object or string)
* value
* data
* output
* case
- Supports array format (takes first element)
3. Enhanced data extraction logic:
- Checks multiple data sources
- Handles both array and object formats
- Merges SMS meta data from injected
- Ensures base structures exist
Files:
- frontend/src/components/form/generateConfirmationFormHTML.ts: Added normalization logic
Problem:
- Form was simplified and didn't match n8n implementation
- Missing validation, button state updates, checkbox handling
- Missing full statement text with consent checkbox
Solution:
1. Added complete renderStatement function:
- Возмещение section with SBP phone display
- Full ЗАЯВЛЕНИЕ text with all fields inline
- Period fields (startdate/finishdate)
- Full offender fields (email, phone, website)
- Consent checkbox for privacy policy
- Attachments list display
2. Added validation functions:
- validateAllFields - checks all required fields
- updateSubmitButton - updates button state based on consent and validation
- Field validation helpers (isValidPhone, isValidEmail, isValidINN, etc.)
3. Enhanced attachBindings:
- Date field conversion (YYYY-MM-DD <-> DD.MM.YYYY)
- Money field comma to dot replacement
- INN field filtering (numeric only, length limits)
- Checkbox handling for privacy consent
- Phone display update in SBP section
4. Added checkbox styles and createCheckbox function:
- Custom checkbox styling matching n8n
- Required checkbox error states
- Proper label and link styling
5. Improved initialization:
- Better error handling
- Field validation on load
- Delegated INN filtering
- Proper state initialization
Files:
- frontend/src/components/form/generateConfirmationFormHTML.ts: Complete form implementation
Problem:
- Function was trying to normalize already normalized data
- Used undefined 'raw' variable after refactoring
- Data structure mismatch causing form not to render
Solution:
1. Removed redundant normalization logic:
- Data is already normalized in StepClaimConfirmation component
- Use caseObj directly from data.case
- Only ensure base structures exist (user, project, offenders, meta, attachments)
2. Fixed undefined variable:
- Changed raw.token to data.token
- Removed unused normalization code
3. Simplified data flow:
- Input: data.case (already normalized)
- Output: caseJson with same structure
- JavaScript in HTML uses injected.case directly
Files:
- frontend/src/components/form/generateConfirmationFormHTML.ts: Simplified normalization
Problem:
- User wants to use the provided n8n Code node structure for generating confirmation form HTML
- Current implementation doesn't match the expected structure
Solution:
1. Created separate file generateConfirmationFormHTML.ts:
- Implements data normalization from propertyName format
- Uses provided HTML template structure
- Includes field creation functions (createField, createDateField, etc.)
- Implements form rendering with editable inline fields
- Handles form data binding and submission via postMessage
2. Updated StepClaimConfirmation component:
- Imports generateConfirmationFormHTML from separate file
- Removed old inline HTML generation function
- Uses new structure-based generation
3. Data normalization:
- Transforms propertyName structure to form structure
- Maps applicant fields: first_name -> firstname
- Maps contract_or_service fields to project
- Maps claim fields to project (description, reason)
- Handles attachments and offenders arrays
4. Form features:
- Inline editable fields in statement text
- Date fields with calendar picker
- Money fields with рублей suffix
- Readonly fields for phone and category
- Form data collection and submission
Files:
- frontend/src/components/form/generateConfirmationFormHTML.ts: New file with form generation logic
- frontend/src/components/form/StepClaimConfirmation.tsx: Updated to use new generator
Problem:
- Only placeholder with Claim ID and Unified ID was shown
- No actual form for editing claim data
- User asked when the actual form will appear
Solution:
1. Created full HTML form with editable fields:
- Applicant data (name, birthday, birthplace, INN, address, phone, email)
- Case data (category, subject, date, amount, reason, description)
- Offender data (organization name, address, INN, OGRN, contacts)
- Attachments list (read-only display)
2. Fixed data mapping:
- Transform propertyName structure to form structure
- Map applicant fields: first_name -> firstname, etc.
- Map contract_or_service fields to project
- Map claim fields to project (description, reason)
3. Form features:
- All fields are editable except phone (read-only)
- Category is read-only (set by system)
- Form collects edited values on confirmation
- Sends form data back via postMessage
4. Removed n8n webhook call:
- HTML form is generated locally in React component
- No external dependencies for form generation
Files:
- frontend/src/components/form/StepClaimConfirmation.tsx: Full form implementation
Problem:
- Claim ID and Unified ID showing as 'не указан' in confirmation form
- transformDraftToClaimPlanFormat was returning array instead of object
- StepClaimConfirmation was not correctly extracting IDs from claimPlanData
Solution:
1. Changed transformDraftToClaimPlanFormat return type:
- Changed from array [{ propertyName, ... }] to object { propertyName, ... }
- This matches what StepClaimConfirmation expects
2. Enhanced ID extraction in StepClaimConfirmation:
- Added explicit claimId and unifiedId variables
- Better fallback chain: claimPlanData.claim_id -> propertyName.meta.claim_id
- Same for unified_id
3. Added comprehensive logging:
- Log claimPlanData structure on component mount
- Log extracted IDs before form generation
- Log transformDraftToClaimPlanFormat input/output
- Log claim.unified_id from API response
4. Improved data flow:
- claim.unified_id from API -> transformDraftToClaimPlanFormat -> StepClaimConfirmation
- Fallback to currentFormData.unified_id if claim.unified_id missing
Files:
- frontend/src/pages/ClaimForm.tsx: Changed return type, added logging
- frontend/src/components/form/StepClaimConfirmation.tsx: Enhanced ID extraction, added logging
Problem:
- problem_description not found in payload, but exists in draft list
- Completeness check fails because hasDescription = false
- Draft not recognized as ready for confirmation
Solution:
1. Enhanced problem_description extraction:
- Checks multiple locations: body.problem_description, payload.problem_description
- Also checks payload.body.problem_description for nested structures
- Added fallback to body.description and payload.description
2. Improved completeness logic:
- If problem_description not found but wizard_plan and answers exist,
infer that description was entered (plan is generated from description)
- This handles cases where description exists but not in expected payload location
3. Better logging:
- Shows if problem_description was found directly or inferred
- Logs all payload keys for debugging
Logic:
- hasDescription = !!problemDescription || (!!wizardPlan && !!answers)
- If plan and answers exist → description was entered earlier
- This allows drafts with plan+answers+documents to proceed to confirmation
Files:
- frontend/src/pages/ClaimForm.tsx: Enhanced problem_description detection
Problem:
- When draft is fully filled, we subscribed to Redis SSE channel claim:plan
- But all data already exists in PostgreSQL database
- No need to wait for n8n to publish data - we can load it directly
Solution:
1. Removed subscribeToClaimPlanForDraft() function
- No longer subscribes to SSE channel for drafts
- Removed EventSource cleanup code
2. Added transformDraftToClaimPlanFormat() function
- Transforms draft data from DB format to propertyName format
- Extracts data from payload/body (telegram/web_form formats)
- Maps documents_meta to attachments array
- Formats applicant, case, contract_or_service, offenders, claim, meta
- Returns data in array format expected by confirmation form
3. Updated loadDraft() logic:
- When draft is ready for confirmation (all steps filled + draft status)
- Calls transformDraftToClaimPlanFormat() instead of subscribing to SSE
- Immediately shows confirmation form with data from DB
Flow:
1. User selects fully filled draft
2. System checks completeness (description, plan, answers, documents)
3. If ready → transforms DB data to propertyName format
4. Shows confirmation form immediately (no SSE wait)
Benefits:
- ✅ Faster: no waiting for n8n to publish data
- ✅ More reliable: data always available from DB
- ✅ Simpler: no SSE connection management for drafts
- ✅ Works offline: doesn't depend on Redis pub/sub
Files:
- frontend/src/pages/ClaimForm.tsx: Added transform function, removed SSE subscription
Problem:
- When user selects a draft with all steps filled (description, plan, answers, documents)
- But claim status is still 'draft' (not submitted)
- User has to manually navigate through all steps again
Solution:
1. Added check in loadDraft() to detect fully filled drafts:
- hasDescription: problem_description exists
- hasWizardPlan: wizard_plan exists
- hasAnswers: answers exist and not empty
- hasDocuments: documents_meta array has items
- isDraft: status_code === 'draft'
- allStepsFilled: all checks pass
2. When draft is ready for confirmation:
- Automatically subscribe to claim:plan SSE channel
- Wait for claim data from n8n
- Show loading message while waiting
- On success: show confirmation form automatically
3. Added subscribeToClaimPlanForDraft() function:
- Subscribes to /api/v1/claim-plan/{session_token}
- Handles claim_plan_ready event
- Updates formData with claimPlanData
- Auto-navigates to confirmation step via useEffect
4. Added useEffect for auto-navigation:
- Watches formData.showClaimConfirmation and formData.claimPlanData
- When both true, navigates to step 3 (confirmation)
- Handles cleanup of EventSource on unmount
Flow:
1. User selects draft → loadDraft() checks completeness
2. If all filled + draft → subscribeToClaimPlanForDraft()
3. SSE receives data → updates formData
4. useEffect detects → navigates to confirmation step
5. User sees confirmation form immediately
Files:
- frontend/src/pages/ClaimForm.tsx: Added auto-navigation logic
Problem:
- After wizard form submission, need to wait for claim data from n8n
- Claim data comes via Redis channel claim:plan:{session_token}
- Need to display confirmation form with claim data
Solution:
1. Backend: Added SSE endpoint /api/v1/claim-plan/{session_token}
- Subscribes to Redis channel claim:plan:{session_token}
- Streams claim data from n8n to frontend
- Handles timeouts and errors gracefully
2. Frontend: Added subscription to claim:plan channel
- StepWizardPlan: After form submission, subscribes to SSE
- Waits for claim_plan_ready event
- Shows loading message while waiting
- On success: saves claimPlanData and shows confirmation step
3. New component: StepClaimConfirmation
- Displays claim confirmation form in iframe
- Receives claimPlanData from parent
- Generates HTML form (placeholder - should call n8n for real HTML)
- Handles confirmation/cancellation via postMessage
4. ClaimForm: Added conditional step for confirmation
- Shows StepClaimConfirmation when showClaimConfirmation=true
- Step appears after StepWizardPlan
- Only visible when claimPlanData is available
Flow:
1. User fills wizard form → submits
2. Form data sent to n8n via /api/v1/claims/wizard
3. Frontend subscribes to SSE /api/v1/claim-plan/{session_token}
4. n8n processes data → publishes to Redis claim:plan:{session_token}
5. Backend receives → streams to frontend via SSE
6. Frontend receives → shows StepClaimConfirmation
7. User confirms → proceeds to next step
Files:
- backend/app/api/events.py: Added stream_claim_plan endpoint
- frontend/src/components/form/StepWizardPlan.tsx: Added subscribeToClaimPlan
- frontend/src/components/form/StepClaimConfirmation.tsx: New component
- frontend/src/pages/ClaimForm.tsx: Added confirmation step to steps array
Problem:
- When uploading files on Step 3, wizard_plan was reset to NULL
- wizard_plan is created on Step 2 (StepDescription) and saved by claimsave_primary
- form_get workflow on Step 3 doesn't receive wizard_plan again
- Old SQL was overwriting wizard_plan with NULL
Solution:
- Add 'existing_claim' CTE to read current payload from DB
- Modified all parsers to fallback to DB values if field not in incoming payload:
* wizard_plan_parsed - preserves generated wizard plan
* answers_prefill_parsed - preserves AI-generated prefill
* coverage_report_parsed - preserves coverage analysis
* ai_agent1_facts_parsed - preserves fact extraction
* ai_agent13_rag_parsed - preserves RAG analysis
* problem_description_parsed - preserves user description
Flow:
1. Step 2: User describes problem → claimsave_primary saves wizard_plan ✅
2. Step 3: User uploads files → form_get/claimsave preserves wizard_plan from DB ✅
File: docs/SQL_CLAIMSAVE_UPSERT_SIMPLE.sql
Next: Update n8n workflow 'form_get' node 'claimsave' with this SQL
Database changes:
- Add unified_id, contact_id, phone columns to clpr_claims table
- Create indexes for fast lookup by these fields
- Migrate existing data from payload to new columns
- SQL migration: docs/SQL_ALTER_CLPR_CLAIMS_ADD_FIELDS.sql
SQL improvements:
- Simplify claimsave query: remove complex claim_lookup logic
- Use UPSERT (INSERT ON CONFLICT) with known claim_id
- Always return claim (fix NULL issue)
- Store unified_id, contact_id, phone directly in table columns
- SQL: docs/SQL_CLAIMSAVE_UPSERT_SIMPLE.sql
Workflow enhancements:
- Add branch for form submissions WITHOUT files
- Create 6 new nodes: extract, prepare, save, redis, respond
- Separate flow for has_files=false in IF node
- Instructions: docs/N8N_FORM_GET_NO_FILES_INSTRUCTIONS.md
- Node config: docs/N8N_FORM_GET_NO_FILES_BRANCH.json
Migration stats:
- Total claims: 81
- With unified_id: 77
- Migrated from payload: 2
Next steps:
1. Add 6 nodes to n8n workflow form_get (ID: 8ZVMTsuH7Cmw7snw)
2. Connect TRUE branch of IF node to extract_webhook_data_no_files
3. Test form submission without files
4. Verify PostgreSQL save and Redis event
- Добавлены логи в frontend (ClaimForm.tsx) для отслеживания unified_id и запросов к API
- Добавлены логи в backend (claims.py) для отладки SQL запросов
- Создан лог сессии с описанием проблемы и текущего состояния
- Проблема: API возвращает 0 черновиков, хотя в БД есть данные
Изменения в /api/n8n/documents/attach:
✅ Принимает массив документов (не одиночный объект)
✅ Умная обработка S3 путей:
- /bucket/path → https://s3.twcstorage.ru/bucket/path
- bucket/path → https://s3.twcstorage.ru/bucket/path
- https://... → без изменений
✅ Поддержка обоих форматов полей:
- file / file_url
- filename / file_name
✅ Batch-обработка с детальной статистикой
✅ Возвращает результаты для каждого документа отдельно
✅ Логирование успешных и неуспешных операций
Формат ответа:
{
total_processed: N,
successful: M,
failed: K,
results: [...],
errors: [...]
}
Тесты:
- TEST_REAL_DATA.sh - тест с реальными данными из n8n
- TEST_QUICK.sh - быстрые тесты
Документация обновлена с примерами batch-обработки
Изменения:
✅ Новый endpoint: POST /api/n8n/documents/attach
✅ Поддерживает привязку к Project или HelpDesk
✅ Логика: если указан ticket_id → HelpDesk, иначе → Project
✅ Полное логирование всех операций
✅ Интеграция с upload_documents_to_crm.php
Входные данные:
- contact_id (обязательно)
- project_id (обязательно)
- file_url (обязательно)
- file_name (обязательно)
- ticket_id (опционально, для привязки к заявке)
- file_type (опционально, описание документа)
Готово к интеграции в n8n workflow!
Изменения:
✅ Добавлены переменные n8n_create_contact_webhook и n8n_create_claim_webhook в Settings
✅ Все webhook URLs теперь централизованно в .env
✅ Удалён хардкод из n8n_proxy.py
Теперь все N8N webhooks:
- N8N_POLICY_CHECK_WEBHOOK
- N8N_FILE_UPLOAD_WEBHOOK
- N8N_CREATE_CONTACT_WEBHOOK
- N8N_CREATE_CLAIM_WEBHOOK
Проблема:
- Backend не логировал что именно n8n возвращает для /api/n8n/policy/check
- Не видно откуда брать project_id в response
Исправление:
✅ Добавлено логирование response.text[:500] для policy/check
✅ Добавлена обработка ошибок парсинга JSON
Теперь в логах видно полный ответ от n8n!
Проблема:
- Step1Phone делал запрос НАПРЯМУЮ к n8n (палил webhook URL)
- В backend логах не было видно что n8n возвращает для контакта
- Нельзя было отследить contact_id, claim_id, is_new_contact
Решение:
✅ Добавлен endpoint /api/n8n/contact/create в n8n_proxy.py
✅ Step1Phone.tsx теперь использует proxy вместо прямого URL
✅ Backend логирует полный response от n8n (contact_id, claim_id и тд)
Теперь весь трафик к n8n идёт через backend proxy!
Проблема:
- TypeScript игнорировал project_id, is_new_project, ticket_id, ticket_number
- Они не были объявлены в interface FormData
Исправление:
✅ Добавлены в FormData:
- project_id?: string (ID проекта в vTiger)
- is_new_project?: boolean (флаг создания)
- ticket_id?: string (ID заявки HelpDesk)
- ticket_number?: string (номер заявки)
Теперь updateFormData корректно сохраняет все данные от n8n!
Проблема:
- n8n возвращает [{success: true, result: {claim_id, contact_id, ...}}]
- Код пытался взять data.claim_id вместо data.result.claim_id
Исправление:
- ✅ Обработка массива от n8n
- ✅ Извлечение данных из result: const result = crmResult.result || crmResult
- ✅ Улучшенное логирование для отладки
- ✅ Проверка crmResult.success перед обработкой
Теперь formData корректно получает:
- claim_id (от n8n)
- contact_id (от CreateWebContact)
- is_new_contact (флаг)
- ✅ Добавлена обработка массива от n8n (как в Step2EventType)
- ✅ Сохранение project_id, is_new_project в formData
- ✅ Сохранение contact_id для консистентности
- ✅ Работает как для найденного, так и для не найденного полиса
Теперь formData содержит полную информацию:
- claim_id (из n8n)
- contact_id (из CreateWebContact)
- project_id (из CreateWebProject) ← НОВОЕ
- is_new_project (флаг создания) ← НОВОЕ
Подробная документация:
- ✅ CreateWebClaim.php - операция vTiger для заявок
- ✅ n8n workflow get_claim_CRM_ERV (ID: qdYZqhIDGhK9E4DA)
- ✅ Backend proxy /api/n8n/claim/create
- ✅ Frontend интеграция Step2EventType
- ✅ Решенные проблемы: BOM, пустой ответ n8n, массив вместо объекта
- ✅ Полный флоу создания заявки
- ✅ Метрики и статистика
Создано заявок: 8 (последняя ЗАЯВКА_825)
Время работы: 4 часа 15 минут
- ✅ Новый endpoint: POST /api/n8n/claim/create
- ✅ Проксирует запросы к n8n webhook создания заявки
- ✅ Frontend теперь использует /api/n8n/claim/create вместо прямого URL
- ✅ Решает проблему CORS и скрывает webhook URL
- ✅ Логирование запросов и ошибок
- ✅ n8n может вернуть [{success: true, ...}] вместо {success: true, ...}
- ✅ Добавлена проверка Array.isArray и извлечение первого элемента
- ✅ Теперь корректно обрабатывается ответ от webhook создания заявки
- ✅ Вызов n8n webhook после выбора типа события
- ✅ Формирование title из event_type + voucher
- ✅ Передача всех данных: claim_id, contact_id, project_id, event_type
- ✅ Сохранение ticket_id и ticket_number в formData
- ✅ Loading состояние кнопки
- ✅ Debug события для отслеживания
- Step1Phone теперь вызывает n8n webhook после SMS верификации
- Webhook создаёт/находит контакт в CRM через CreateWebContact
- Возвращает: contact_id, claim_id, is_new_contact
- Данные сохраняются в formData для дальнейшей работы
- Исправлена нормализация телефона в sms_service (убираем +)
- Отключен rate limiting SMS для тестирования
- Backend подключён к внешнему Redis (crm.clientright.ru:6379)
- Добавлены поля contact_id, is_new_contact в FormData
- Frontend пересобран с новым кодом
- Перенос телефона на первый шаг с SMS верификацией
- Создана операция CreateWebContact в vTiger CRM
- N8N workflow: контакт + claim_id + Redis session
- Docker-compose: убраны локальные postgres/redis
- Backend подключён к внешним сервисам
- Флаг is_new_contact для UX (новый vs существующий клиент)
- Исправлено 7 проблем (Postgres v16, Redis, N8N webhooks, Gitea)
- Готовность к черновикам и личному кабинету
- docker-compose.yml: убраны локальные postgres/redis, только внешние
- Frontend: телефон в формате 79001234567 (без +)
- Готово к интеграции с n8n webhook для создания контакта в CRM
- CreateWebContact: только создание или возврат ID, БЕЗ обновления
