uVersion
Português
Baixar →

Wiki

Papéis e painel de administração

O painel de administração do uVersion: quem pode abri-lo, os 9 papéis, super admin frente a project_admin, a hierarquia de níveis e qual aba está disponível para quem.

Introdução

O painel de administração está integrado ao cliente desktop do uVersion. Ele reúne a gestão de usuários, grupos, permissões, regras de validação, webhooks, distribuição e armazenamento. Esta página explica o sistema de papéis no qual todo o resto se apoia: leia-a antes das outras páginas desta seção.

Abrir o painel

O painel de administração aberto, mostrando a lista de abas (Usuários, Grupos, Permissões, Regras, Webhooks, Distribuição, Armazenamento).

Faça login no cliente desktop com uma conta que tenha um papel de administração e abra a entrada Admin na navegação. As contas sem papel de administração não veem essa entrada.

Dois papéis abrem o painel: admin (super administrador) e project_admin (administrador de projeto). O que eles veem ali não é idêntico: veja a seção seguinte.

Super admin vs project_admin

O uVersion distingue dois níveis de administração:

  • Super admin (papel admin): autoridade sobre todo o servidor. Ele gerencia todos os repositórios, todos os usuários, as configurações globais, a auditoria, a licença.
  • project_admin: administrador completo, mas apenas dos projetos que administra. Em seus repositórios, ele faz tudo o que um admin faz (permissões, regras, webhooks, GC, obliteração). Fora de seus repositórios, ele não tem nenhum poder de administração.

O princípio: um project_admin é um administrador pleno de seus próprios projetos, e nada em outro lugar. Por isso o painel dele é compartimentado: algumas ações globais (veja abaixo) permanecem reservadas ao super admin.

Os 9 papéis

PapelPara que serve
adminSuper administrador: acesso total, todo o servidor.
project_adminAdministrador de projeto: admin completo de seus repositórios, nada em outro lugar.
leadLíder de equipe: escrita em todos os repositórios e várias capacidades elevadas (aprovação, atividade global, distribuição). De fato, hoje um papel muito poderoso.
artistColaborador (arte): check-out / check-in de arquivos conforme suas permissões.
programmerColaborador (código): check-out / check-in conforme suas permissões.
qaControle de qualidade: contribui e participa das revisões.
userColaborador genérico.
viewerSomente leitura.
playtesterAcesso apenas às builds publicadas (download de jogos). Não vê nem o workspace nem os arquivos do repositório.
O papel define o poder, a permissão define o alcance O papel diz o que uma conta pode fazer (administrar, contribuir, ler). As permissões dizem em quais pastas. Um artist só pode modificar os caminhos onde a escrita lhe foi concedida.

Níveis e guarda

Os papéis são ordenados por nível: admin 100, lead 50, project_admin 40, programmer / artist / qa / user 10, viewer / playtester 5.

Um administrador só pode agir sobre uma conta estritamente abaixo de seu próprio nível: assim, ninguém pode se autopromover, nem modificar um par, nem se rebaixar abaixo do próprio nível. É isso que impede, por exemplo, que um project_admin (nível 40) se transforme em super admin.

Quem acessa qual aba

AbaSuper adminproject_admin
UsuáriosGestão completaApenas criação, lista compartimentada
GruposGestão completaLeitura dos nomes (para direcionar uma concessão)
PermissõesSimSim, em seus repositórios
RegrasSimSim, em seus repositórios
WebhooksSimSim, em seus repositórios
DistribuiçãoSimNão (reservado a admin e lead)
Armazenamento & GCSimSim, em seus repositórios

Permanecem estritamente de super admin: a modificação / redefinição / desativação de um usuário, a gestão de grupos (além da simples leitura), a auditoria, as configurações do servidor, as estatísticas globais e a licença.

Capacidades de todo o servidor

Algumas autorizações são capacidades vinculadas ao papel e válidas em todo o servidor (não têm dimensão por repositório). Duas consequências práticas:

  • Um lead, que detém a capacidade manage_rules, tem acesso à Distribuição em todo o servidor.
  • Um project_admin não detém nenhuma capacidade: sua autoridade vem da lista de projetos que administra, não de uma capacidade. É deliberado, uma capacidade não pode ser limitada a um projeto.