Чтобы роли были проще, понятнее, и читабельнее.

Имитация CLS может

А зачем?

ну этим принципом в БСП по ходу и пользовались :)

Даже не знаю как ответить :)

Я в третий раз повторю. Ты смешиваешь техническую реализацию и интерфейс по настройке.
Сделать новый интерфейс чтобы было легко их настраивать - можно только поприветствовать. Неважно, как оно там устроено внутри. Ты можешь сделать простой интерфейс для настройки.

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

Ты ведь не делал замеров производительности своего RLS под высокой конкурентной загрузкой?

чтобы меня по ним вообще не трогали. Вот он двигатель

а что в нем моего? раньше все конфигурации работали на том механизме который мне по душе,, и там не было предупреждения - типо включая эту галочку - вы существенно замедлите скорость работы программы :)

> Очень часто возникают задачи установки сложных ролей, по куче принципов
Хорошо бы подробнее понять о каких задачах и принципах идет речь.
Нередко, особенно начинающие почти всегда на правах и rls пытаются построить бизнес-логику, что в принципе неверно, например, бизнес-процесс: добавил заявку, а изменить больше не можешь - так делать нельзя.
> в том числе и с частичным запретов редактирования конкретных реквизитов по условию документа.
Этого нужно избегать по-максимуму. По сути это управление видимостью и доступность и делать это нужно прямо в форме, а не с помощью ролей (кроме того, роли не дают безопасности в данном случае, так как объект целиком "приезжает" на сторону клиента).
Если нужна безопасность, тогда нужно делить объект на 2 части или более (разные таблицы или программный доступ через привилегированный режим при наличии дополнительных прав)
То есть смысл в том, чтобы как раз не делать лишних ролей, кроме основной пары, иначе все равно будет тьма ролей, только сильно нестандартных, то есть с непонятно каками правами, а анализ прав крайне трудоемкая задача (какой бы отчет не был)

> Плюс шаблон не общий, а у каждой роли свой.
Это уже не БСП, а платформа - все хотят общий шаблон, но нет его
> Кроме этого - нет возможности читать РЛС, т.е. типо РЛС есть, а какие там ограничения - а хз.
RLS на конкретное право таблицы либо есть либо нет, а если есть то во всех ролях одинаковый (это стандарт), то есть перетыкивать ничего не нужно. Кроме того, в новом RLS логика ограничения вообще в модулях менеджеров уже.

А потом стали внедрять на крупных проектах и поняли что старый RLS не тянет.

@DitriXNew была нереализованная идея. Включаем тех жуонал, протыкиваем функционал под полными ролями. Парсим. Получаем список метаданных для включения в роль

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

Мне по прежнему не понятно, зачем делать больше 1 роли на 1 объект

Я тут по другому сделать хочу, хочу чтобы был анализ по метаданным от объекта, ну типо ты дал право просмотра документа, добавил это в профиль, программа бежит и проверяет все связанные данные, и если к чему то нет доступа - то предупреждает. Но это глубоко в планах.
Но и твоя идея интересна, однако, тут без программиста хрен справишься :)

проблема в запросах. Узнать какие метаданные трогаются в конкретном процессе тяжело.

Ну как минимум - Чтение, Просмотр, Изменение, и История

Это самые частые запросы

Изивини, но тут фигня написана какая то :)