# Usuários e permissões

Funções, permissões por recurso e verificações em templates, bibliotecas e na API.

O acesso no Nimbly é baseado em funções. Um usuário tem uma ou mais funções, e uma função tem permissões. As mesmas permissões valem no admin, na API, na edição na página e nos seus próprios templates.

## Funções

O setup cria duas funções: `admin`, que pode tudo, e `editor`. As funções são gerenciadas em `/nb-admin/roles/`. A tela de permissões mostra uma linha por recurso com uma caixa de seleção por operação, para que uma função possa, por exemplo, editar projetos mas só ler leads.

## Permissões

Todo recurso tem o mesmo conjunto:

| Permissão | Permite |
|---|---|
| `view-projects` | Ler projetos |
| `create-projects` | Adicionar projetos |
| `edit-projects` | Alterar projetos |
| `delete-projects` | Excluir projetos individuais |
| `manage-projects` | Tudo o que está acima |
| `import-projects`, `export-projects` | Importar e exportar no admin |

Outras permissões cobrem a própria plataforma:

| Permissão | Permite |
|---|---|
| `edit-inline-content` | Editar textos e imagens nas páginas |
| `view-nimblybar` | A barra de edição no site |
| `view-admin-dashboard` | O painel do admin |
| `view-stats` | Estatísticas de visitantes |
| `edit-.config` | Configurações do site e das páginas |
| `chat-nimbly` | O agente integrado no chat da equipe |

Os projetos podem acrescentar permissões próprias, como `approve-orders`, e verificá-las em templates e bibliotecas.

## Verifique o acesso nos templates

Mostre algo só para usuários com uma permissão:

```html
[#feature-cond features=edit-projects tpl=btn-edit-project#]
[#feature-cond features=view-reports tpl=reports-panel tpl_else=reports-locked#]
```

Proteja uma página inteira; um visitante sem a permissão é mandado embora antes que algo seja exibido:

```html
[#access feature=view-reports#]
[#html#]
```

Esconder um botão é apresentação, não proteção. A operação por trás dele, na API ou numa biblioteca, verifica a permissão por conta própria.

## Verifique o acesso em PHP

```php
load_library('access');
if (!access_by_feature('approve-orders')) {
    return;
}
```

Num endpoint de API próprio, `api_access('<permission>')` aceita o usuário autenticado, um token da API ou uma operação pública permitida explicitamente. Restrinja os dados ao usuário quando eles pertencem a ele, por meio de `$_SESSION['username']`.

## Usuários com dados próprios

Para uma área de membros, guarde o dono no registro e filtre por ele na biblioteca que prepara a página. Um usuário pode alterar os próprios campos de perfil; quais são, você define com `self_edit` no recurso users.

## Usuários da API

Uma integração entra como um usuário próprio, com uma função que tem só o necessário. Um feed que só lê projetos precisa de `view-projects` e de mais nada. Veja [Integrações](/pt/docs/guides/integrations/).

Excluir todos os registros de um recurso de uma vez é uma permissão separada, `api_delete_resource_<resource>`, que nenhuma outra permissão inclui.

## Sessões

As sessões terminam após um período sem atividade: 4 horas para visitantes, 3 dias para usuários autenticados e 7 dias para admins, configurável por função em `session` nas configurações do site. **Sign out everyone** no admin encerra todas as sessões.