---
tags: [projeto, intranet, social-media, bugfix]
date: 2026-04-27
---

# Social Media - Reenviar cronograma apagava hashtags e trocava planejamento

## Sintoma

No modal "Planejamento recusado" (`renderModalCronogramaRejeitado`), ao editar os 3 campos (Planejamento / Legenda / Hashtags) e clicar **Reenviar cronograma**:
- Hashtags eram apagadas no banco
- Planejamento ficava com o texto da Legenda
- Conteúdo (legenda real) não era atualizado

O botão **Salvar** funcionava normal — usa `coletarFormData()`.

## Causa

`reenviarCronograma()` em `app/Views/social_media/index.php:1501` foi escrita quando o modal tinha **1 textarea** só (que era usado como planejamento). Quando o modal foi expandido pra 3 campos separados, a função não foi atualizada e ficou com lógica fóssil:

```js
// CÓDIGO ANTIGO (BUG)
var plan=document.getElementById('epConteudo');  // <- Legenda, não planejamento!
if(plan){fd.append('planejamento',plan.value);fd.append('conteudo','');}
fd.append('hashtags','');  // <- apagava
```

Resultado:
- `planejamento` recebia o valor da Legenda
- `conteudo=''` → o guard backend preserva, mas inconsistente
- `hashtags=''` → ia direto pra coluna (não há guard pra hashtags)
- `epPlanejamento`, `epHash`, `epTitulo` eram ignorados

## Fix

Substituiu o bloco manual de FormData por `coletarFormData()` (mesma função do botão Salvar) — que já lê os 3 campos com os IDs certos. Adiciona apenas `acao=salvar`, `quando_publicar=agendar`, `aprovacao_status=pendente` e segue o fluxo (POST update + chamada ao endpoint cronograma/enviar-cliente).

## Lição

Quando um modal evolui para múltiplos campos, todas as funções de submit que tocam nele precisam ser revistas. Comentários no código tipo "epConteudo no modo 3 é o PLANEJAMENTO" são pegadinhas — eles eram verdade no passado e ninguém atualizou.

## Relacionados
- [[sessao-2026-04-22]]
- [[sessao-2026-04-24-whatsapp-social-notifier]]