Criar uma função personalizada

As três funções padrão cobrem a maioria dos casos, mas toda igreja eventualmente precisa de algo que não encaixa nelas — um tesoureiro que pode registrar doações mas não pode ver endereços de membros, um líder de louvor que gerencia um ministério, um coordenador de voluntários que cuida da presença durante a semana mas nunca toca em doações. Funções personalizadas permitem que você construa exatamente o pacote de permissões que quer e dê a ele um nome que sua equipe reconheça.

Abra a caixa de diálogo de criar função

Em Usuários e Funções → Funções e Permissões, clique no botão Adicionar função no canto superior direito do card Gerenciar funções. A aba Funções e Permissões só é visível para usuários com users.manage — se você não a vê, provavelmente está conectado como Leader ou Viewer; mude para uma conta Administrator.

Preencha os três campos

Nome da função

O que a função é chamada em todos os lugares onde aparece — o chip no perfil de um usuário, o cabeçalho da coluna na matriz de permissões, a opção no seletor de função quando você está convidando um usuário. Use o título que sua igreja realmente usa em voz alta: Tesoureiro, Líder de Louvor, Recepcionista de Visitantes, Coordenador da Escola Dominical. Duas ou três palavras é o ponto ideal.

Chave da função

Um identificador curto e seguro para máquina que o banco de dados e o registro de auditoria usam para referenciar a função. Se você deixar em branco, o GCM deriva uma do nome — minúsculas, espaços substituídos por sublinhados, pontuação removida. Líder de Louvor vira lider_de_louvor; Coordenador da Escola Dominical vira coordenador_da_escola_dominical.

Você pode sobrescrever se quiser algo mais curto (tesoureiro em vez de tesoureiro_da_igreja), mas escolha com cuidado — a chave é o que aparece em logs de erro, na trilha de auditoria e em quaisquer integrações personalizadas que consultem a tabela de funções. Uma vez que um usuário foi atribuído à função, alterar a chave deixaria a atribuição órfã, então a UI não permite que você a edite após a criação. Exclua e recrie se precisar de uma chave diferente.

TIP

Atenha-se a letras minúsculas, dígitos e sublinhados. O auto-derivador aplica isso, e o banco de dados tem um índice único em (organization_id, key) para que duas funções no seu espaço de trabalho não compartilhem uma chave.

Descrição

Uma nota de uma linha para o próximo admin ler. "Registra doações e gerencia fundos, mas não pode ver endereços de membros ou o histórico de doações de outros membros." Opcional, mas apreciada — aparece sob o nome da função na lista de funções e no tooltip da coluna na matriz de permissões.

Salve e escolha permissões

Clique em Criar. A função é inserida em roles_v2 com is_system = false (que é o que a torna excluível depois) e aparece imediatamente como uma nova coluna na matriz de permissões abaixo. Ela começa com zero permissões marcadas — a matriz é sua tela em branco.

Role a matriz e ative o que a função precisa. Cada interruptor grava em role_permissions_v2 no momento em que você o aciona; não há botão de salvar. Veja Concedendo permissões para o catálogo completo e combinações comuns.

WARNING

Uma função personalizada com zero permissões é funcionalmente inútil — atribua-a a um usuário e ele pode entrar mas cada página retorna um banner de permissão negada. A UI permite criar funções vazias deliberadamente (você pode querer conceder permissões depois) mas não as deixe vazias em produção.

A flag is_system

As três funções iniciadas têm is_system = true. A sua terá is_system = false. Isso importa em dois lugares:

1. A lista de funções esconde o botão de exclusão em funções de sistema. Você ainda pode ativar ou desativar as permissões delas — isso é seguro — mas não pode removê-las inteiramente.
2. Um trigger de banco de dados também aplica isso no backend. Mesmo que você contorne a UI e chame o endpoint de exclusão diretamente, o SQL rejeita a requisição com um erro cannot delete system role.

A flag is_system é definida no momento da inserção e não pode ser invertida depois. Não há forma suportada de converter uma função personalizada em uma de sistema, ou vice-versa. Se você precisa disso, contate o suporte e nós cuidamos via uma sessão de impersonificação de platform admin.

Excluindo uma função personalizada

Clique no ícone vermelho de lixeira na linha da lista de funções. Duas verificações rodam:

1. Se ainda há usuários atribuídos à função, a exclusão é rejeitada com uma contagem de quantos. Reatribua ou remova esses usuários primeiro — veja Convidar um usuário para a caixa de diálogo de atribuição.
2. Se a exclusão tem sucesso, cada linha em role_permissions_v2 para aquela função também é removida na mesma transação. Nada recebe soft-delete; esta é uma limpeza definitiva.

Se você excluir por engano, precisará recriar a função e reconceder as permissões. Funções personalizadas não estão na lixeira.

Padrões de nomenclatura que funcionam

Alguns padrões que vimos compensar:

• Tesoureiro — giving.view, giving.record, giving.manage, reports.view. Nada mais. Ótimo para quem conta o dinheiro e para a comissão de auditoria.
• Líder de Louvor — members.view, events.view, events.create, events.edit, messaging.send. Limitado ao ministério Equipe de Louvor, gerencia ensaios sem ver o diretório mais amplo.
• Recepcionista de Visitantes — members.view, members.create, forms.submit. Permite que o voluntário do balcão de boas-vindas adicione novos visitantes durante o culto.
• Auditor — toda permissão view e nada mais. Mesma forma de Viewer mas nomeada para o contexto para que o registro de auditoria mostre Auditor entrou em vez de Viewer entrou.

Próximo

• Concedendo permissões — a matriz em detalhe.
• Permissões limitadas — restrinja a função a uma filial.
• Registro de auditoria de mudanças de função — veja quem cria e edita funções.