A lógica do código parece correta. O problema provavelmente é na RLS — a página pública usa o cliente Supabase sem autenticação, então as policies de rewards e reward_teams podem estar bloqueando a leitura anônima. Verifico:
RLS está correto — rewards_select e reward_teams_select são públicos. O problema está na lógica de filtragem. Vou reler o código da página:
Encontrei o problema. O filtro de equipe tem uma falha: quando o cliente tem um team_id mas o prêmio é global (sem nenhuma linha em reward_teams), isGlobal = true e o prêmio passa. Porém quando o cliente não tem team_id (como a Andréia pode estar) e o prêmio tem equipes associadas, matchesTeam = false e o prêmio é bloqueado.
Mas o problema real é mais simples: vou verificar os dados da Andréia e dos prêmios existentes direto no banco:
Diagnóstico preciso agora:
admin_id = ea5eea68... (não é o Igor 58850483...), team_id = 54acb801...admin_id = 58850483... (Igor)O problema é esse: a query filtra .eq('admin_id', adminId) onde adminId é o admin_id do cliente Andréia (ea5eea68...), mas os prêmios pertencem ao Igor (58850483...). A Andréia foi criada por um membro/admin diferente, então nenhum prêmio bate.
A solução: os prêmios devem ser buscados pelo super admin — que é sempre o Igor. O admin_id do cliente não é confiável para isso. Preciso buscar o super admin da equipe da Andréia:
O problema era que a query buscava prêmios pelo admin_id do cliente (ea5eea68... — o membro que criou a Andréia), mas todos os prêmios pertencem ao Igor (58850483...). A correção busca primeiro o super admin da plataforma via is_super_admin = true e usa o ID dele para filtrar os prêmios — assim qualquer cliente de qualquer membro enxerga os prêmios criados pelo Igor corretamente.
You can send messages while the preview loads