-- ---------------------------------------------------------------------------
-- A porta do convite de indicacao, e o passado do formulario escrito uma vez (03/11/2026, a fatia 75 da
-- fila das telas que faltam, REL-INDICACAO-PORTA; a I3 de `docs/f3-relatorios/spec-indicacao.md` e as
-- respostas 264 (b) e 265 (b) do dono, de 25/10/2026, o D613 e o D615).
--
--   mysql franquia_producao < scripts/migracao-indicacao-porta.sql
--
--   indicacoes.porta  por onde o convite veio: 'aplicativo' (o convite do aplicativo,
--                     `AplicativoService::indicacaoCadastrar`) ou 'formulario' (a etapa 6 da
--                     adesao, `FidelidadeService::indicarAmigo`, e o passado abaixo)
--
-- A COLUNA: NOT NULL com o padrao 'aplicativo', e por isso toda linha de antes dela fica do aplicativo --
-- o que todas eram onde o codigo da 53 (c) ainda nao chegou (a producao; na copia, as 10 de 03/11/2026,
-- conferidas: nenhuma do formulario). O codigo novo grava a porta em toda linha que cria (o portao
-- `scripts/conferir-escritores-da-porta.php`). `ALGORITHM=INSTANT`: coluna nova no fim, com padrao.
--
-- AS LINHAS QUE JA ESTAO LA ficam do aplicativo, menos a do formulario com a ligacao da 53 (c) cujo amigo
-- ainda tem a marca de quem indicou (o UPDATE abaixo, com o porque).
--
-- O PASSADO (a 264 (b): "o passado fica nas duas portas e nao muda mais quando o amigo conclui o
-- cadastro; e dado novo no banco, escrito uma vez, e nao paga comissao a ninguem"), LOGO DEPOIS DO
-- `ADD COLUMN`, NO MESMO ROTEIRO, para a coluna e o passado nao se separarem: cada cliente com a marca
-- "Indicação - <id>" da etapa 6 vira uma linha de convite do formulario --
--
--   unidade      = a do amigo (`a.unidade`), que nasceu na do cadastro de quem indicou no dia do convite
--   cliente      = quem indicou, o id da marca, SO SE ESSE CLIENTE EXISTIR (a chave `FK_INDICACOES_cliente`)
--   convidado    = o amigo
--   porta        = 'formulario'
--   url          = '' (a coluna e NOT NULL; o link do passado nao foi guardado)
--   data_convite = a `data_criacao` do amigo
--
-- SEM COMISSAO: NAO toca `clientes.indicacao` (a comissao da primeira compra le o `getIndicacao()` do
-- amigo, `VendaPagamentoService::gerenciarComissaoIndicacaoPrimeiraVenda`), e nao grava `data_venda`,
-- `comissao`, `primeira_venda` nem `data_adesao` (a adesao do passado nao foi registrada). Os 10 pontos
-- por compra seguem a marca, como hoje, e so ela. PULA quem ja tem linha (o `NOT EXISTS` pelo convidado):
-- o amigo com a ligacao da 53 (c) nao duplica, e a segunda vez nao escreve nada. A MARCA E A DO
-- `ISCadastro\Regra\MarcaDaIndicacao::indicadorDoFormulario`, em SQL: "Indicação" com o acento e a caixa
-- (o 'c' do `REGEXP_LIKE`; a comparacao da coluna ignora os dois), o traco, os digitos e os espacos em
-- volta. O `IndicacaoDoFormularioTest` confere as duas leituras.
--
-- NA PRODUCAO, NO LACO DO PASSO 0 DA JANELA, com o sistema parado e depois do backup (a 191 (a); o passo 4
-- de `docs/procedimento-de-corte-etapa-1.md`): nenhum amigo nasce pelo codigo antigo entre o INSERT e o
-- codigo novo. La a 53 (c) ainda nao chegou, e todo amigo do formulario que tiver a marca na hora vira
-- linha (na copia, 183). O que concluiu o cadastro antes ja perdeu a marca, e nao volta.
--
-- NA COPIA LOCAL DESDE 03/11/2026, nos dois bancos (a 264 (b), "nas copias, na fatia I3", e a 83 (a)).
--
-- IDEMPOTENTE: o `ALTER` so roda se a coluna ainda nao existir (o `information_schema`), e o INSERT pula
-- quem ja tem linha. NENHUM DELETE.
--
-- PARA DESFAZER, SO A COLUNA:
--   ALTER TABLE indicacoes DROP COLUMN porta;
-- As linhas do passado FICAM: apagar linha de `indicacoes` pede resposta propria, e um DELETE por porta
-- pegaria tambem as linhas da 53 (c), que cascateiam para os clientes amigos (`FK_CLIENTES_indicacao`,
-- `ON DELETE CASCADE`).
--
-- ---------------------------------------------------------------------------
-- ESTA MIGRACAO PRECISA ESTAR EM PRODUCAO ANTES DO PASSO 1 -- o passo 0 (D323). O codigo antigo de
-- producao nao le a coluna, e o padrao a preenche no INSERT dele.
-- ---------------------------------------------------------------------------

-- O "Indicação" DA MARCA TEM ACENTO: lido pelo cliente em outro conjunto de caracteres, o literal nao casaria
-- com nada, e o passado (e a conferencia) daria zero calado.
SET NAMES utf8mb4;

SET @existe = (
    SELECT COUNT(*) FROM information_schema.columns
     WHERE table_schema = DATABASE()
       AND table_name = 'indicacoes'
       AND column_name = 'porta'
);

SET @sql = IF(@existe = 0,
    'ALTER TABLE indicacoes
       ADD COLUMN porta varchar(12) NOT NULL DEFAULT ''aplicativo''
       COMMENT ''Por onde o convite veio: aplicativo ou formulario.''
       AFTER convidado,
       ALGORITHM=INSTANT',
    'SELECT ''indicacoes: coluna porta ja existe, nada a fazer'' AS aviso'
);

PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

-- AS LINHAS QUE JA ESTAO LA: a coluna nasce com o padrao, e toda linha fica do aplicativo -- menos a do
-- formulario com a ligacao (a 53 (c), desde 10/10/2026, a etapa 6 de quem indica ativo), gravada entre o
-- codigo da 53 (c) e esta coluna: ela e a unica cujo convidado ainda tem a marca de QUEM CONVIDOU NA LINHA
-- (o convidado do aplicativo nasce com a origem "Indicação", sem o numero). Essa volta ao formulario. A que ja
-- concluiu o cadastro perdeu a marca, e nao ha como separa-la da do aplicativo (a I3, a nota do comeco): fica
-- do aplicativo. Na copia de 03/11/2026, nenhuma das duas (as 10 linhas sao do aplicativo); na producao a
-- 53 (c) nao chegou, e tambem nenhuma. Rodado de novo, nao acha nada: o codigo novo grava a porta, e o
-- convidado do aplicativo nao tem a marca.
UPDATE indicacoes i
  JOIN clientes a ON a.id = i.convidado
   SET i.porta = 'formulario'
 WHERE i.porta = 'aplicativo'
   AND REGEXP_LIKE(a.origem, '^[[:space:]]*Indicação[[:space:]]*-[[:space:]]*[0-9]+[[:space:]]*$', 'c')
   AND i.cliente = REGEXP_SUBSTR(a.origem, '[0-9]+');

-- O PASSADO: uma linha do formulario por marca de indicador existente, sem linha ainda.
INSERT INTO indicacoes (unidade, cliente, convidado, porta, url, data_convite)
SELECT a.unidade, quem.id, a.id, 'formulario', '', a.data_criacao
  FROM clientes a
  JOIN clientes quem ON quem.id = REGEXP_SUBSTR(a.origem, '[0-9]+')
 WHERE REGEXP_LIKE(a.origem, '^[[:space:]]*Indicação[[:space:]]*-[[:space:]]*[0-9]+[[:space:]]*$', 'c')
   AND a.unidade IS NOT NULL
   AND a.data_criacao IS NOT NULL
   AND NOT EXISTS (SELECT 1 FROM indicacoes i WHERE i.convidado = a.id)
 ORDER BY a.id;

-- Conferencia. O esperado: as linhas por porta, e as do formulario com e sem a ligacao (na copia de
-- 03/11/2026, 10 do aplicativo e 183 do formulario, todas sem a ligacao); 0 marcas de indicador existente
-- sem linha; e, a parte, as marcas de indicador que nao existe (sem linha, de proposito) e as que ficaram
-- sem unidade ou sem data (nenhuma na copia).
SELECT i.porta, COUNT(*) AS linhas, SUM(EXISTS (SELECT 1 FROM clientes c WHERE c.indicacao = i.id)) AS com_a_ligacao
  FROM indicacoes i GROUP BY i.porta ORDER BY i.porta;

SELECT
    SUM(quem.id IS NOT NULL AND a.unidade IS NOT NULL AND a.data_criacao IS NOT NULL
        AND NOT EXISTS (SELECT 1 FROM indicacoes i WHERE i.convidado = a.id)) AS marcas_sem_linha,
    SUM(quem.id IS NULL) AS marcas_de_indicador_inexistente,
    SUM(quem.id IS NOT NULL AND (a.unidade IS NULL OR a.data_criacao IS NULL)) AS marcas_sem_unidade_ou_data
  FROM clientes a
  LEFT JOIN clientes quem ON quem.id = REGEXP_SUBSTR(a.origem, '[0-9]+')
 WHERE REGEXP_LIKE(a.origem, '^[[:space:]]*Indicação[[:space:]]*-[[:space:]]*[0-9]+[[:space:]]*$', 'c');