-- AS QUATRO PERMISSOES COM O NOME DA TELA -- o passo 7 da etapa 1 do corte (04/11/2026,
-- a resposta 298 (c) do dono, "As quatro passam ao nome da tela no dia da virada"; o
-- D701; a DE3 de docs/f3-relatorios/spec-datas-da-equipe.md).
--
--     mysql --default-character-set=utf8mb4 franquia_producao < scripts/renomear-permissoes-das-telas-novas.sql
--
-- Com o codigo novo no lugar e a manutencao no ar. A volta e
-- `scripts/devolver-nomes-das-permissoes-das-telas-novas.sql`, ANTES de o codigo antigo
-- servir.
--
-- O QUE ELE FAZ: renomeia quatro linhas de `funcionalidades`, cada uma pelo id E pelo nome
-- antigo (os ids lidos na copia so por SELECT, em 04/11/2026):
--
--     49  Relatórios de aniversariante        -> Relatórios de datas da equipe
--     40  Relatórios dashboard colaboradores  -> Relatórios do profissional parceiro
--     15  Relatórios de clientes              -> Relatórios da carteira de clientes
--     17  Relatórios de vendas                -> Relatórios da cota-parte
--
-- Os privilegios (`privilegios`, o molde dos grupos, e `privilegios_usuarios`, os de cada
-- pessoa) ligam pelo id: ninguem perde permissao, e as contagens de antes e de depois o
-- mostram. A "Relatórios dashboard colaboradores - plano carreira" nao muda: o id e o nome
-- inteiro casam juntos, e nunca por LIKE.
--
-- SO COM O CODIGO QUE ACEITA O NOME NOVO (o `SessaoAcl::salvarAcessoPeloNomeNovo`, desde
-- 04/11/2026). O `Acl` lanca com o nome que a tabela nao tem, e o `SessaoAcl` de antes
-- pergunta pelos nomes antigos no login de todos: com este roteiro e o codigo velho, ninguem
-- entra. O codigo novo pergunta pelo novo e, sem ele, pelo antigo -- a ordem dentro do passo
-- nao importa.
--
-- ELE PARA SEM MUDAR NADA (o cliente sai com 1, "Column 'PARE_...' cannot be null") em dois
-- casos, e diz qual antes de parar:
--   1. o nome novo ja existe em OUTRO id: dois recursos com o mesmo nome derrubam o login de
--      todos (o `Acl` lanca no segundo `addResource`, o incidente de 15/09 do comentario do
--      `tests/Caracterizacao/fixtures.sql`), e nenhum banco o impede -- o MySQL nao tem indice
--      no nome, e a copia local do PostgreSQL nao tem a `funcionalidades_nome_unico`. Leia o
--      id listado e pare: e decisao, e nao conserto de roteiro.
--   2. um dos quatro ids nao ficou com o nome novo: o id da producao nao e o da copia, ou o
--      nome esta gravado de outro jeito. A conferencia e DENTRO da transacao: o cliente sai, a
--      conexao fecha, e o InnoDB desfaz os quatro. Leia `SELECT id, nome FROM funcionalidades
--      WHERE nome LIKE 'Relat%'` e ajuste o id abaixo, nunca o nome.
-- As duas paradas usam uma tabela TEMPORARIA (some com a conexao); o usuario precisa do
-- CREATE TEMPORARY TABLES, que o root tem.
--
-- IDEMPOTENTE: rodado de novo, o UPDATE muda zero linhas e a conferencia passa.
--
-- UTF-8 EXPLICITO: os nomes tem acento, e o cliente sem `--default-character-set=utf8mb4` os
-- envia em latin1 (o `SET NAMES` abaixo e a segunda garantia).
--
-- O ENSAIO e `php scripts/ensaiar-permissoes-com-o-nome-da-tela.php`, num banco descartavel
-- com dados inventados. NAO FOI APLICADO EM COPIA NENHUMA: as copias locais seguem com o nome
-- antigo ate a proxima exportada, e o `SessaoAcl` as le por ele.

SET NAMES utf8mb4;

CREATE TEMPORARY TABLE de3_nomes (
    id INT NOT NULL PRIMARY KEY,
    antigo VARCHAR(100) NOT NULL,
    novo VARCHAR(100) NOT NULL
) DEFAULT CHARACTER SET utf8mb4;

INSERT INTO de3_nomes (id, antigo, novo) VALUES
    (49, 'Relatórios de aniversariante', 'Relatórios de datas da equipe'),
    (40, 'Relatórios dashboard colaboradores', 'Relatórios do profissional parceiro'),
    (15, 'Relatórios de clientes', 'Relatórios da carteira de clientes'),
    (17, 'Relatórios de vendas', 'Relatórios da cota-parte');

SELECT '=== ANTES (id, nome, moldes de grupo, linhas de pessoas)' AS '';
SELECT f.id, f.nome,
       (SELECT COUNT(*) FROM privilegios p WHERE p.funcionalidade = f.id),
       (SELECT COUNT(*) FROM privilegios_usuarios u WHERE u.funcionalidade = f.id)
  FROM funcionalidades f
 WHERE f.id IN (SELECT id FROM de3_nomes)
 ORDER BY f.id;

-- 1. O NOME NOVO EM OUTRO ID: lista e para, antes de mudar qualquer coisa.
SELECT '=== PARE SE HOUVER LINHA: o nome novo ja existe em outro id (id, nome)' AS '';
SELECT f.id, f.nome
  FROM funcionalidades f
  JOIN de3_nomes n ON f.nome = n.novo AND f.id <> n.id
 ORDER BY f.id;

CREATE TEMPORARY TABLE de3_pare_antes (PARE_o_nome_novo_ja_existe_em_outro_id CHAR(2) NOT NULL);
INSERT INTO de3_pare_antes VALUES (IF(
    (SELECT COUNT(*) FROM funcionalidades f JOIN de3_nomes n ON f.nome = n.novo AND f.id <> n.id) = 0,
    'ok', NULL));

CREATE TEMPORARY TABLE de3_pare_depois (PARE_um_dos_quatro_ids_nao_ficou_com_o_nome_novo CHAR(2) NOT NULL);

START TRANSACTION;

SELECT '=== MUDOU (as linhas renomeadas agora: 4 na primeira vez, 0 nas seguintes)' AS '';
UPDATE funcionalidades f
  JOIN de3_nomes n ON n.id = f.id
   SET f.nome = n.novo
 WHERE f.nome = n.antigo;
SELECT ROW_COUNT();

-- 2. A CONFERENCIA, DENTRO DA TRANSACAO: os quatro ids com o nome novo.
SELECT '=== PARE SE HOUVER LINHA: o id que nao ficou com o nome novo (id, o nome de agora)' AS '';
SELECT n.id, COALESCE(f.nome, '(o id nao existe)')
  FROM de3_nomes n
  LEFT JOIN funcionalidades f ON f.id = n.id
 WHERE f.nome IS NULL OR f.nome <> n.novo
 ORDER BY n.id;

INSERT INTO de3_pare_depois VALUES (IF(
    (SELECT COUNT(*) FROM funcionalidades f JOIN de3_nomes n ON n.id = f.id AND f.nome = n.novo) = 4,
    'ok', NULL));

COMMIT;

SELECT '=== DEPOIS (id, nome, moldes de grupo, linhas de pessoas: as mesmas contagens de antes)' AS '';
SELECT f.id, f.nome,
       (SELECT COUNT(*) FROM privilegios p WHERE p.funcionalidade = f.id),
       (SELECT COUNT(*) FROM privilegios_usuarios u WHERE u.funcionalidade = f.id)
  FROM funcionalidades f
 WHERE f.id IN (SELECT id FROM de3_nomes)
 ORDER BY f.id;

SELECT '=== DEPOIS, NENHUMA LINHA COM UM DOS NOMES ANTIGOS (zero)' AS '';
SELECT COUNT(*) FROM funcionalidades f JOIN de3_nomes n ON f.nome = n.antigo;