- Добавлен сервис CrmMySQLService для прямого подключения к MySQL CRM
- Обновлён метод get_draft() для получения cf_2624 напрямую из БД
- Реализована блокировка полей (readonly) при contact_data_confirmed = true
- Добавлен выбор банка для СБП выплат с динамической загрузкой из API
- Обновлена документация по работе с cf_2624 и MySQL
- Добавлен network_mode: host в docker-compose для доступа к MySQL
- Обновлены компоненты формы для поддержки блокировки полей
- Исправлена потеря документов при обновлении черновика (SQL объединяет вместо перезаписи)
- Исправлено определение типа документа (приоритет field_label над field_name)
- Исправлены дубликаты в documents_meta и documents_uploaded
- Добавлена передача group_index с фронтенда для правильного field_name
- Исправлены все документы в таблице clpr_claim_documents с правильными field_name
- Обновлены SQL запросы: claimsave и claimsave_final для нового флоу
- Добавлена поддержка multi-file upload для одного документа
- Исправлены дубликаты в списке загруженных документов на фронтенде
Файлы:
- SQL: SQL_CLAIMSAVE_FIXED_NEW_FLOW.sql, SQL_CLAIMSAVE_FINAL_FIXED_NEW_FLOW_WITH_UPLOADED.sql
- n8n: N8N_CODE_PROCESS_UPLOADED_FILES_FIXED.js (поддержка group_index)
- Backend: documents.py (передача group_index в n8n)
- Frontend: StepWizardPlan.tsx (передача group_index, исправление дубликатов)
- Скрипты: fix_claim_documents_field_names.py, fix_documents_meta_duplicates.py
Результат: документы больше не теряются, имеют правильные типы и field_name
Added:
- Detailed logging for /api/v1/claims/description endpoint
- Full event data logging for debugging
- Documentation for n8n workflow setup (N8N_DESCRIPTION_WORKFLOW.md)
The issue: Form hangs on recommendations step because n8n doesn't process description events.
Flow:
1. Frontend sends description to /api/v1/claims/description
2. Backend publishes to Redis channel ticket_form:description
3. Frontend subscribes to SSE /api/v1/events/{session_id} (listens to ocr_events:{session_id})
4. n8n must:
- Subscribe to ticket_form:description channel
- Process description and generate wizard_plan
- Publish wizard_plan back to ocr_events:{session_id} channel
Files:
- backend/app/api/claims.py (enhanced logging)
- docs/N8N_DESCRIPTION_WORKFLOW.md (new documentation)
Added filtering to exclude approved/confirmed forms from drafts list:
- Updated /drafts/list endpoint to filter out forms with status_code='approved' or is_confirmed=true
- Created SQL script for n8n to mark forms as approved after processing Redis channel data
- Forms marked as approved will no longer appear in drafts list
SQL script: SQL_MARK_FORM_APPROVED.sql
- Updates status_code to 'approved'
- Sets is_confirmed = true
- Uses claim_lookup CTE to find claim by id or payload->>'claim_id'
Files:
- backend/app/api/claims.py (updated drafts list queries)
- docs/SQL_MARK_FORM_APPROVED.sql (new SQL script for n8n)
SMS code is now successfully included in the Redis event data:
- Frontend sends SMS code in payload to backend
- Backend extracts SMS code from request body
- Backend includes SMS code in event_data before publishing to Redis
- Added comprehensive logging for debugging
The issue was that backend Docker image needed to be rebuilt after code changes.
Files:
- backend/app/api/claims.py (added detailed logging)
- frontend/src/components/form/StepClaimConfirmation.tsx (SMS code validation)
Added comprehensive logging to track SMS code:
- Log all keys in request body
- Log SMS code presence and value
- Log extracted SMS code before adding to event_data
- This will help identify why SMS code might not appear in Redis
Files:
- backend/app/api/claims.py
Added SMS code to form approval data:
- Frontend: Pass SMS code to saveFormData function
- Frontend: Include sms_code in payload sent to backend
- Backend: Include sms_code in Redis event data
This allows n8n workflow to access the verified SMS code for logging/audit purposes.
Files:
- frontend/src/components/form/StepClaimConfirmation.tsx
- backend/app/api/claims.py
Fixed route conflict:
- Moved POST /approve route BEFORE GET /{claim_id}
- FastAPI processes routes in order, so specific routes must come before parameterized ones
- This fixes 405 Method Not Allowed error
Files:
- backend/app/api/claims.py
Changed from dynamic channel form_approve:{claim_id} to fixed channel:
- Channel: clientright:webform:approve
- Simpler n8n subscription (no need for dynamic channel name)
- All form approvals go to the same channel
Files:
- backend/app/api/claims.py
- frontend/src/components/form/StepClaimConfirmation.tsx
- docs/REDIS_FORM_APPROVE.md
Simplified approach:
- Removed backend endpoint /approve (will use direct webhook)
- Updated saveFormData to send data directly to n8n webhook
- Fire-and-forget approach: no waiting for response
- Show success message 'Ваше заявление отправлено!' after SMS verification
- Uses webhook URL: https://n8n.clientright.pro/webhook/eebe58d4-0bcd-4d09-9d62-39868b110960
Flow:
1. User confirms form → SMS modal appears
2. SMS code sent automatically
3. User enters code → verified
4. Data sent to webhook (fire-and-forget)
5. Success message shown
6. Navigate to next step
Files:
- frontend/src/components/form/StepClaimConfirmation.tsx
- backend/app/api/claims.py (removed /approve endpoint)
Problem:
- Multiple records exist with same claim_id in DB
- One record (ID: 0eb051ec...) has send_to_form_approve.draft (updated: 2025-11-24)
- Another record (ID: b532b1b3...) doesn't have send_to_form_approve (updated: 2025-11-21)
- API query used LIMIT 1 without ORDER BY, could return wrong record
- Form was empty because wrong record (without send_to_form_approve) was returned
Solution:
- Added ORDER BY updated_at DESC to get latest record first
- This ensures we always get the record with send_to_form_approve.draft
- Latest record has correct data structure for confirmation form
Files:
- backend/app/api/claims.py: Added ORDER BY updated_at DESC
- Добавлены логи в frontend (ClaimForm.tsx) для отслеживания unified_id и запросов к API
- Добавлены логи в backend (claims.py) для отладки SQL запросов
- Создан лог сессии с описанием проблемы и текущего состояния
- Проблема: API возвращает 0 черновиков, хотя в БД есть данные
