Всем привет!

В БСП, УТ 11 и т.д. контактную информацию перенесли в табличные части, хотя ранее всегда это было на отдельном регистре.
Главной причиной такого решения, насколько я понял из всеобщего холивара по данной теме, было требование к безопасности Контактной информации.

Однако вот вопрос - в этом случае невозможно ограничить доступ на уровне RLS к отдельным видам информации. Хотя в реальной жизни в управленческих целях гораздо чаще приходится ограничивать доступ именно к ним.
Например, справочник сотрудников - доступ к нему нужен практически для всех сотрудников. Служебные/Внутренние телефоны, чаты и т.п. нужно видеть всем сотрудникам. А паспортные данные явно и категорически нельзя видеть практически никому. И получается, что ограничить доступ к паспортным данным на уровне RLS нельзя никак в принципе. Это в целях безопасности что ли?....

Что я понимаю не так?

Контактная информация в ЗУП 3 = табличная часть ФизическиеЛица. Но там в этой информации паспортных данных нет.
И есть регистр сведений ДокументыФизическихЛиц права чтения на этот регистр обрезаны.
Осталось только рассмотреть, какой там шаблон ограничения доступа к нему установлен.

(0) Не надо хранить паспортные данные в контактной информации. Как выше написали про ЗУП, в УТ11 для паспортных данных отдельный регистр.

РегистрСведений.ДокументыФизическихЛиц    ЧтениеДанныхФизическихЛицЗарплатаКадры    Чтение    <Прочие поля>    "#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляРегистра(""ИдентификаторыОбъектовМетаданных.РегистрСведенийДокументыФизическихЛиц"", ""Физлицо"", """", """", """", """")
#Иначе
#ПоЗначениям( ""РегистрСведений.ДокументыФизическихЛиц"",""Чтение"","""",
""ГруппыФизическихЛиц"",""Физлицо"",
"""","""","""","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""" )
#КонецЕсли"

Это в ЗУП 3.1
Предположу, что во всем БСП сделано или точно также или почти также

Собственно ключевой вопрос - "Зачем Табличная часть?" Какой в ней смысл вообще в принципе и зачем сделали отдельную часть у каждого справочника, к которому никак не пристроить отдельный доступ, вместо единого регистра, на котором доступ прекрасно рулился?

Ну т.е. первая реакция - "НА КОЙ Х....Р, КАРЛ????!!!!". Но головой понимаю, что должны же были руководствоваться какими-то здравыми рассуждениями, когда это делали. Вот и хочу понять - Зачем? Чего я не знаю или не понимаю?

(4) как раз рлс писать по отдельным объектам куда проще для тч, чем для регистра

ну и паспортные данные не хранятся в КИ.
Если вы их туда запихали - ССЗБ

(5) Эммм... Так ведь и я так думал, пока не столкнулся и не запилил табличную часть.... А потом оказалось, что:
"Ограничения и табличные части
Ограничения доступа к данным действуют только на записи таблиц верхнего уровня и не могут ограничивать доступность записей табличных частей."
https://its.1c.ru/db/metod8dev#content:2316:hdoc

Вот и спрашивается, зачем делать такую структуру, на которой нельзя организовать доступ по РЛС?

(4) С точки зрения производительности и по блокировкам всегда лучше много маленьких табличек, чем одна большая. Да и чисто логически - какая связь между данными контрагентов и еще хрень пойми кого? Зачем они нужны в одной таблице?
Ну да - RLS на строки табличной части не натянешь. Боль вполне понимаю и разделяю. Могли бы не в ТЧ запихивать, а в отдельные справочники/регистры.

(7) можно наложить рлс на вид ки и само ки не получать автоматом в форме

(9) А если для другого вида объекта доступ по этому виду контактной информации нужен? Не, если нужно разграничивать по видам КИ, то с ТЧ беда.

(10) + А, стоп. Для разных видов объекта создаются разные виды КИ... Но все равно костыль костыльный.

(10) (11) - Во-во! И как объяснить собственнику, что ему нельзя ограничить доступ сотрудников к разной контактной информации только потому, "Что так в типовой БСП сделано..." Бред какой-то....

(8) - Да, тут можно было бы о чем-то рассуждать - несколько подчиненных справочников, или один регистр сведений. Есть и свои плюсы и свои минусы. Но так, как сделано - это же КАРЛ?!?!? ЗАЧЕМ КАРЛ?!??!?

Написать расширение для установки отбора строк табличной части в зависимости от ролей задача пустяковая.

А так у ф/л, сотрудника теоретически может быть масса элементов КИ: телефоны, мейлы, мессенжеры и т.д. посему
хранить это в ТЧ ссылки вполне логично.

Ну в общем еще один случай убедиться, что БСП в целом и структура контактной информации не создана для решения управленческих задач