|
БСП и доступ к контактной информации. Что?.... | ☑ | ||
---|---|---|---|---|
0
Buckbister
06.10.19
✎
22:18
|
Всем привет!
В БСП, УТ 11 и т.д. контактную информацию перенесли в табличные части, хотя ранее всегда это было на отдельном регистре. Главной причиной такого решения, насколько я понял из всеобщего холивара по данной теме, было требование к безопасности Контактной информации. Однако вот вопрос - в этом случае невозможно ограничить доступ на уровне RLS к отдельным видам информации. Хотя в реальной жизни в управленческих целях гораздо чаще приходится ограничивать доступ именно к ним. Например, справочник сотрудников - доступ к нему нужен практически для всех сотрудников. Служебные/Внутренние телефоны, чаты и т.п. нужно видеть всем сотрудникам. А паспортные данные явно и категорически нельзя видеть практически никому. И получается, что ограничить доступ к паспортным данным на уровне RLS нельзя никак в принципе. Это в целях безопасности что ли?.... Что я понимаю не так? |
|||
1
Фрэнки
07.10.19
✎
09:14
|
Контактная информация в ЗУП 3 = табличная часть ФизическиеЛица. Но там в этой информации паспортных данных нет.
И есть регистр сведений ДокументыФизическихЛиц права чтения на этот регистр обрезаны. Осталось только рассмотреть, какой там шаблон ограничения доступа к нему установлен. |
|||
2
Smile 8D
07.10.19
✎
09:23
|
(0) Не надо хранить паспортные данные в контактной информации. Как выше написали про ЗУП, в УТ11 для паспортных данных отдельный регистр.
|
|||
3
Фрэнки
07.10.19
✎
09:55
|
РегистрСведений.ДокументыФизическихЛиц ЧтениеДанныхФизическихЛицЗарплатаКадры Чтение <Прочие поля> "#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляРегистра(""ИдентификаторыОбъектовМетаданных.РегистрСведенийДокументыФизическихЛиц"", ""Физлицо"", """", """", """", """") #Иначе #ПоЗначениям( ""РегистрСведений.ДокументыФизическихЛиц"",""Чтение"","""", ""ГруппыФизическихЛиц"",""Физлицо"", """","""","""","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""", """","""" ) #КонецЕсли" Это в ЗУП 3.1 Предположу, что во всем БСП сделано или точно также или почти также |
|||
4
Buckbister
07.10.19
✎
15:52
|
Собственно ключевой вопрос - "Зачем Табличная часть?" Какой в ней смысл вообще в принципе и зачем сделали отдельную часть у каждого справочника, к которому никак не пристроить отдельный доступ, вместо единого регистра, на котором доступ прекрасно рулился?
Ну т.е. первая реакция - "НА КОЙ Х....Р, КАРЛ????!!!!". Но головой понимаю, что должны же были руководствоваться какими-то здравыми рассуждениями, когда это делали. Вот и хочу понять - Зачем? Чего я не знаю или не понимаю? |
|||
5
pechkin
07.10.19
✎
15:59
|
(4) как раз рлс писать по отдельным объектам куда проще для тч, чем для регистра
|
|||
6
pechkin
07.10.19
✎
15:59
|
ну и паспортные данные не хранятся в КИ.
Если вы их туда запихали - ССЗБ |
|||
7
Buckbister
07.10.19
✎
16:11
|
(5) Эммм... Так ведь и я так думал, пока не столкнулся и не запилил табличную часть.... А потом оказалось, что:
"Ограничения и табличные части Ограничения доступа к данным действуют только на записи таблиц верхнего уровня и не могут ограничивать доступность записей табличных частей." https://its.1c.ru/db/metod8dev#content:2316:hdoc Вот и спрашивается, зачем делать такую структуру, на которой нельзя организовать доступ по РЛС? |
|||
8
fisher
07.10.19
✎
16:15
|
(4) С точки зрения производительности и по блокировкам всегда лучше много маленьких табличек, чем одна большая. Да и чисто логически - какая связь между данными контрагентов и еще хрень пойми кого? Зачем они нужны в одной таблице?
Ну да - RLS на строки табличной части не натянешь. Боль вполне понимаю и разделяю. Могли бы не в ТЧ запихивать, а в отдельные справочники/регистры. |
|||
9
pechkin
07.10.19
✎
16:16
|
(7) можно наложить рлс на вид ки и само ки не получать автоматом в форме
|
|||
10
fisher
07.10.19
✎
16:18
|
(9) А если для другого вида объекта доступ по этому виду контактной информации нужен? Не, если нужно разграничивать по видам КИ, то с ТЧ беда.
|
|||
11
fisher
07.10.19
✎
16:19
|
(10) + А, стоп. Для разных видов объекта создаются разные виды КИ... Но все равно костыль костыльный.
|
|||
12
Buckbister
07.10.19
✎
16:22
|
(10) (11) - Во-во! И как объяснить собственнику, что ему нельзя ограничить доступ сотрудников к разной контактной информации только потому, "Что так в типовой БСП сделано..." Бред какой-то....
(8) - Да, тут можно было бы о чем-то рассуждать - несколько подчиненных справочников, или один регистр сведений. Есть и свои плюсы и свои минусы. Но так, как сделано - это же КАРЛ?!?!? ЗАЧЕМ КАРЛ?!??!? |
|||
13
unenu
07.10.19
✎
16:36
|
Написать расширение для установки отбора строк табличной части в зависимости от ролей задача пустяковая.
А так у ф/л, сотрудника теоретически может быть масса элементов КИ: телефоны, мейлы, мессенжеры и т.д. посему хранить это в ТЧ ссылки вполне логично. |
|||
14
Buckbister
07.10.19
✎
22:09
|
Ну в общем еще один случай убедиться, что БСП в целом и структура контактной информации не создана для решения управленческих задач
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |