Ограниченые справочники по ролям

Для того чтобы строить подобные схемы, нужно хорошо понимать саму логику системы.

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

Т.е для настройки системы нужно обладать достаточными знаниями в том, как работает система, чтобы крутить какой либо алгоритм. (Все мы учимся на своих же ошибках, возьмите тестовый стенд и колдуйте над ним).

По теме:

Цитата
djren пишет: Пример: Справочник статусы "Новый", "зарегистрированный", "На исполнении", "Выполнено", "закрыто". Сотрудник1-роль1-Видит только "Новый", "зарегистрированный" Сотрудник2-роль2-видит только "На исполнении", "Выполнено", "закрыто"

В настройках роли указываем доступные статусы.

Цитата
djren пишет:и т.д. по другим справочникам.

– зависит от логики. Все изменения в системе нужно настраивать согласно существующей логике.

Цитата
djren пишет: А вообще воозможность этой логики в General relation type возможно?

Какой именно это логике? Если говорить о «Статусах» - то этот механизм есть штатный в разделе «Роль». Если речь идет о других категориях которые нужно ограничивать, то не всегда полезно использовать данный механизм.

Определять роль можно не только методикой раздела «Роль». Есть множество способов, один из Шаблоны

Каждой роли можно присвоить свои шаблоны, сл-но можно и строить логику на основании этого.