Permissões

Introdução

A aba Permissions define, para um repositório específico, quem pode ler ou escrever em quais pastas. Uma permissão tem como alvo um grupo ou um usuário, aplica-se a um padrão de caminho e carrega um nível (write / read / none). A função diz o que uma conta pode fazer; a permissão diz sobre quais arquivos.

Acesso e funções

A aba está disponível para o super admin (todos os repositórios) e para o project_admin (os repositórios que ele administra). As regras estão sempre vinculadas ao repositório selecionado.

Os três níveis

Conceder um acesso

1. Selecione o repositório e, em seguida, a aba Permissions.
2. Escolha o sujeito no seletor: um grupo ou um usuário (duas sublistas "Groups" e "Users"). Uma regra visa um ou outro, nunca ambos.
3. Na árvore de pastas, marque as pastas em questão (as caixas têm três estados: tudo / parcial / nada). Um campo de busca filtra a árvore.
4. Na barra que aparece, escolha o nível (write / read / none) e clique em Apply.

As regras ativas do sujeito são exibidas em uma tabela (padrão, nível, prioridade) onde você pode excluí-las uma a uma.

Conceder por nome de usuário

O botão "+ By username" permite conceder acesso a alguém que não aparece na lista visível, digitando seu nome exato. É a maneira de conceder acesso a uma conta fora do seu escopo habitual, por exemplo um playtester que ainda não possui nenhuma permissão.

O nome deve corresponder exatamente (sem prefixo). O campo retorna apenas o identificador e o nome, nunca a função, para não servir para sondar as contas existentes.

Padrões e prioridade

Uma pasta marcada Foo/Bar torna-se o padrão Foo/Bar/** (a pasta e tudo o que ela contém, em qualquer profundidade). A raiz do repositório torna-se /**.

Cada regra recebe uma prioridade automática igual à profundidade da pasta (número de segmentos, raiz = 0). Uma regra mais específica (mais profunda) prevalece, portanto, sobre uma mais geral. Exemplo: write em Content/** e none em Content/Secret/** dá acesso de escrita em todo Content/ exceto em Secret/.

Resolução padrão

Quando nenhuma regra explícita cobre um caminho, o acesso efetivo segue este modelo:

• Por padrão, o acesso é read (leitura) quando nenhuma regra corresponde.
• admin e lead têm write em toda parte (contorno de função).
• Um project_admin tem write nos repositórios que administra e nada de especial em outros lugares.
• Caso contrário, aplica-se a regra mais específica; na falta dela, a leitura padrão.

Em outras palavras: para proibir a leitura de uma pasta a alguém, não basta não conceder nada (o padrão é read), é preciso uma regra none explícita.

Testar uma permissão

O painel Test Permission responde a "qual acesso efetivo este usuário tem sobre este caminho?". Escolha um usuário, digite um caminho (ex. /Content/Maps/Level01.umap) e execute o teste. O resultado mostra o nível efetivo, bem como a fonte e o padrão que decidiram, o que permite entender por que um acesso é concedido ou negado.

Para um usuário que você não tem o direito de ver, o teste retorna o mesmo "não encontrado" de uma conta inexistente, para não revelar a existência das contas.

Armadilhas comuns

"Não concedi nada, mesmo assim ele consegue ler"

É o padrão read. Para fechar uma pasta, coloque uma regra none explícita sobre ela.

Duas regras se contradizem

A mais específica (maior profundidade) vence. Use o teste para ver qual decide.

Um lead permanece com escrita apesar de uma regra none

As funções admin e lead contornam as regras de caminho (write em toda parte). Uma regra none não as restringe. O mesmo para um project_admin em seus próprios repositórios.

Acesso via grupo vs. acesso direto

Um acesso pode vir da própria conta ou de um grupo do qual ela é membro. Se remover uma regra não muda nada, procure a outra fonte (o teste indica qual se aplica).