uVersion
Русский
Скачать →

Wiki

Роли и панель администрирования

Панель администрирования uVersion: кто может её открыть, 9 ролей, супер-администратор против project_admin, иерархия рангов и какая вкладка кому доступна.

Введение

Панель администрирования встроена в десктоп-клиент uVersion. Она объединяет управление пользователями, группами, правами, правилами проверки, вебхуками, распределением и файлами репозитория. Эта страница объясняет систему ролей, на которую опирается всё остальное: прочитайте её перед другими страницами этого раздела.

Три слова встречаются повсюду. Репозиторий является версионируемым проектом на сервере. Роль является меткой, которую несёт учётная запись (admin, artist, viewer…), и говорит, что этой учётной записи разрешено делать. Право говорит, в каких папках она может это делать.

Открытие панели

1. Открыть пункт Admin

Войдите в десктоп-клиент под учётной записью с ролью администрирования, затем откройте пункт Admin на боковой панели. Учётные записи без роли администрирования этот пункт не видят. Панель открывают две роли: admin (супер-администратор) и project_admin (администратор проекта). То, что они там видят, не одинаково: см. следующий раздел.

2. Различить два ряда вкладок

Под заголовком Admin Panel вкладки расположены в два ряда. Верхний, SERVER, относится ко всему серверу и не зависит ни от какого проекта. Нижний, PROJECT, действует на репозиторий, выбранный в селекторе репозитория в начале этого ряда: смена репозитория меняет то, что показывают эти вкладки. Это первое, что стоит проверить, когда вкладка показывает не то, что вы ожидаете.

Открытая панель администрирования: заголовок Admin Panel, ряд SERVER сверху и под ним ряд PROJECT с селектором репозитория в начале.

Супер-администратор vs project_admin

uVersion различает два уровня администрирования:

  • Супер-администратор (роль admin): власть над всем сервером. Он управляет всеми репозиториями, всеми пользователями, глобальными настройками, аудитом, лицензией.
  • project_admin: полноценный администратор, но только тех проектов, которыми он управляет. В своих репозиториях он делает всё, что делает admin (права, правила, вебхуки, GC, уничтожение). За пределами своих репозиториев у него нет никаких полномочий администрирования.

Принцип: project_admin является полноправным администратором собственных проектов и никем в других местах. Поэтому его панель разделена: некоторые глобальные действия (см. ниже) остаются за супер-администратором.

9 ролей

РольДля чего
adminСупер-администратор: полный доступ, весь сервер.
project_adminАдминистратор проекта: полный админ своих репозиториев, ничего в других местах.
leadРуководитель команды: запись во все репозитории и несколько повышенных возможностей (утверждение, глобальная активность, распределение). Фактически сегодня очень мощная роль.
artistУчастник (арт): check-out / check-in файлов согласно своим правам.
programmerУчастник (код): check-out / check-in согласно своим правам.
qaКонтроль качества: вносит вклад и участвует в ревью.
userОбычный участник.
viewerТолько чтение.
playtesterДоступ только к опубликованным сборкам (загрузка игр). Не видит ни workspace, ни файлы репозитория.
Роль определяет силу, право определяет область Роль говорит, что учётная запись может делать (администрировать, вносить вклад, читать). Права говорят, в каких папках. artist может изменять только те пути, где ему предоставлена запись.

Ранги и защита

Роли упорядочены по рангу: admin 100, lead 50, project_admin 40, programmer / artist / qa / user 10, viewer / playtester 5.

project_admin может назначить только роль строго ниже собственного ранга: то есть он не может ни повысить себя, ни понизить себя, ни создать или повысить admin, lead или другого project_admin.

Супер-администратор является потолком, и над ним нет равного Правило строго более низкого ранга к нему не применяется: супер-администратор может назначить любую роль, включая admin, и действовать на другого супер-администратора (изменить или удалить его). Это необходимо, иначе второго супер-администратора, созданного по ошибке, было бы невозможно убрать.

Кто к какой вкладке имеет доступ

Вкладки ряда SERVER действуют на весь сервер. Вкладки ряда PROJECT действуют на репозиторий, выбранный в селекторе в начале того же ряда.

ВкладкаРядСупер-администраторproject_admin
DashboardSERVERДаНет
RepositoriesSERVERДаНет
UsersSERVERПолное управлениеСоздание и изменение (email, роль); видит все учётные записи, кроме супер-администраторов
GroupsSERVERПолное управлениеНет (группы остаются доступными для выбора из Permissions)
LocksSERVERВсе блокировки сервераДа, ограничено его репозиториями
Audit LogSERVERДаНет
DistributionSERVERДаНет (только для admin и lead)
PermissionsPROJECTДаДа, в своих репозиториях
RulesPROJECTДаДа, в своих репозиториях
WebhooksPROJECTДаДа, в своих репозиториях
FilesPROJECTДаДа, в своих репозиториях
У вкладки Files есть два представления Вкладка Files несёт два представления: Browse (просмотр файлов репозитория) и Storage (занятость диска и garbage collection). Переключение выполняется двумя кнопками в верхней части вкладки. Подробности о представлении Storage описаны в Хранилище & GC.
Вкладка Files, активно представление Browse: две кнопки Browse и Storage в верхней части вкладки, а под ними дерево файлов репозитория.

Строго за супер-администратором остаются: сброс пароля пользователя, его удаление и переключатель Активен / Неактивен, управление группами, аудит, панель мониторинга и список репозиториев, распределение, настройки сервера, глобальная статистика и лицензия. Зато project_admin может создать учётную запись и изменить email и роль учётных записей, не являющихся супер-администраторами: см. Пользователи.

Возможности на уровне всего сервера

Возможность является именованным разрешением (например «публиковать сборки», «утверждать изменения»), привязанным к роли, а не к человеку или папке. Важный момент: возможность действует на всём сервере, у неё нет измерения по репозиториям. Два практических следствия:

  • lead, обладающий возможностью manage_rules, имеет доступ к Распределению на всём сервере.
  • project_admin не обладает никакой возможностью: его власть исходит из списка проектов, которыми он управляет, а не из возможности. Это сделано намеренно, возможность нельзя ограничить одним проектом.