что такое rls в 1с
Настройка RLS в 1С — ограничение доступа на уровне записей
Ранее мы рассматривали настройку ролей пользователей в системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).
Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.
1С RLS (Record Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.
Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).
Преимущества ограничения прав на уровне записей в 1С
Основное преимущество — наличие механизма вообще, механизм достаточно сложный и интересный. Позволяет очень тонко разграничить права пользователей — пользователи могут даже не догадываться о существовании в системе других данных.
Недостатки 1С 8 RLS
Среди недостатков можно отметить заметное падение производительности системы. Это вызвано тем, что платформа при построении запроса в базе данных осложняет любой запрос разработчика дополнительными условиями.
Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.
Настройка ограничения прав на уровне записей 1С RLS
Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:
##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли
По сути, этот запрос каждый раз добавляется при запросе к таблице «#ТекущаяТаблица». Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.
Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — «Параметры сеансов«. Как правило, они задаются при старте сессии пользователя.
Конструктор ограничения доступа к данным
Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:
Другие статьи по 1С:
Пример настройки RLS:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS
1. Права доступа.
На самом деле все очень просто. В 1С по умолчанию запрещено всё, что не разрешено. Есть только одна сущность, отвечающая за доступ пользователя к какой-либо функциональности или данным. Эта сущность называется «Право доступа». Она является единственным элементом, отвечающим за доступ к конкретному режиму работы, справочнику, реквизиту.
Количество видов прав доступа предопределено платформой. Всего платформе есть две основные группы прав доступа. Общие для всей системы права доступа к механизмам платформы, отвечающие за доступ к определенным режимам работы платформы (Администрирование, Монопольный режим, Тонкий клиент,Интерактивное открытие внешних отчетов. ). И объектные права доступа, позволяющие работать с различными объектами конфигурации. Их количество зависит от типа объекта конфигурации. Например, у справочника есть 16 различных видов доступа (Чтение, Добавление, Изменение, Удаление. ). Для регистра сведений видов доступа всего пять. Все эти права можно установить только на уровне справочника целиком. Также можно ограничить доступ на уровне реквизитов. Но в этом случае доступна лишь часть видов прав (для справочников это права Просмотр и Редактирование).
Все права доступа связаны между собой и зависят друг от друга. Есть права более высокого и более низкого уровня. Нельзя дать право более низкого уровня, если у пользователя нет права на действия более высокого уровня.
Рассмотрим права доступа к справочнику. На данной схеме видно, что большинство прав является уточнением более общих прав. Если Право1 полностью расположено на схеме внутри прямоугольника другого Права2, то Право1 не может быть выдано без выдачи Права2. Самым общим правом является право «Чтение». Если право «Чтение» отсутствует, то недоступны и все остальные права. Если недоступно право «Добавление», то нельзя установить право «Интерактивное добавление». Однако, систему прав нельзя назвать полноценной иерархией. Например, право «Редактирование» можно дать лишь при наличии прав «Просмотр» и «Изменение». Но можно дать «Просмотр» без «Изменение» или «Изменение» без «Просмотр».
Право доступа это минимальная единица доступа. Все управление доступом сводится к выдаче пользователю нужного набора прав. Остальные объекты (роли, группы доступа) это просто дополнительная обвязка, служащая для группировки и более удобной выдачи прав доступа.
Рассмотрим схему назначения пользователям прав доступа, используемую в большинстве типовых конфигураций. В упрощенном виде ее можно представить следующим образом. Вводятся новые сущности «Профиль доступа» и «Группа доступа». В каждый профиль доступа включается несколько ролей. И каждому пользователю назначается одна или несколько групп доступа. Далее каждая группа доступа связывается с профилем доступа. В итоге мы получаем возможность указывать для пользователя не просто роли, а комплекты ролей в зависимости от выполняемых им функций.
С технической точки зрения данная система выдачи прав реализовывается с участием двух стандартных подсистем. Подсистема «Управление доступом» используется для настройки связи групп доступа с предопределенными в конфигурации ролями. Подсистема «Пользователи» используется для настройки связей пользователей ИБ с группами доступа конфигурации.
3. «Логика разрешений» как правило пересечения ролей.
Важно понимать, что в 1С общая логика управления доступом это логика разрешений. В платформе 1С вообще нет никаких механизмов запрета доступа. Есть только механизмы выдачи доступа. По умолчанию доступ ко всем данным запрещен, и настройка доступа заключается в выдаче каждому пользователю нужных ему прав. Это означает, что если какой-то ролью пользователю дано право на просмотр документов «Реализация товаров», то никакими способами нельзя это право отнять другими ролями или любыми другими механизмами платформы и конфигурации. Можно изначально выдать не полный доступ к справочнику, а отфильтровать с помощью RLS данные, на которые мы даем доступ. Но если доступ уже выдан, то забрать его другими ролями уже нельзя.
Именно поэтому при ограничении ролями доступа пользователям к справочнику очень важно проверять, что пользователю не назначена никакая другая роль на тот же справочник. Иначе первая роль даст нужный доступ, который не сможет запретить вторая.
В платформе есть возможность дать пользователю дополнительные права на время выполнения отдельной операции. Эта возможность называется «Привилегированный режим». Он позволяет пользователю выполнять действия над данными, которые ему не доступны. Однако, в платформе нет возможности даже временно уменьшить имеющиеся у пользователя права.
4. Косвенное управление доступом.
Есть отдельные механизмы, который хоть и не предназначены напрямую для управления доступом, косвенного на него влияют и могут использоваться для дополнительных ограничений. Рассмотрим их основные возможности.
4.1. Функциональные опции.
К системе управления доступом иногда относят механизм функциональных опций. Это не совсем верно, так как функциональные опции никак не влияют на доступ к данным. Это исключительно интерфейсный механизм, предназначенный для упрощения интерфейса для пользователя. Он появился в платформе 8.2 как результат усложнения функционала конфигураций. Функциональные опции предназначены для скрытия из интерфейса функционала, не используемого в данной конкретной компании или данным конкретным пользователем. Механизм влияет только на отображение данных. Из интерфейса исчезают команды, а на формах скрываются реквизиты, отключенные функциональными опциями. При этом у пользователя остается доступ ко всем этим командам и реквизитам. Он может без каких-либо проблем работать со скрытыми данными программно при помощи обработок.
Подробнее о работе с функциональными опциями можно почитать на ИТС
4.2. RLS (Record Level Security)
Все перечисленные выше механизмы влияют именно на предоставление доступа к объектам вцелом. К справочникам, документам, реквизитам справочников. Права доступа влияют на доступ к объектам, функциональные опции на отображение объектов в интерфейсе. Часто возникает задача разрешить пользователю доступ к данным справочника или документа. Но не ко всем данным, а лишь к их части. Например, разрешить доступ к документам реализации только по одной организации.
Для настройки такого разрешения есть дополнительный механизм RLS (Record Level Security). Как и следует из названия, этот механизм контроля доступа на уровне конкретных записей таблиц. Если права доступа дают доступ к таблицам вцелом (справочникам) или колонкам таблиц (реквизитам), то RLS определяет конкретные строки таблиц (записи), с которыми разрешено работать пользователю. Он позволяет определить данные, которые пользователю доступны.
С учетом общей сложности механизмов обычно достаточно сложно разобраться, что именно доступно конкретному пользователю типовой конфигурации. Для проверки выданных прав в типовых конфигурациях есть очень удобный отчет, который так и называется «Права доступа». Он анализирует все выданные пользователю права и отображает итоговый список прав выданный всеми группами доступа с учетом фильтров RLS.
4.3. Разделение данных.
Еще один механизм, который влияет на доступ к данным, это разделение данных. Этот механизм предназначен для ведения в одной физической базе данных нескольких независимых баз, имеющих общую конфигурацию и общие справочники. В отдельных очень ограниченных случаях этот механизм может рассматриваться как управление доступом. При его включении каждый пользователь может работать лишь в какой-то одной своей независимой базе, но использовать при этом общие данные.
В каком-то общем смысле этот механизм можно считать тоже фильтром на данные и частным случаем реализации RLS. В отличии от RLS разделение гораздо более жесткий механизм. И благодаря этой жесткости у разработчиков есть техническая возможности дополнительными индексами сделать такую фильтрацию без свойственных RLS замедлений работы.
Фактически RLS это просто дополнительные отборы, добавляемые автоматически к каждому запросу к базе данных. Разделение данных это добавление разделителя во все разделенные таблицы и их индексы, в том числе в кластерный. Данные группируются в разрезе разделителя, т.е. физически перераспределяются по диску в отдельные группы по каждому значению разделителя. Благодаря этому каждый пользователь работает только со своими данными, и серверу не нужно при каждом запросе физически просматривать всю таблицу. Достаточно просмотреть только область данных текущего раздела.
Однако именно из-за этого физического перераспределения данных, при работе полноправного пользователя, у которого нет фильтра по значениям разделителя, все запросы выполняются очень и очень медленно. Без значения разделителя невозможно полноценное использования индексов, поэтому объем физически считываемых с диска и обрабатываемых при каждом запросе данных может возрастать на порядки. Соответсвенно, в реальности разделение имеет смысл, только если все постоянно работающие в базе пользователи будут работать только внутри своей области.
Подробнее о разделении данных можно почитать на ИТС, а также в блоге http://howknow1c.ru.
4.4. Программный код.
Пожалуй, наиболее универсальный способ установки дополнительных ограничений это программный код. Им можно повлиять на любые механизмы платформы. Например, разработчик для ограничения доступа к документам может добавить фильтр в форму списка документов, в форму выбора, может проверять программно возможность просмотра данных документа при открытии конкретной формы документа. Разработчик в своих отчетах может наложить фильтр при отборе данных.
Однако, программным кодом нет возможности ограничить права вцелом по конфигурации. Максимум, который разработчик может сделать, это встроить ограничения в конкретные отдельные механизмы получения данных. Благодаря тому, что в 1С используется объектная модель работы с данными, программный код может гарантированно защитить данные от изменения, добавив нужные проверки в модуль объекта. Но разработчик никак не может полностью гарантировать, что пользователь точно не сможет получить информацию о чужих документах реализации другими отчетами или обработками.
Такой принцип используется, например, в расширении «Кодан». Подключаясь к конфигурации, расширение добавляет пользовательские ограничения и проверки во все справочники и документы. Оно фильтрует данные, отображаемые пользователям в списках, проверяет доступ при просмотре или изменении данных. Обеспечивает невозможность изменения запрещенных данных. Но не может фильтровать данные в отчетах или запросах.
Всегда остаются варианты получения запрещенных данных запросом, собственной обработкой или отчетом. Разве что очень жестко ограничить перечень используемого пользователем функционала конфигурации и добавить отдельный фильтр в каждый механизм (форму, обработку, отчет, запрос), разрешенный пользователю.
4.5. Сравнение вариантов.
Попробуем кратко сравнить рассмотренные варианты дополнительного ограничения данных.
Как включить
Что при этом произойдет
1. Добавить место хранения функциональной опции: константа, реквизит справочника или ресурс регистра сведений.
2. Добавить в конфигурацию функциональную опцию и указать в ней созданное ранее место хранения.
3. Указать в свойствах функциональной опции ее состав, отметить все объекты конфигурации, которые будут от нее зависеть.
4. Включить использование функциональной опции в режиме предприятия.
1. Все объекты, включенные в состав функциональной опции, перестанут отображаться в командном интерфейсе.
2. В формах и отчетах исчезнут все скрытые опцией поля.
1. Прописать фильтры RLS в каждой роле пользователя для каждого из прав, которые нужно ограничить.
Примечание: В режиме предприятия никаких действий выполнять не нужно. Фильтры применятся автоматически.
1. Настроенный фильтр будет добавляться к каждому запросу к ИБ.
2. Данные, не подходящие под фильтр RLS нельзя будет получить никакими средствами: они не будут отображаться в формах, отчетах; не будут отбираться никакими запросами.
1. Добавить в конфигурацию общий реквизит, определеяющий состав разделяемых данных.
2. Добавит два параметра сеанса: для признака использования и текущего значения разделения данных.
3. Добавить программный код, обеспечивающий включение разделения данных и заполнения текущего значение разделителя.
1. Сразу после добавления в конфигурацию возможности разделения данных физически перестроятся таблицы, для которых добавилась возможность разделения.
2. После включения разделения.
1. Сделает именно то, что написано.
Примечание: код не влияет на конфигурацию вцелом, а лишь на конкретный механизм, для которого прописываается действие
5. Итоги.
У каждого способа настройки ограничений свои плюсы и минуса. С точки зрения технологии наиболее правильный способ это грамотное разбиение на роли. Для фильтрации доступных данных надежнее всего использование RLS. Именно для этой задачи механизм предназначен. Точечные ограничения проще всего выполнять с помощью программного кода. Функциональные опции и разделение данных достаточно специфичные механизмы, не предназначенные для ограничения доступа. Хоть в некоторых случаях и могут для этого использоваться.
Использование ограничений доступа к данным для различных объектов 1С:Предприятия 8
Этот раздел содержит информацию об особенностях использования ограничений доступа к данным, определяемых поведением различных объектов 1С:Предприятия.
О принципах функционирования ограничений доступа к данным
Основные принципы функционирования и использования ограничений доступа к данным описаны в документации 1С:Предприятия 8 и в разделе «Ограничения доступа к данным. Сведения о принципах функционирования».
Для лучшего понимания механизма проверки ограничений доступа полезно иметь в виду следующие правила:
Приведем несколько примеров.
Например, в случае простейшего ограничения вида:
ГДЕ Реквизит = &ПравильноеЗначениеРеквизита
можно считать, что для каждой записи, для которой проверяется ограничение(проверяемой записи), выполняется запрос следующего вида:
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи
ГДЕ Реквизит = &ПравильноеЗначениеРеквизита
В данной таблице доступ к записи, в которой значение реквизита «Реквизит» совпадает со значением параметра сеанса «ПравильноеЗначениеРеквизита», разрешен. К другим записям этой таблицы доступ запрещен.
Другой пример. Усложним ограничение. Допустим нужно разрешить доступ к записи таблицы «Справочник.Контрагенты» не только если ее «Реквизит» имеет «правильное значение», но и в том случае, если «правильное значение» имеет «Реквизит» родителя этой записи (1-го или 2-го уровня). В этом случае ограничение может иметь следующий вид:
Контрагенты
ИЗ Справочник.Контрагенты КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
ПО Контрагенты.Родитель = Контрагенты1.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты2
ПО Контрагенты1.Родитель = Контрагенты2.Ссылка
ГДЕ Контрагенты.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты1.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты2.Реквизит = &ПравильноеЗначениеРеквизита
Тогда запрос, который будет выполнятся в процессе проверки этого ограничения для конкретной записи справочника «Контрагенты», будет иметь вид:
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
ПО Контрагенты.Родитель = Контрагенты1.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты2
ПО Контрагенты1.Родитель = Контрагенты2.Ссылка
ГДЕ Контрагенты.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты1.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты2.Реквизит = &ПравильноеЗначениеРеквизита
Обращения по ссылкам в запросах и ограничения доступа к данным
Пусть на справочник «Контрагенты» установлено следующее ограничение доступа:
ГДЕ Ответственный = &ТекущийПользователь
а сам справочник содержит такие записи:
Ответственный
(ссылка на Справочник.Пользователи)
Пусть регистр сведений «КонтактнаяИнформация» содержит следующие записи:
КонтактноеЛицо
(ссылка на Справочник.ФизЛица)
Организация
(ссылка на Справочник.Контрагенты)
Тогда если текущим пользователем является пользователь «Иванов», то результатом запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Имя, Ответственный
ИЗ Справочник.Контрагенты
Ответственный
(ссылка на Справочник.Пользователи)
Однако, результатом следующего запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ КонтактноеЛицо, Организация
ИЗ РегистрСведений.КонтактнаяИнформация
Ответственный
(ссылка на Справочник.Пользователи)
ВЫБРАТЬ РАЗРЕШЕННЫЕ КонтактноеЛицо, Организация.Имя КАК Имя, Организация.Ответственный КАК Ответственный
ИЗ РегистрСведений.КонтактнаяИнформация
поскольку противоречащие ограничению записи справочника «Контрагенты» считаются отсутствующими, а значениями полей «Имя» и «Ответственный» по ссылкам, указывающим на несуществующие записи, является значение NULL.
Если же необходимо по тому же признаку ограничить доступ к записям регистра сведений «КонтактнаяИнформация», то на этот регистр можно наложить ограничение вида:
ГДЕ Организация.Ответственный = &ТекущийПользователь
В этом случае результатом выполнения последнего запроса будет таблица:
Ограничения и табличные части
Ограничения доступа к данным действуют только на записи таблиц верхнего уровня и не могут ограничивать доступность записей табличных частей. С другой стороны, в тексте ограничения поля табличных частей использоваться могут. В этом случае в процессе проверки ограничения для некоторой записи будет исполнен запрос, в котором табличная часть будет соединена с таблицей из одной проверяемой записи левым внешнем соединением. Таким образом запись будет удовлетворять ограничению, если в ее табличной части найдется хотя бы одна запись, для которой условие в ограничении принимает значение «Истина».
Из соображений эффективности в ограничениях доступа к данным нельзя использовать агрегатные функции. Поэтому возможности участия в ограничениях доступа к данным каких-нибудь условий на совокупности записей табличных частей не предусмотрено. Подобная цель может быть достигнута посредством запросов, вложенных в ограничения, однако пользоваться этим необходимо с осторожностью из-за возможного снижения производительности.
Например, если документ «Накладная» содержит табличную часть «Состав», то ограничения доступа к этому документу проверяются при обращении к каждой накладной, как к единому целому и не могут разрешить доступ к какой-нибудь одной записи его табличной части «Состав», а к какой-нибудь другой запретить.
Пусть таблица «Документ.Накладная» содержит следующие записи:
Контрагент
(ссылка на Справочник.Контрагенты)
Состав (табличная часть)
В этом случае запрос, исполняемый для каждой накладной в процессе проверки следующего ограничения:
ГДЕ Состав.Количество > 50
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи КАК Накладная
ЛЕВОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ Документ.Накладная.Состав КАК Состав
ПО Накладная.Ссылка = Состав.Ссылка
ГДЕ Состав.Количество > 50
Следовательно доступ будет разрешен только для записи «Трикотажная фабрика». Поэтому запрос:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Контрагент, Состав.(Номенклатура, Количество)
ИЗ Документ.Накладная
а запрос к вложенной таблице:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Контрагент, Номенклатура, Количество
ИЗ Документ.Накладная.Состав
поскольку ограничение накладывается только на записи верхнего уровня, но не на записи табличных частей.
Если нужно разрешить доступ еще и к тем накладным, у которых состав пустой, то ограничение может быть модифицировано так:
ГДЕ Состав.Количество > 50 ИЛИ Состав.Количество ЕСТЬ NULL
Если же необходимо разрешить доступ только к тем накладным, у которых в табличной части «Состав» нет записей с «Количеством», превышающем 50, то в ограничении необходимо использовать вложенный запрос:
Все операции над объектами встроенного языка 1С:Предприятия выполняются в режиме «ВСЕ» (без использования режима «РАЗРЕШЕННЫЕ»). Для успешного получения разрешенных объектов в соответствующих методах объектов необходимо указывать отборы, не противоречащие ограничениям. Например, если на чтение из регистра сведений «КонтактнаяИнформация» установлено ограничение вида:
ГДЕ Тип = &ТипКонтактнойИнформации»
то для успешного выполнения метода
необходимо установить отбор:
Если ограничение доступа сложное и не может быть сформулировано в терминах отборов, то использование выборки (метод Выбрать() ) и аналогичных оказывается невозможным. В этом случае следует использовать запросы. Проектирование разграничения доступа к данным таким образом, чтобы ограничения могли быть сформулированы в терминах отборов, позволит использовать объекты встроенного языка с максимальной гибкостью.
Виртуальные таблицы запросов
При использовании в запросах без ключевого слова РАЗРЕШЕННЫЕ виртуальных таблиц в условиях установленных ограничений доступа к данным необходимо указывать отборы, не противоречащие ограничениям не только для запроса в целом, но и для виртуальных таблиц. Например:
ВЫБРАТЬ
КонтактнаяИнформацияСрезПервых.Представление
ИЗ
РегистрСведений.КонтактнаяИнформация.СрезПоследних(, Тип = &Тип ) КАК КонтактнаяИнформацияСрезПервых
ГДЕ
КонтактнаяИнформацияСрезПервых.Тип = &Тип
Выделенный отбор по виртуальной таблице «СрезПоследних» может содержать произвольное логическое выражение, допустимое для раздела ГДЕ, использующее поля, которые присутствуют в виртуальной таблице.