Sistema EAMSP no GitHub Pages (versão simples)

Site estático (HTML + JavaScript) publicado no GitHub Pages. Os dados ficam no Supabase; o sistema guarda apenas os comprovantes de reembolso em PDF (em um bucket privado, de até 5 MB cada) e nenhum outro arquivo; o restante são nomes, datas de validade (atestado e anuidade), provas e pedidos de reembolso.

Passo a passo

1. Supabase: crie um projeto (região São Paulo, se disponível). No SQL Editor, cole o schema.sql e clique em Run. (Quem já tinha instalado uma versão anterior: veja "Atualizar uma instalação existente".)
2. Chaves: em Project Settings > API, copie a Project URL e a chave anon para o config.js. Nunca use a service_role.
3. GitHub: crie um repositório em nome da equipe (ex.: eamsp) e envie estes arquivos na raiz.
4. Pages: em Settings > Pages, escolha Deploy from a branch, branch main, pasta / (root). O endereço será https://USUARIO.github.io/eamsp/.
5. Login: no Supabase, em Authentication > URL Configuration, coloque o endereço do passo 4 (com a barra final) em Site URL e também em Redirect URLs. Sem isso, a confirmação de e-mail e a recuperação de senha não funcionam.
6. Primeira gestão: cadastre-se no site e, no SQL Editor, rode (trocando o e-mail): update public.perfis set papel = 'admin' where id = (select id from auth.users where email = '[email protected]');
7. Teste de permissões: com duas contas de atleta e uma de gestão, siga o roteiro do fim do schema.sql.

Atualizar uma instalação existente

Quem já tem o sistema instalado não roda o schema.sql de novo: abra o SQL Editor do Supabase, cole o migracao_v2.sql e clique em Run; depois faça o mesmo com o migracao_v3.sql. Cada uma pode ser repetida sem problema (não duplica nada), mas se você rodar a migracao_v2.sql de novo, rode a migracao_v3.sql depois de novo (a v2 recria o gatilho de reembolsos sem as regras da v3). Instalações novas usam apenas o schema.sql, que já inclui tudo. Para instalações anteriores aos níveis de acesso, rode antes o migracao_niveis.sql; não rode a migracao_niveis.sql depois da v3 (ela é só para instalações antigas e recriaria a lista antiga de funções). As migrações terminam com um comando que recarrega o cache da API do Supabase; se o site mostrar "Could not find a relationship … in the schema cache", rode notify pgrst, 'reload schema'; no SQL Editor. Publique a migração do banco e o novo app.js juntos: um app.js antigo, ainda em cache, que aprove renovações depois da migração recebe o erro "Informe a data de emissão".

Funções da versão 2

• Reembolso: o valor da inscrição é preenchido a partir da prova escolhida; antes de enviar há uma prévia do pedido; se for recusado, o atleta corrige e reenvia o mesmo pedido, e o histórico de tentativas fica guardado.
• Calendário: cada prova pode ter várias distâncias. O atleta marca "Vou correr" (só em prova futura, com distância da própria prova) e a gestão tem a lista da tenda, pronta para imprimir.
• Avisos dentro do sistema: um sino mostra pendências e novidades (por exemplo, decisão sobre renovação ou reembolso). Avisos por e-mail ainda não existem.
• Renovações pela gestão: a gestão informa a data de emissão e a de pagamento; mudanças na emissão ficam no histórico.

Dashboard financeiro e pagamento em lote

• Dashboard financeiro: cartões por situação (pendente, aprovado, pago, recusado), barras por mês, ranking por prova, tempo médio até o pagamento e filtro de período (o período vale para a data da solicitação, em horário de São Paulo; só a série mensal de pagos usa a data do pagamento). O bloco Por atleta aparece só para gestão e admin.
• Pagamento em lote: a gestão seleciona reembolsos aprovados, informa a data do pagamento e confirma. É tudo ou nada: se um pedido do lote não puder ser pago, nenhum é pago. Ninguém paga o próprio reembolso.
• Patrocinador: o admin atribui a função na aba Usuários; a pessoa pode ser também atleta. Ela vê só o dashboard, com totais, sem nome de atleta nem descrição dos pedidos. No banco o patrocinador pode ler o calendário de provas (informação da equipe, não dado pessoal); na tela a aba Calendário só aparece se ele também for atleta.

Níveis de acesso

• Atleta: vê o calendário, atualiza o nome, solicita renovações e reembolsos e acompanha as decisões.
• Gestão: tudo do atleta, mais cadastrar provas, ver os atletas e validar renovações e reembolsos.
• Admin: tudo da gestão, mais a aba Usuários, onde atribui a função de cada pessoa cadastrada. O banco impede que alguém mude a própria função sem ser admin e que o último admin seja rebaixado; cada mudança fica registrada.
• Patrocinador: vê apenas o dashboard financeiro (totais, sem nomes nem descrições); no banco pode ler o calendário de provas (informação da equipe, não dado pessoal), mas na tela a aba Calendário só aparece se ele também for atleta. Não lê reembolsos, renovações nem perfis de outras pessoas. Pode ser também atleta.
• O primeiro admin é definido pelo SQL Editor (passo "Primeira gestão", agora com 'admin'). Depois disso, as demais funções são dadas pela aba Usuários.

Validação pela gestão

• Atestado e anuidade: o atleta não altera as datas diretamente. Ele solicita a renovação (com a nova validade) e a data só passa a valer quando a gestão aprova. A recusa exige motivo, e só pode haver uma solicitação pendente por tipo.
• Reembolso: o atleta cria o pedido como pendente e só pode cancelá-lo enquanto pendente. A gestão aprova, recusa (com motivo) e marca como pago, nessa ordem; o banco bloqueia qualquer outro caminho e registra quem decidiu e quando.
• A gestão confere o comprovante fora do sistema: como não há arquivos guardados, a validação é uma confirmação manual.

Cuidados

• O repositório em Pages gratuito é público. Nele ficam só o código, a URL e a chave anon, que são públicas por desenho. Nunca coloque dados de atletas no repositório.
• A segurança vem das regras do banco (schema.sql); não desative a segurança por linha (RLS).
• No plano gratuito do Supabase o projeto pausa após cerca de uma semana sem uso e os backups são limitados. Para uso real com a equipe, avalie o plano Pro.
• A biblioteca do Supabase é carregada de um CDN público; se quiser mais controle, fixe uma versão exata no index.html.
• Peça o consentimento dos atletas e publique um aviso de privacidade (LGPD): o sistema trata dado de saúde (validade do atestado).