В том, что доступность определяется теперь не только запросом к самому объекту, а по отдельной таблице

основное отличие нового рлс - права на объекты не рассчитываются каждый раз в рантайме, а заранее, и в рлс остается максимально простой шаблон - выбрать разрешенные из Т левое соединение "регистр с правами" где "регистрсправами".пользователь = &ТекущийПользователь

против многокилометровых по пять раз вложенных запросов

Пользователь в этом регистре - ведущее измерение?

не помню. но какая разница, если по нему есть индекс?

Ну то есть, шаблон таки начинает попадать в индекс и за счёт этого быстрее, все берётся из одной таблицы, есть в регистре - нет ограничения, нет - есть

Ясно. Делали такое лет 5 назад в какой-то нетленке... Обновление наборов прав приходилось каждые 5 минут запускать. Ничего нового, одним словом

У нас и сейчас, в другой нетленке, есть похожий механизм для срезов цен и остатков по ключам аналитики, где ключ аналитики - хэш от всех измерений этих регистров... И тоже надо каждые 5-10 минут запускать пересчет

Жертвуем актуальностью данных ради скорости

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

У нас также, подписки на события записи новых/существующих ключей в регистрах цен и остатков

И это все начиная с бсп 3.0?

в продакшене - да. самому решению тоже больше пяти лет

Ясно, спасибо. Не знал

Все актуально и быстро. Не в транзакции рассчитываются только зависимые права на подчиненные таблицы. См. ответы на партнерке.

Угу... Создание партнера в режиме обмена (любое копирование) + создание подчиненного контрагента (в любом режиме, естественно с подчинением созданному).
По пробуйте кто нибудь.... Контрагента ограниченный пользователь не увидит.

Поэтому с надежностью пока какая-то задница. На свежем релизе воспроизвести ситуацию пока трудоемко.

Когда константа ОграничиватьДоступНаУровнеЗаписейУниверсально включена, тогда при изменении объектов (или наборов записей), в том числе в режиме ОбменДанными.Загрузка = Истина, происходит обновление ключей доступа к объектам (или к регистрам), которое необходимо для корректной проверки прав доступа для неполноправных пользователей. Это добавляет, как правило, 5–20 мс на 1 объект или набор записей, что при записи большого числа «легких» объектов может быть существенным замедлением. Чтобы сократить эти затраты, следует отключить обновление ключей доступа на период загрузки, а затем включить (при включении произойдет планирование обновления ключей доступа для таблиц, в которые внесены изменения с момента отключения). Таким образом общие затраты на загрузку будут снижены, а обновление ключей доступа будет выполнено в фоне, что более эффективно, если объектов много, так как в фоне обновление ключей доступа выполняется пакетно, а не по одному. Для отключения обновления ключей доступа предусмотрена процедура ОтключитьОбновлениеКлючейДоступа общего модуля УправлениеДоступом (примеры см. в комментарии к процедуре).

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

вообще принципиальной разницы для СУБД нет.
Цепляется ветка И Истина в (РЛС)
Только в новом РЛС - это соедиение двух таблиц. Все это превращяется в один EXISTS. Который замедляет основную выборку например в 5 раз, но это не критично. Например основной поток 0,2 сек, а ветка РЛС - еще 1 сек.
А в старом текст РЛС это портянка из 5+ кажется таблиц. Это не просто мутные соединения. Это мутные многоуровневые соединения. В итоге это вложенные EXISTS. Количество выполнений в плане запроса в превращается в миллионы, десятки миллионов. Фактическое время выполнения узлов РЛС (это видно в 2019 скуле) может уже составлять 30 сек, 60 сек и т.д. в зависимости от размера потока первичных данных.
В итоге основной профит от нового рлс это максимальное упрощение РЛС-ветки.