Support Forum

[olegko]

Максим выше уже предлагал завести для всех пользователей универсальную роль. Разовью мысль.
Я делал достаточно много конфигураций TrackStudio под разные нужды и пришел к такому шаблону: учетные записи пользователей в системе создаются только с одной ролью: Пользователь (исключение - Администратор системы, но это уже built-in). Для роли "Пользователь" настраиваются права в духе "нельзя вообще ничего, кроме смены пароля". В дальнейшем при настройке создаются роли согласно бизнес-процессам, как для управления задачами, так и, отдельно, для управления пользователями. И уже для этих ролей настраиваются права доступа, разрешения на выполнение операций и т.п.
Затем реальные пользователи назначаются на проекты уже с этими ролями через переопределение или расширение. Для назначения сразу нескольких пользователей они формируются в иерархию (и тогда права доступа на задачу должен назначать пользователь-узел иерархии для своих подчиненных, прямо через роль "Пользователи").

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

Добавлю от себя в тему о назначении ролей.
1) Нужно разделять пользовательские (дефолтные) роли и проектные роли.
Очень часто бывает, что юзеры имеют доступ к проектам не с дефолтными ролями. И в таком случае имеем две роли - у дефолтной роли реально используется только "юзерская" часть, а у проектной - только "проектная" часть настроек.

2) Создавать всех юзеров с одной дефолтной ролью возможно и подойдёт для небольших организаций.
Но для больший организаций обычно:
- юзеров сотни, которые делятся на разные команды
- разные команды должны иметь разный доступ на разные проекты
- и при этом юзеры могут переходить их одной команды в другую
- роль одтельной комадны в проекте может меняться
В таком случае управлять назначением на проект удобнее на уровне ролей (а не по каждому юзеру отдельно).

Поэтому исходя из 1) и 2) логичным будет в следующей мажорной версии TS ввести два типа ролей - пользовательсткие и проектные.
И ещё было бы хорошо получить возможность "прикреплять" проектные роли к юзерским ролям.

[sekob]

На мой взгляд про типы ролей, (для себя я называю глобальная и локальная с привязкой к задаче) лучше почетче в документации отразить. Сейчас там этого нет. Информация только на форуме проскакивала. Если на начальном этапе корректно не настроить, то потом при разрастании будут разные грабли.

[mvasenkov]

На мой взгляд про типы ролей, (для себя я называю глобальная и локальная с привязкой к задаче) лучше почетче в документации отразить. Сейчас там этого нет. Информация только на форуме проскакивала. Если на начальном этапе корректно не настроить, то потом при разрастании будут разные грабли.

Задача такая у меня записана, отразим

[mvasenkov]

2) Создавать всех юзеров с одной дефолтной ролью возможно и подойдёт для небольших организаций.
Но для больший организаций обычно:
- юзеров сотни, которые делятся на разные команды
- разные команды должны иметь разный доступ на разные проекты
- и при этом юзеры могут переходить их одной команды в другую
- роль одтельной комадны в проекте может меняться
В таком случае управлять назначением на проект удобнее на уровне ролей (а не по каждому юзеру отдельно).

А я про это выше и писал: делайте структуру пользователей иерархической:
контора - отдел - группа - пользователь
При этом "контора", "отдел" и "группа" - могут быть не реальные, а фантомные (ну или я их еще суррогатными называю) пользователи. От них даже пароль можно забыть.
Тогда чтобы сделать команду - нужно завести пользователя как подчиненного в группе. Чтобы назначить кого-то руководителем группы, нужно ему дать права доступа через ACL на корень этой группы. Перевод пользователя из одной команды в другую осуществляется с помощью операции cut/paste в списке пользователей.
Права же на проект для команды (а не для отдельного пользователя) назначаются именно через роль Пользователь (с переопределением), но делать это должен либо руководитель группы, либо, что менее удобно, зато более надежно, руководитель или администратор, залогиненные через суррогатного пользователя (они это со своим паролем могут сделать).
При раздаче прав через роль они распространяются на всех подчиненных пользователя, который раздает права.

[mvasenkov]

Вообще про настройку прав доступа надо кино снимать, все никак руки не дойдут.

[olegko]

А я про это выше и писал: делайте структуру пользователей иерархической:
контора - отдел - группа - пользователь
При этом "контора", "отдел" и "группа" - могут быть не реальные, а фантомные (ну или я их еще суррогатными называю) пользователи. От них даже пароль можно забыть.
Тогда чтобы сделать команду - нужно завести пользователя как подчиненного в группе. Чтобы назначить кого-то руководителем группы, нужно ему дать права доступа через ACL на корень этой группы. Перевод пользователя из одной команды в другую осуществляется с помощью операции cut/paste в списке пользователей.
Права же на проект для команды (а не для отдельного пользователя) назначаются именно через роль Пользователь (с переопределением), но делать это должен либо руководитель группы, либо, что менее удобно, зато более надежно, руководитель или администратор, залогиненные через суррогатного пользователя (они это со своим паролем могут сделать).
При раздаче прав через роль они распространяются на всех подчиненных пользователя, который раздает права.

Расскажу как у нас организовано:
1) Первый нюанс в том, что организационная (юзерская) иерархия слабо связана с проектной иерархий.
Это означает, что два юзера в одном проекте могут иметь отношение "Начальник1" <> "Подчинённый1", а во втором - "Подчинённый2" <> "Начальник2"
==> Выделить локальных руководителей на уровне иерархии пользователей не получается (так, чтобы они не имели "лишних" прав). Вариант, что один и тот же юзер может иметь разные юзерские аккаунты на разные проекты я исключаю.
==>> Полноценно управлять правами доступа в такой структуре может только один (главный) админ

2) У нас сейчас более 600 пользователей, которые представляют около 60 команд. Разные команды должны иметь разный доступ к около 100 проектам-подпроектам.
==> Назначать права на проекты каждому юзеру отельно крайне неэффективно (особенно учитывая периодически изменяющиеся требования к правам доступа и переходы между отделами)
==>> Логично будет закрепить за каждой командой отдельную роль (дефолтную) и права на проект давать целой роли (связывать дефолтную роль команды с одной из проектных ролей).
==>>> Какие плюсы такого решения:
- При создании нового юзера не нужно отельно давать ему права на проекты команды (он получает их автоматом, как носитель командной роли).
- Переход юзера из одной команды в другую сводится к переопределению дефолтной роли - в таком случае юзер автоматом теряет права на проекты старой команды и получает права на проекты новой команды
- Ну и управлять правами доступа на уровне ролей команды гораздо эффективнее, чем на уровне каждого юзера отдельно
- И ещё - плюсом является то, что по дефолтной роли юзера можно определить к какой команде он принадлежит (имеется ввиду показ ролей юзеров в Assignee)

Я описал общую идею. Есть конечно исключения, когда права на проект даются конкретному юзеру - но именно в тех случаях, когда это нужно одному-двум юзерам со специфическими правами.