Administrador de plataforma

Público

Este artigo é para operadores da plataforma GCM. Administradores de igreja devem ver Usuários e funções — o console de Administrador de plataforma é o cockpit interno da equipe, não faz parte do espaço de trabalho de cada igreja.

O Administrador de plataforma é a superfície exclusiva para operadores que fica atrás de app.geniuschurchmanager.com/platform. É assim que a equipe GCM gerencia cada organização na plataforma: quem está em atraso, por que uma função edge explodiu ontem à noite, qual título de página de destino é enviado em espanhol, o que o cron de renovação fará amanhã de manhã às 02:00. É uma camada React separada com sua própria barra lateral (PlatformLayout), seu próprio portão RBAC e sua própria postura de auditoria.

Quem pode entrar

Só um usuário cujo JWT carrega is_platform_admin: true ou is_superadmin: true pode carregar qualquer rota /platform/*. Tanto o PlatformLayout quanto o PlatformAdmin.tsx verificam usePermissions().roles na montagem e redirecionam não-staff de volta para /. A claim do JWT é definida pela função edge auth-hook a partir do perfil do usuário, então as promoções entram em vigor no próximo login.

Existem dois níveis:

Função	O que ela libera
platform_admin	Leitura/escrita total em cada organização, cada livro-razão de faturamento, cada linha de auditoria. Não pode promover outros usuários a platform_admin ou superadmin.
superadmin	Tudo acima, além da capacidade de conceder platform_admin e superadmin. Um trigger do DB (trg_protect_platform_admin_role*) proíbe rebaixar o último superadmin.

Se sua conta perder ambas as flags, você será silenciosamente jogado de volta para / no momento em que visitar /platform — saia e entre novamente após qualquer mudança de função, já que o JWT é o que conta.

Ressalva da conta de demonstração

A conta de demonstração compartilhada em app.geniuschurchmanager.com não é mais administradora de plataforma. Para acompanhar as capturas de tela desta seção, você precisa de uma conta da equipe que carregue a claim platform_admin. Peça a um superadmin para provisionar uma se você não tiver acesso.

Os seis grupos de navegação

A barra lateral é agrupada para combinar com o ritmo do trabalho do operador, não com o alfabeto:

1. Visão geral — KPIs da visão geral, Lista de organizações.
2. Planos e módulos — Catálogo de planos, mapeamento plano -> módulo. Em sua maioria somente leitura após o lançamento.
3. Faturamento — Console de operações de faturamento, configuração do gateway, métricas de MRR / churn.
4. Conteúdo — Modelos de e-mail, modelos de site, modelos de workflow, sobreposições de conteúdo da página de destino.
5. Configurações — Marca, manifesto PWA, DNS, canais, configurações de e-mail, slugs reservados.
6. Sistema — Usuários, dados mestres de Geografia, Log de auditoria, Log de erros.

O que mora em qual tabela

A maioria das superfícies nesta seção lê de uma de três tabelas com escopo de plataforma:

• platform_audit_log — cada ação de equipe: organização criada, plano alterado, reembolso emitido, personificação iniciada, impersonation_failed. Capturado por useAppMode e por cada função edge de operações de faturamento.
• platform_settings — armazenamento chave/valor plano. Mantém a marca (brand_title, brand_logo), copy de marketing (marketing_hero_title), links sociais, o interruptor do tour guiado. Sem coluna organization_id — isso é em toda a plataforma.
• admin_impersonation — a linha de sessão que o RPC start_impersonation cria para que current_org_id() possa, de forma transparente, restringir um usuário da equipe à organização-alvo. A linha é o que faz a RLS "simplesmente funcionar" durante a personificação.

Qualquer coisa que pareça dados por organização (orgs, payment_history, linha do tempo de auditoria, error_log) vive nas mesmas tabelas multi-tenant que um admin de tenant tocaria — a equipe só vê cada linha em vez do que vale uma organização.

Somente leitura por padrão, auditar-cada-escrita por design

As abas do Administrador de plataforma se apoiam fortemente em três padrões:

• useQuery em cache para leituras, então o refresh é grátis e consistente entre abas.
• Campos de motivo em cada escrita destrutiva — reembolsos, exclusões em massa, sobreposições de assinatura — todos exigem um motivo em texto livre que aterrissa em platform_audit_log ao lado do e-mail do ator.
• Simulação antes da cobrança — o diálogo de renovação tem por padrão "Apenas pré-visualizar" para que você possa ver o que o gateway faria antes que o dinheiro se mova.

Se um recurso futuro permitir que você altere o estado em toda a plataforma sem um campo de motivo, trate isso como um bug.

Para onde ir em seguida

Você precisa...	Artigo
Encontrar uma organização pelo nome, alterar seu plano ou excluir um duplicado	Organizações
Reembolsar um pagamento, consertar uma renovação travada ou rastrear uma cobrança falha	Operações de faturamento
Entrar no espaço de trabalho de um cliente para reproduzir um bug	Fluxo de personificação
Triar um pico de erros estilo Sentry	Log de erros
Investigar "quem mudou o quê, quando"	Log de auditoria
Adicionar um país, estado ou cidade ausente ao seletor de endereço	Dados mestres de Geografia
Ajustar o texto do herói da página de destino ou enviar uma nova imagem OG	Sobreposições de conteúdo da página de destino