Repository navigation
release: corte da v1.1.0 — develop para main (24 commits) - #186
Merged
Merged
Conversation
- evo-ai-crm-community: ad7523c → 9fd4e84 - evo-ai-processor-community: 5769ec6 → 2b5a22b - evo-auth-service-community: 2d9884f → f92f1d8 - evo-bot-runtime: 040a486 → d9f8816 - evolution-api: dd552c7 → e273b904
…es-develop chore(submodules): bump 5 services to develop HEAD
The bot runtime validates the host of an incoming attachment before fetching it, and reads the authorized hosts from MEDIA_HOST_ALLOWLIST only — an allowlist taken from the event would be chosen by whoever sent the event. Unset means no attachment is fetched, so the variable has to travel with the service or media silently stops reaching the agent. Set it to the host that signs the attachment URLs: ACTIVE_STORAGE_URL when present, otherwise BACKEND_URL. Add the storage host as well when ActiveStorage runs in redirect mode (presigned S3/MinIO links), or the CDN host when one fronts the CRM. Wired into docker-compose.yml, docker-compose.swarm.yaml, internal/review/docker-compose.yml and both env examples. The swarm file leaves it blank next to the instructions, like the other per-deployment values there.
…host-allowlist-env chore(EVO-2178): ship MEDIA_HOST_ALLOWLIST on every deploy surface
…ole exists (installation owner) (CRM-180) The Design principles section claimed "No super-admin" and a role hierarchy of account_owner + agent only. But evo-auth-service-community db/seeds/rbac.rb creates the super_admin role (all valid permissions + installation_configs.manage; exactly one user, the setup-wizard installation owner). Aligns the doc to the code. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Review follow-up. The previous commit removed the false "No super-admin" claim but left two others standing, and added a third: - "no intermediate roles" stayed on the rewritten line. account_owner holds roles.create and roles.bulk_update_permissions (resource_actions_config.rb:68-79), routed at config/routes.rb:156-164, so custom roles are creatable at runtime via POST /api/v1/roles. apply_role_filters even lists them. - "a single super_admin" / "exactly one user" is an intention, not an invariant. SetupBootstrapService#assign_global_role grants it to the bootstrap user and PromoteFirstUserToSuperAdmin grants it to the oldest user of an existing install, but UserRole only validates uniqueness of (user_id, role_id). Asserting one holder is the same false comfort that hid five super_admins from a customer audit. - Role::ADMIN_ROLE_KEYS was cited as "the authoritative role model" and attributed to evo-auth-service-community. It lives in evo-ai-crm-community/app/models/role.rb, it is an admin-bypass allowlist rather than a role model, it reads %w[super_admin account_owner administrator admin] (not the pair the previous commit message claimed), it names legacy keys the seed never creates, and the auth/CRM/ frontend copies disagree on whether "admin" belongs. Replaces the bullets with a Roles subsection: the three seeded roles and their scope, the two facts the code does not enforce, and db/seeds/rbac.rb as the single authoritative source. Doc only — no test.
…admin-monorepo-readme docs(readme): correct "no super-admin" in the monorepo README (CRM-180)
…TION_KEY 45 merges since the last pointer bump (2026-07-17): visibility/security fixes (CRM-195, CRM-205, ActionCable inbox scope, pipeline-items update gate), macros/templates/teams management (CRM-70), contact notes (CRM-177), labels refactor (CRM-172/184), Baileys provider removal, the AI-credential chain (EVO-2250/CRM-187) and dead-code cleanups (CRM-179/CRM-200). Three migrations apply on boot (pipeline_teams, capture-form indexes, agent_bots.credential_id). The AI-credential chain reads EVO_AI_ENCRYPTION_KEY — the same Fernet key core/processor already consume as ENCRYPTION_KEY — and refuses to store credentials without it. Wire it into the CRM services in all three composes and document it in both env templates.
… heads auth +67 (RBAC least-privilege wave CRM-163/178/181/182/190/194, CRM-70, CRM-166; nine permission migrations apply on boot), core +50 (AI/integration credentials CRM-186/191, EVO-2250 key hint, MCP test endpoints; SQL migrations 000016-000020), frontend +223 (develop line with the front halves of CRM-70/164/166/174/178/187/213 — was pinned to the main head), flow +15 (CRM-209, CRM-60, EVO-2203; no new env — EVOAI_CRM_BASE_URL/TOKEN already wired here), processor +13 (EVO-2250 vault, EVO-2178 mime guard) and bot-runtime +8 (EVO-2178 allowlist/SSRF, EVO-2180). evo-nexus, evolution-api and evolution-go already sit on their develop heads. All six heads CI-green, image publishes included.
…unity-develop chore: bump all submodules to their develop heads + wire EVO_AI_ENCRYPTION_KEY
…efault (CRM-236) (#175) * fix(compose): stop pinning AI_CALL_TIMEOUT_SECONDS=30 over the code default (CRM-236) The bot-runtime fix raised the default ceiling from 30s to 90s, but every shipped compose file set the env var to 30 explicitly — which overrides the default and reproduces the original incident on any real stack. The code fix alone would have had no effect where it matters. Found while verifying CRM-236 on the local stack: the running container still reported AI_CALL_TIMEOUT_SECONDS=30 after the rebuild. .env.example carries the same stale 30 and is a protected file here, so it is left for a maintainer to update — flagged in the PR and on the card. * style(compose): trim the CRM-236 note to what the value does not say Four lines of measurement narrative above one env value; the numbers live in the PR. Kept: why an explicit value here matters at all. * fix(env): stop shipping AI_CALL_TIMEOUT_SECONDS=30 to new installs (CRM-236) The two composes were raised to 90, but .env.example is what a fresh install copies — leaving 30 here meant every new box was born with the old ceiling and the raised default never took effect. --------- Co-authored-by: Matheus Pastorini <matheus.pastorini@etus.com.br> Co-authored-by: Guilherme Gomes <guinomotec.dev@gmail.com>
…evelop (#176) - evo-ai-crm-community 8c007a2 -> 0a09b80: macros sem conversa resolvida (CRM-152) e a regra que silencia o bot nomeada (CRM-212). - evo-ai-frontend-community 02ad8d5 -> e5794f6: etiqueta salva por labelId (CRM-215), aviso de atribuicao por inbox (CRM-162), troca de senha no card do agente (CRM-210, CRM-251). - evo-ai-processor-community f83ec1e -> cbba441: stages das regras de pipeline no prompt (CRM-235), conversa/contato vindos do contexto (CRM-237) e o agente que ninguem espera para de rodar (CRM-236). - evo-auth-service-community b861842 -> bc57cbd: admin troca a senha de outro usuario (CRM-210) e o entrypoint so cria o banco quando ele nao existe (CRM-216). - evo-bot-runtime b2b2d88 -> 7ec7db4: feedback de provedor degradado (CRM-236). - evo-flow-community eabb7f1 -> f1bda76: condicao de Etiqueta casa por labelId ou labelName e a exclusao de contato deixa de depender do cache quente (CRM-215).
…s da develop (#177) - evo-ai-crm-community +35 CRM-320, 286, 285, 301, 289, 258, 255/254, 206 - evo-ai-frontend-community +15 CRM-318, 262, 254, 116 - evo-flow-community +17 CRM-257, 271, 256, 241 - evo-ai-core-service-community +6 CRM-116 (quota de agentes) - evo-auth-service-community +3 CRM-262 Sem pendencia: processor, bot-runtime, nexus, evolution-api, evolution-go.
Tres ponteiros. Os outros sete ja estavam na ponta da develop.
evo-ai-crm-community (11): superficie de embed do Hub para o signup
rodar dentro do CRM, com a excecao do whatsapp_connect declarada no
guard de mutacoes (CRM-314); configuracao de instalacao passa a exigir
permissao granular e nega com 403 em vez do 401 que desloga (CRM-366);
provider default do agent bot despachado por job assincrono (CRM-347).
evo-ai-frontend-community (19): editar etiqueta deixa de derrubar a
tela (CRM-381); criar contato com avatar para de recusar labels e de
achatar atributo aninhado (CRM-321); status da mensagem mostra o motivo
do provedor (CRM-365); conexao do canal Meta se conclui sem sair do CRM
(CRM-314).
evo-ai-core-service-community (4): PUT /agents/{id} mescla o config em
vez de substituir, com a preservacao comparando valor e nao presenca
(CRM-305).
…s-community-crm-305-347-381 chore(submodules): bumpa crm, frontend e core da community
Internal review material for a private-repo change; it is not documentation for anyone running the community stack.
…al-review-doc docs: remove internal review notes from the public repo
Review lives on the board, not in the repository. Removes internal/ and untangles the two CHANGELOG references and the nginx README paragraph that described the gateway defaults in terms of that stack.
…-review chore: drop the internal review stack from the repo
Freezes the seven family services at their develop heads of 2026-09-02. These are the commits the v1.1.0 tags are cut from. auth 61158f5 -> 851073d crm 1e01c5a -> aa3d408 frontend 85eff52 -> 20ba0e6 processor cbba441 -> a8e1bd4 core 32d792c -> c6f7ba3 flow 6d31ce1 -> 1734849 bot-runtime 7ec7db4 (already at head) evolution-api, evolution-go and evo-nexus keep their own versioning and are not part of the v1.1.0 tag set.
…tack evo-flow was the only service in docker-compose.swarm.yaml still on the mutable :develop tag, introduced in #163 the day before the v1.0.0 cut. A swarm deploy therefore mixed a released family with one service tracking develop. :latest is what a tagged release publishes, so it matches the rest.
chore(release): congela os ponteiros da família para o corte da v1.1.0
docs(changelog): add v1.1.0 release section
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @gomessguii, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 2 days and 17 hours by commenting @sourcery-ai review. Upgrade to get a review now.
Reviewer's GuideThis release-cut PR fast-forwards the umbrella’s release state from develop into main by updating all service pointers and documenting v1.1.0, while also wiring the new credential/media configuration, correcting the RBAC documentation, switching the swarm evo-flow pointer to the released image stream, and removing obsolete internal review-stack assets. File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
walkeralencar
pushed a commit
to aoba-tech/evo-crm-community
that referenced
this pull request
Sep 3, 2026
… dump fix (EVO-1966) Move o ponteiro do CRM 7ab9a9f -> 041a5ef pra o umbrella pegar o evo-ai-crm-community#186 (disable schema dump no dev). Sem esse bump, um clone limpo do develop + make setup ainda 500a no dashboard, apesar de evolution-foundation#186/evolution-foundation#134 estarem mergeados. Só o ponteiro do CRM; nenhum outro submodulo tocado.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Passo 6 (último) do corte da v1.1.0: alinha a
maindo umbrella com adevelop, que carrega os ponteiros congelados da família e a seção de CHANGELOG onde a tagv1.1.0foi cortada (3c19c2d).developentrando namainmain(a limpeza do stack de review interno, aplicada nas duas branches em separado em 28-29/08) entram no merge sem conflito de conteúdo — a remoção já está feita dos dois ladosv1.1.0já está publicada; as 7 tags dos submódulos e as 7 GitHub Releases tambémDepois deste merge a família fica com
main,developev1.1.0no mesmo conteúdo em todos os repos, e o:latestdo Docker Hub deixa de ser o conjunto misto que ficou do corte de agosto pela metade.Summary by Sourcery
Align the umbrella and its services on the v1.1.0 release with hardened authorization, encrypted credentials, corrected AI and automation behavior, and coordinated deployment configuration.
New Features:
Bug Fixes:
Enhancements:
Build:
CI:
Deployment:
Documentation:
Chores: