Что-нибудь делал нормальные RLS на чтение, через парсинг типовых ролей.
Т.е. выгрузку их в XML, там обработать, добавить свои шаблоны - и вуаля!?

"Т.е. выгрузку их в XML, там обработать, добавить свои шаблоны - и вуаля!?" - делал
"Что-нибудь делал нормальные RLS на чтение, через парсинг типовых ролей." - это как?

(1) роли можно выгрузить в XML и там пропарсить

"Что-нибудь делал" какое пренебрежение, какое уничижение!1

(3) "Кто-нибудь"

(2) а цель какая? Чем типовое "Все ограничения доступа" не устроило?

(0) Да. http://devtool1c.ucoz.ru/index/redaktor_ogranichenija_dostupa/0-67

Сейчас РЛС пишется в модулях менеджеров

"нормальные RLS на чтение" - а какое нормальное?

(6) это через парсинг? Нужно через командную строку. Обновились - прогнали конфу, нужные дефиниции встали в RLS
(8) нормальные, это не от 1С. ;-) Самописные.

Я вот, кстати, давно просил 1С вместо "бантиков" сделать программную генерацию RLS.

(7) RLS на чтение? Рилли?
(5) не гибкое.

(9) так они и сделали

(10) да на чтение. это новый производительный вариант

(6) плохо документашка написана. По картинке не понятен принцип редактирования RLS

(12) а как он работает на регистрах накопления?

ну например, если надо отфильтровать по контрагенту движения документов реализации?

примерно так

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
    
    Ограничение.Текст =
    "РазрешитьЧтениеИзменение
    |ГДЕ
    |    ЗначениеРазрешено(Склад)";
    
КонецПроцедуры

(16) RLS стало возможно менять программно? или там в коде RLS зашито обращение к каким-либо регистрам?

(16) это платформенная шняга? На ИТС что-то не пишется про версию релиза, с которой работает

https://its.1c.ru/db/bsp301doc#content:1758:1

Я выкидывал типовые RLS и писал свои, берущие данные из настроек прав БСП, но с ограниченной функциональностью.

(20) добавлял новые роли или заменял в шаблонах? меня интересует решение, удобное при обновлениях типовых

(21) Добавлял новые. Это для нетленки было.

Мне кажется, проще оставить типовые роли, на них многое завязано. Но выгрузить их в XML, убить там все ненужные RLS на чтение, подменить своими. Ну а изменения контролировать конечно же подписками, а не RLS.

(22) понятно. Меня больше интересует в контексте, чтобы можно было нормально обновлять релизы.

(16) Хм... А каким механизмом платформы потом применяется программно сформированное ограничение доступа?

(25) это не платформенное, это БСП. но мне тоже любопытно, как они сырой текст втсавляют в запрос RLS

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

(27) Понятно. То есть это просто правила заполнения регистров доступных данных.

(27) Я такое встречал в Документообороте, потом поднял проект в одно рыло на 100 часов по переписыванию рассчетных прав доступа на динамические. Тупиковый путь.

Вот они, RLS, родимые, в выгруженных файлах конфигурации:

<object>
        <name>InformationRegister.МестонахождениеОСБухгалтерскийУчет</name>
        <right>
            <name>Read</name>
            <value>true</value>
            <restrictionByCondition>
                <condition>#Если &amp;ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляРегистра("ИдентификаторыОбъектовМетаданных.РегистрСведенийМестонахождениеОСБухгалтерскийУчет", "Организация", "", "", "", "")
#Иначе
// ОсновноеУсловиеЧтение
// Можно читать если есть доступ к (по или)
// Организации
#ПоЗначениям("РегистрСведений.МестонахождениеОСБухгалтерскийУчет", "Чтение", "",
"Организации", "Организация",
"","",
"","",
"","",
"","","","","","","","",
"","","","","","","","",
"","","","","","","",""
)
#КонецЕсли</condition>
            </restrictionByCondition>
        </right>
        <right>
            <name>View</name>
            <value>true</value>
        </right>
    </object>