Pipeline: default stage does not auto-assign new conversations

[DavidsonGomes]

Source

QA session from 2026-04-18 Meet — timestamp 3:23.

Summary

Setting a pipeline as the default pipeline should make every new conversation land automatically in its leftmost/first stage (Chatwoot-style). Today, the conversation is created but no stage is assigned — every card has to be dragged manually, which defeats the purpose of the CRM.

Davidson confirmed: "essa parte do default é algo que já era para funcionar, isso já funcionava, foi feito para isso nessa parte."

Steps to reproduce

1. Configure a pipeline, mark it as default, set type support.
2. Create 4 stages (e.g., Não atendidos / Em atendimento / Aguardando / Cancelado).
3. Receive a new WhatsApp message → a new conversation is created.
4. Observe the Pipeline view: conversation is NOT in any stage.

Expected

New open conversations land on the first stage of the default pipeline automatically.

Acceptance criteria

• New conversation with status open → appears on leftmost stage of the default pipeline.
• Regression test covering new conversation creation → pipeline stage assignment.
• Document whether 'default' applies per account or globally (currently ambiguous in UI).

[DavidsonGomes]

Tracked on Linear: EVO-975 (project: Evo CRM Community).

[DavidsonGomes]

Tracked on Linear: EVO-975 (project: Evo CRM Community).

[marcelogorutuba]

PR relacionada: #72

[marcelogorutuba]

✅ Corrigido — resumo completo da demanda

Causa raiz

O AssociationNotFoundError era gerado em dois lugares distintos ao tentar carregar :account em eager loads onde essa associação não existe no modelo:

1. fetch_pipeline (pipelines) — impedia Pipeline.default.first de retornar qualquer pipeline, então nenhuma conversa nova recebia stage.
2. fetch_message_associations (messages controller) — mesma falha ao carregar mensagens de conversas.

---

O que foi corrigido

evo-ai-crm-community

• fix(EVO-975) — remove :account do eager loading em fetch_pipeline (commit 535cd76)
• fix(EVO-975) complementar — remove :account do eager loading em messages_controller#fetch_message_associations (commit 26d86c7) — este fix estava no working directory sem commit desde a correção original
• EvoAuthService: retry automático em conexões HTTP persistentes stale (reset_persistent_client!)
• Novo endpoint GET /evolution/health para verificar conectividade com Evolution API
• Attachment#download_url: adiciona expires_in: 1.week para evitar URLs pré-assinadas expiradas

evo-auth-service-community

• Backend completo do onboarding survey: geração de survey_token via Redis (TTL 10 min), endpoint POST /setup/survey, associações user_tours e setup_survey_response no modelo User
• Serializers: expõe setup_survey_completed e avatar_url no payload do usuário
• CORS: permite todos os origins em /rails/active_storage/* (blobs de mídia pública)
• avatarable.rb: expires_in: 1.week no blob.url para cloud storage

evo-ai-frontend-community

• Profile.tsx: substitui strings hardcoded por chaves i18n (audio.saveError, notifications.browserPermission.notSupported)
• Adiciona labels de notificação SLA (sla_missed_first_response, sla_missed_next_response, sla_missed_resolution)
• i18n/config.ts: registra locale setup para pt, es, fr, it

evo-ai-processor-community

• run_seeders.py: corrige NameError — args era referenciado antes de ser parseado no add_argument

Root repo

• Bump de todos os 7 submodules para os commits mais recentes

---

Por que estava incompleto

A branch fix/auth-storage-permissions acumulou trabalho de múltiplas issues sem disciplina de escopo — o fix complementar da EVO-975 (messages_controller) e diversas outras correções ficaram no working directory dos submodules sem nunca serem commitadas. Nenhum submodule havia sido bumped no root repo desde b51ca2d (27/abr).

PR: #72