1с ограничение доступа к данным по реквизитам

RLS в 1C - ограничения доступа на уровне записей

Классическая задача: открыть пользователю доступ к какому-либо объекту, но не ко всем элементам / документам, а только к некоторым.

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

Или это может быть ограничение “все, кроме некоторых”.
Или ограничение не на справочники/документы, а на данные регистров

Например, чтобы пользователи ни одним отчетом не могли вытащить данные по выплатам партнерам.

По сути – это тонкая и очень гибкая настройка “что можно видеть этому пользователю, а о чем ему и не нужно догадываться”.

Почему именно RLS?

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

Это либо требования конфиденциальности, либо чтобы не испортить данные, за которые пользователь не отвечает и, возможно, даже не разбирается в них (например, бухгалтерские данные для менеджера по продажам).

В конфигурациях за возможные права доступа к данным отвечают специальные объекты метаданных – роли. Каждому пользователю информационной базы назначается одна или несколько ролей. Они определяют, возможны ли операции с конкретными объектами метаданных (чтение, запись, проведение и т.д.).

Но это не все.

Часто бывает необходимо не просто открыть/запретить доступ к определенному объекту, а ограничить доступ к части данных в нем.

Только при помощи ролей решить такую задачу нельзя – для этого реализован механизм ограничения доступа на уровне записей (RLS).

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

Про RLS – более подробно: 8 видео и PDF

Поскольку это распространенная задача администрирования 1С – предлагаем посмотреть более детальные материалы:

PDF с вводной информацией.

21 страница, которые нужно прочесть сначала.

Видео 01:

01. Ограничение доступа к данным при помощи ролей

Ограничение доступа к данным при помощи ролей

В этом видео рассказывается, как ограничивается доступ к данным при помощи ролей. Уточняется, что роли ограничивают доступ к виду объектов информационной базы (отдельный справочник, но не конкретные элементы справочника).

Видео 02:

02. Ограничение доступа на уровне записей (RLS)

Ограничение доступа на уровне записей (RLS)

В этом видео рассказывается о механизме ограничений доступа на уровне записей (RLS), когда можно настроить доступ не ко всему справочнику в целом, а к отдельным его элементам, в зависимости от хранящихся в информационной базе данных. Подобные ограничения прописываются в ролях.

Видео 03:

03. Реализация ограничения доступа на уровне записей для справочника Контрагенты

Реализация ограничения доступа на уровне записей для справочника Контрагенты

В этом видео рассказывается, как в демонстрационной конфигурации «Управляемое приложение» настроить доступ менеджеров только к собственным контрагентам, закрепленным за ними.

Видео 04:

04. Принцип работы ограничений доступа на уровне записей на низком уровне

Принцип работы ограничений доступа на уровне записей на низком уровне

В этом видео рассказывается, как платформа трансформирует запросы, передаваемые для выполнения на сервер СУБД, при наличии ограничений доступа на уровне записей.

Видео 05:

05. Совместное применение нескольких ограничений доступа на уровне записей

Совместное применение нескольких ограничений доступа на уровне записей

Пользователю информационной базы может быть назначено несколько ролей. При этом в каждой роли могут быть свои ограничения доступа на уровне записей. В этом видео рассказывается, как ведет себя система при наложении ограничений.

Видео 06:

06. Наложение ограничений методом ВСЕ

Наложение ограничений методом ВСЕ

В этом видео описывается первый способ наложения ограничений на уровне записей – метод ВСЕ. При этом, если в выборку попадают записи, к которым доступ ограничен, будет выведено сообщение об ошибке.

Видео 07:

07. Наложение ограничений методом РАЗРЕШЕННЫЕ

Наложение ограничений методом РАЗРЕШЕННЫЕ

В этом видео описывается первый способ наложения ограничений на уровне записей – метод РАЗРЕШЕННЫЕ. При этом в выборку попадут только те записи, к которым у пользователя есть права доступа.

Видео 08:

08. Исправление ошибки, возникающей из-за наложения прав доступа на уровне записей

Исправление ошибки, возникающей из-за наложения прав доступа на уровне записей

В этом видео рассматривается, как при помощи ключевого слова РАЗРЕШЕННЫЕ исправить ошибку, возникающую под пользователем с ограниченными правами.

Не пропустите – все сразу и в полном объеме!

Этот курс позволит решать ВСЕ задачи по развертыванию и поддержке информационных систем на 1С.

Вот несколько тем из курса:

  • Установка и обновление платформы «1С:Предприятие 8» – ручная и автоматическая, под Windows и Linux
  • Автоматический запуск для выполнения регламентных операций
  • Обновление конфигураций из пользовательского режима
  • Обновление нетиповых конфигураций. Как избежать проблем при обновлении измененных типовых конфигураций
  • Создание собственных cfu-файлов поставки
  • Инструменты БСП: внешние формы, обработки заполнения документов и т.п.
  • Использование бесплатной СУБД PostgreSQL
  • Установка и запуск кластера серверов 1С:Предприятие 8
  • Утилита администрирования для настройки кластера и рабочих серверов
  • Настройка RLS на примере УПП 1.3 и ERP 2
  • Что делать, если данные в ИБ повреждены
  • Настройка обменов данными между конфигурациями
  • Организация групповой разработки
  • Настройка и использование аппаратных ключей защиты
  • Программные лицензии 1С: установка и привязка к внешнему оборудованию

Этот курс актуален для всех, кто внедряет или поддерживает 1С.

Даже на 3-5 пользователей. Тем более – если их хотя бы десяток…

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

И лучше это сразу делать правильно.

Чтобы потом не было “…! Ну что за …! Твою же …!” – и прочих выражений сожаления :)

Курс по Администрированию систем на 1С.
Описание курса, программа и оформление заказа

Кроме того, у нас появился специализированный курс – Настройка и доработка прав доступа, профилей пользователей и RLS в типовых конфигурациях УТ 11.4 (11.3), КА 2.4 (2.2) и 1C:ERP 2.4 (2.2).

 Ограничение доступа к данным

Механизм ограничений доступа к данным (также известный как RLS, Row Level Security) позволяет управлять правами доступа не только на уровне объектов метаданных, но и на уровне объектов базы данных «1С:Предприятия». Для ограничения доступа к данным могут быть использованы следующие объекты «1С:Предприятия»:
● роли,
● параметры сеанса,
● функциональные опции,
● привилегированные общие модули,
● ключевое слово РАЗРЕШЕННЫЕ в языке запросов.
Совместное использование перечисленных объектов позволяет обеспечить максимальную гибкость при необходимости разграничения прав доступа к данным между  пользователями, выполняющими различные функции.
Ограничения доступа к данным могут накладываться на следующие операции с данными (права доступа): чтение (право Чтение), добавление (право Добавление), изменение (право Изменение) и удаление (право Удаление). Текущий пользователь будет иметь возможность выполнить требуемую операцию в следующих случаях:
● Для операций чтения и удаления объект, находящийся в базе данных, должен соответствовать ограничению доступа к данным.
● Для операции добавления ограничению доступа к данным должен соответствовать объект, который планируется записать в базу данных.
● Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан).
При наложении ограничений доступа к данным следует помнить, что для операций изменения, добавления и удаления можно задать только одно условие, а для операции чтения можно задать более одного ограничения доступа к данным. Это означает, что для чтения разных полей объекта могут быть заданы разные условия, причем при задании условия можно указать как имя конкретного поля, так и специальное поле Прочие поля. В первом случае условие будет накладываться только в том случае, если в выборке (которой выполняется чтение данных) будет присутствовать поле, для которого задано ограничение, а во втором – ограничение будет накладываться для всех полей объекта, кроме полей, для которых ограничения заданы явным образом.
При задании ограничения на конкретное поле, это поле будет читано в том случае, если ограничение выполняется, а при задании ограничения на Прочие поля, данные объекта будут прочитаны только в том случае, если ограничение выполняется для всех полей объекта, попавших в запрос чтения данных.
Для объектов базы данных следующих видов могут быть наложены различные ограничения на разные виды изменений (добавление, модификацию, удаление):
● Планы обмена,
● Справочники,
● Документы,
● Планы видов характеристик,
● Планы счетов,
● Планы видов расчета,
● Бизнес-процессы,
● Задачи.
Для следующих видов объектов базы данных возможно наложение ограничений на чтение не только всего объекта целиком, но и отдельных его полей:
● Планы обмена,
● Справочники,
● Документы,
● Журналы документов,
● Планы видов характеристик,
● Планы счетов,
● Планы видов расчета,
● Регистры сведений,
● Бизнес-процессы,
● Задачи.
ВНИМАНИЕ! При обращении к полям объектов базы данных посредством свойств прикладных объектов из встроенного языка «1С:Предприятия» выполняется чтение всего объекта целиком, а не только значения используемого поля. Исключением является получение представления, когда будут прочитаны только значения полей, участвующих в формировании представления.
Ограничения доступа содержатся в ролях, они могут быть указаны для большинства объектов метаданных и записываются на специальном языке, являющимся подмножеством языка запросов.

Язык ограничения доступа к данным

Ограничения доступа к данным описываются на специальном языке, являющимся подмножеством языка запросов (подробное описание языка запросов . Язык ограничения доступа к данным имеет следующие изменения относительно языка запросов:
● В запросе ограничения доступа к данным всегда присутствует одна таблица в качестве источника данных – это таблица объекта, на который накладывается ограничение (основной объект ограничения).
● Сокращено описание запроса. Язык ограничения доступа к данным использует только секции ИЗ и ГДЕ языка запросов. Так, описание языка запросов выглядит следующим образом:
ВЫБРАТЬ [РАЗРЕШЕННЫЕ] [РАЗЛИЧНЫЕ] [ПЕРВЫЕ <Количество>]
<Список полей выборки>
[ИЗ <Список источников>]
[ГДЕ <Условие отбора>]
[СГРУППИРОВАТЬ ПО <Поля группировки>]
[ИМЕЮЩИЕ <Условие отбора>]
[ДЛЯ ИЗМЕНЕНИЯ [<Список таблиц верхнего уровня>]]
В то время как описание языка запросов ограничения доступа к данным выглядит следующим образом:
[Псевдоним таблицы основного объекта ограничения]
[ИЗ <Список источников>]
[ГДЕ <Условие отбора>]

Во вложенных запросах, используемых в языке ограничения доступа к данным, ограничен набор допустимых возможностей ;
● В качестве элементов условий можно указывать параметры сеанса  и функциональные опции ;
● В любом месте запроса ограничения доступа к данным допустимо использование шаблонов, упрощающих написание ограничений.
Главной частью ограничения является условие, которое вычисляется для каждой записи таблицы базы данных, на которую накладывается ограничение доступа к данным. Запись считается доступной в том случае, если в результате работы условия для одной записи таблицы основного объекта ограничения получена не пустая таблица (т.е. таблица, в которой 1 или более записей). Если в результате работы условия получается пустая таблица – запись, для которой условие исполнилось таким образом, считается недоступной. Причем изменение записи таблицы основного объекта ограничения
считается допустимым, если запись не противоречит ограничению, указанному для права, как до выполнения операции изменения, так и после выполнения этой операции.

Поля таблиц

В ограничениях доступа к данным можно использовать:
● Поля таблиц объекта, для которого описывается ограничение доступа к данным.
Например, если ограничение накладывается на чтение элементов справочника Контрагенты, то в ограничении могут использоваться поля справочника Контрагенты и его табличных частей. В частности, наиболее простые ограничения на чтение элементов справочника Контрагенты могут выглядеть так:

ГДЕ Наименование = “Кирпичный завод”
Или так:

ГДЕ Продукция.Наименование = “Кирпич красный”
Где Продукция – это табличная часть справочника Контрагенты.
● Поля таблиц объектов, доступных по ссылкам в основном объекте ограничения.
Например, если реквизит ОсновнойМенеджер справочника Контрагенты имеет тип ссылки на справочник Пользователи, то ограничение доступа может иметь, например, следующий вид:

ГДЕ ОсновнойМенеджер.Код = “Иванов”
Или:

ГДЕ ОсновнойМенеджер.ФизическоеЛицо.Наименование = “Петровский”
● Поля таблиц объектов, связанных с основным объектом ограничения некоторыми условиями и выражения над ними.
Например, на чтение элементов справочника Контрагенты может быть наложено следующее ограничение:

Контрагенты
ИЗ
Справочник.Контрагенты КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Пользователи КАК Пользователи
ПО Контрагенты.ОсновнойМенеджер.Наименование = Пользователи.Наименование
ГДЕ Пользователи.ФизическоеЛицо.Наименование = “Петровский”
В этом ограничении используются поля элементов справочника Пользователи, связанных с данным элементом справочника Контрагенты по значению полей Наименование.

Вложенные запросы

Вложенные запросы используются для формирования наборов записей, которые могут использоваться:
● для связывания с таблицей основного объекта ограничения;
● для использования в качестве операнда операций сравнения В или НЕ В.
Во вложенных запросах могут использоваться любые средства языка запросов, кроме:
● оператора В ИЕРАРХИИ;
● предложения ИТОГИ;
● результаты вложенных запросов не должны содержать табличные части;
● некоторых виртуальных таблиц, в частности ОстаткиИОбороты.
В следующем примере ограничения на чтение из справочника Контрагенты, вложенный запрос используется в качестве набора записей для связывания с основным объектом ограничения:

Контрагенты
ИЗ
Справочник.Контрагенты КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ
(ВЫБРАТЬ
Пользователи.Наименование, Пользователи.ФизическоеЛицо
ИЗ
Справочник.Пользователи КАК Пользователи
ГДЕ
Пользователи.Код > “Петечкин”) КАК Пользователи
ПО Контрагенты.ОсновнойМенеджер.Наименование = Пользователи.Наименование
ГДЕ Пользователи.ФизическоеЛицо.Наименование = “Петровский”
В следующем примере приведено ограничение на чтение из справочника ПаспортныеДанныеФизЛиц, в котором вложенный запрос используется в
качестве операнда операции сравнения В:

ГДЕ
ПаспортныеДанныеФизЛиц.ФизЛицо В
(ВЫБРАТЬ РАЗЛИЧНЫЕ
Работники.ФизЛицо КАК ФизЛицо
ИЗ
РегистрСведений.Работники КАК Работники)
Если во вложенном запросе необходимо получить данные из табличной части, то в разделе ИЗ вложенного запроса необходимо обращаться непосредственно к табличной части. Например, вместо:

ВЫБРАТЬ Ссылка КАК Ссылка,
Продукция.Наименование КАК НаименованиеПродукции
ИЗ Справочник.Контрагенты
в качестве запроса, вложенного в ограничение, следует использовать:

ВЫБРАТЬ Ссылка КАК Ссылка,
Наименование КАК НаименованиеПродукции
ИЗ Справочник.Контрагенты.Продукция

Параметры сеанса

В составе запросов ограничения доступа к данным могут входить параметры сеанса. Например, на чтение элементов справочника ГруппыПисемЭлектроннойПочты может быть задано следующее ограничение доступа:

ГДЕ Владелец.ДоступКУчетнойЗаписи.Пользователь = &ТекущийПользователь
И Владелец.ДоступКУчетнойЗаписи.Администрирование = ИСТИНА

ТекущийПользователь   –  это параметр сеанса

Функциональные опции

В составе запросов ограничения доступа к данным могут входить функциональные опции. Могут использоваться только не зависящие от параметров функциональные опции. Например, если у справочника Номенклатура есть реквизит ОсновнойСклад, то ограничение на чтение данного реквизита может выглядеть следующим образом:

ГДЕ &УчетПоСкладам = ИСТИНА

Где УчетПоСкладам – это функциональная опция

Особенности использования

В ограничениях на объекты базы данных следующих типов могут быть использованы не все поля основного объекта данных ограничения:
● в регистрах накопления ограничения доступа могут содержать только измерения основного объекта ограничения;
● в регистрах бухгалтерии в ограничениях можно использовать только балансовые измерения основного объекта ограничения.
ПРИМЕЧАНИЕ. Если в условиях ограничения доступа к данным оборотного регистра накопления используются измерения, не входящие в итоги, то
при обращении к виртуальной таблице оборотов не используются хранимые итоги и запрос выполняется полностью по таблице движений.

Действия ограничения доступа

Ограничения доступа проверяются при любом выполнении соответствующих операций над объектами базы данных (из диалогов, из встроенного языка, посредством запросов) и могут действовать одним из двух способов:
Все. Способ «все» подразумевает, что некоторая операция над данными (из диалогов, из встроенного языка или посредством запросов) должна быть выполнена над всеми подразумеваемыми данной операцией объектами базы данных. Если при выполнении такой операции должны быть прочитаны или изменены объекты базы данных, для которых не выполняются соответствующие ограничения доступа, то операция завершается
аварийно из-за нарушения прав доступа.
Разрешенные. Способ «разрешенные» подразумевает, что при выполнении операции над данными должны быть прочитаны только те объекты базы данных, которые удовлетворяют соответствующим ограничениям доступа. Объекты базы данных, не удовлетворяющие ограничениям доступа, при выполнении такой операции считаются отсутствующими и на результат операции не влияют.
Ограничения доступа к данным накладываются на объекты базы данных в момент обращения «1С:Предприятия» к базе данных. В клиент-серверном варианте «1С:Предприятия» наложение ограничений выполняется на сервере «1С:Предприятия».
Способ действия ограничений, выбираемый для выполнения каждой операции над данными, определяется назначением этой операции и степенью ответственности ее результатов. В частности, способ «разрешенные» используется при отображении динамических списков и некоторых других интерактивных действиях. Способ «все» используется при выполнении любых операций с прикладными объектами из встроенного языка «1С:Предприятия», в том числе при любых изменениях объектов базы данных. Поэтому, например, могут возникнуть затруднения при построении отбора для метода Выбрать() менеджеров справочников, документов и других с последующим обходом результата в том случае, если на соответствующий объект установлено достаточно сложное ограничение, поскольку не всякое условие в ограничении прав доступа может быть адекватно представлено в виде отбора для метода Выбрать().
В запросах способом действия ограничений доступа к данным можно управлять. Для этого в языке запросов предусмотрено ключевое слово РАЗРЕШЕННЫЕ. Если в запросе не указано РАЗРЕШЕННЫЕ, то ограничения действуют способом «все». Если слово РАЗРЕШЕННЫЕ указано, то выбирается способ «разрешенные».
Важно, что если в запросе не указано ключевое слово РАЗРЕШЕННЫЕ, то все отборы, заданные в этом запросе, не должны противоречить ни одному из ограничений на чтение объектов базы данных, используемых в запросе. При этом если в запросе используются виртуальные таблицы, то соответствующие отборы должны быть наложены и на сами виртуальные таблицы.
Пример:

ВЫБРАТЬ
КонтактнаяИнформацияСрезПервых.Представление
ИЗ РегистрСведений.КонтактнаяИнформация.СрезПоследних(, Тип = &Тип)
КАК КонтактнаяИнформацияСрезПервых
ГДЕ
КонтактнаяИнформацияСрезПервых.Тип = &Тип
При использовании объектной техники не поддерживается получение доступа к данным в режиме РАЗРЕШЕННЫЕ. Предполагается, что объектная техника используется для наиболее ответственных операций над данными, в том числе для их изменения. Для получения при помощи объектной техники всех данных, независимо от установленных ограничений, можно выполнять необходимые действия в привилегированном модуле или от имени пользователя с полными правами. Средств получения только разрешенных данных в объектной технике не предусмотрено.

Механизм наложения ограничений

Любая операция над данными, хранимыми в базе данных, в «1С:Предприятии» в конечном счете приводит к обращению к базе данных с некоторым
запросом на чтение или изменение данных. В процессе исполнения запросов к базе данных внутренние механизмы «1С:Предприятия» выполняют наложение ограничений доступа. При этом:
● Формируется список прав (чтение, добавление, изменение, удаление), список таблиц базы данных и список полей, используемых этим запросом.
● Из всех ролей текущего пользователя выбираются ограничения доступа к данным для всех прав, таблиц и полей, задействованных в запросе. При этом если какая-нибудь роль не содержит ограничений доступа к данным какой-нибудь таблицы или поля, то это значит, что в данной таблице доступны значения требуемых полей из любой записи. Иначе говоря, отсутствие ограничения доступа к данным означает наличие ограничения
ГДЕ Истина.
● Получаются текущие значения всех параметров сеанса и функциональных опций, участвующих в выбранных ограничениях.
Для получения значения параметра сеанса от текущего пользователя не требуется наличие права на получение этого значения. Однако если значение некоторого параметра сеанса не было установлено, то произойдет ошибка и запрос к базе данных выполнен не будет.
На получение функциональных опций оказывает влияние свойство функциональной опции Привилегированный режим при получении .
Если это свойство сброшено, то текущий пользователь должен обладать правами на чтение объекта, в котором хранится функциональная опция.
● Ограничения, полученные из одной роли, объединяются операцией И.
● Ограничения, полученные из разных ролей, объединяются операцией ИЛИ.
● Построенные условия добавляются к SQL-запросам, с которыми «1С:Предприятие» обращается к СУБД. При обращении к данным со стороны условий ограничения доступа проверка прав не выполняется (ни к объектам метаданных, ни к объектам базы данных). Причем механизм добавления условий зависит от выбранного способа действия ограничений «все» или «разрешенные».
Способ «все»
При наложении ограничений способом «все» к SQL-запросам добавляются условия и поля так, чтобы «1С:Предприятие» могло получить информацию о том, были ли в процессе исполнения запроса к базе данных использованы данные, запрещенные для данного пользователя или нет. Если запрещенные данные были использованы, то инициируется аварийное завершение запроса. Наложение ограничений доступа способом «все» схематически представлено на рис. 1:

Рис. 1. Способ «все»

Способ «разрешенные»
При наложении ограничений способом «разрешенные» к SQL-запросам добавляются такие условия, чтобы запрещенные текущему пользователю записи не оказывали влияния на результат запроса. Иначе говоря, при наложении ограничений в режиме «разрешенные» запрещенные данному пользователю записи считаются отсутствующими,что схематически представлено на рис 3

 Другие объекты, связанные с ограничениями доступа к данным

При разработке конфигураций с использованием ограничений доступа к данным могут оказаться полезными такие объекты метаданных, как параметры сеанса, функциональные опции и общие модули с флажком Привилегированный.
Параметры сеанса
Параметры сеанса могут использоваться в ограничениях доступа к данным аналогично тому, как в запросе могут использоваться параметры запроса.
Функциональные опции
Не зависящие от параметров функциональные опции могут использоваться в ограничениях доступа к данным аналогично тому, как в запросе могут использоваться параметры запроса.
Привилегированные общие модули

Если для общего модуля установлен флажок Привилегированный, то исполнение процедур и функций этого модуля приобретает важную специфику:
● В клиент-серверном варианте «1С:Предприятия» привилегированным может быть только тот модуль, который исполняется на сервере.
● Исполнение процедур и функций привилегированного модуля и всего, что из них вызвано, выполняется при выключенной системе ограничения
прав, как к объектам метаданных, так и к данным. Таким образом, из привилегированного модуля может быть выполнена любая операция над
любыми объектами даже в том случае, если текущий пользователь не имеет соответствующих прав.
Привилегированные модули предназначены для начальной установки значений параметров сеанса, используемых в ограничениях доступа к данным.
Еще общие модули могут быть использованы для некоторых целостных действий над данными со стороны пользователя с ограниченными правами.
Например, если в функции пользователя входит ввод и проведение документов, но пользователь не должен иметь доступа к данным, на которые влияет проведение документа, то выполнение операции проведения может быть вынесено в привилегированный модуль. Это позволит пользователю проводить документы без предоставления ему прав на другую информацию (регистры, например).
Привилегированный режим
Имеется возможность программной установки привилегированного режима при работе с данными. Программная установка привилегированного режима
может потребоваться в случае массированных операций с данными информационной базы, и при этом нет смысла проверять права доступа к данным.
Описание привилегированного режима см. здесь.

 Использование препроцессора

При редактировании текста ограничения доступа к данным возможно использование инструкций препроцессора. Доступны следующие инструкции:

#ЕСЛИ <Выражение> #ТОГДА
#ИНАЧЕЕСЛИ <Выражение> #ТОГДА
#ИНАЧЕ
#КОНЕЦЕСЛИ
<Выражение> – произвольное логическое выражение на встроенном языке, результат которого имеет тип Булево. Выражение может содержать:
● операции сравнения <, >, <=, >= , =, <>;
● логические операции И, ИЛИ, НЕ;
● параметры сеанса – используется синтаксис &Параметр, где Параметр – имя параметра сеанса.
Если результатом выражения инструкции #ЕСЛИ или #ИНАЧЕЕСЛИ является значение Истина, то в результирующий текст инструкции ограничения доступа помещается текст, расположенный после ключевого слова #ТОГДА. Если же результатом выражения является значение Ложь, то текст, расположенный после ключевого слова #ТОГДА, не помещается в текст инструкции ограничения доступа. Текст, расположенный после инструкции #ИНАЧЕ, будет помещен в результирующий текст ограничения доступа, если ни одно из ранних условий не было выполнено.
ПРИМЕЧАНИЕ. Если текст ограничения доступа к данным содержит инструкции препроцессора, то такое ограничение не проходит проверку синтаксиса при редактировании и не может быть изменено при помощи конструктора.
Пример:

#ЕСЛИ &ТекущийПользователь <> “Климова” #ТОГДА
<текст ограничения доступа>
#КОНЕЦЕСЛИ
Здесь ТекущийПользователь – параметр сеанса типа СправочникСсылка.Пользователи.
Такая конструкция означает, что условие для установки ограничения доступа будет проверяться для всех пользователей из справочника, кроме пользователя Климовой.

Шаблоны текста ограничения доступа

Роль может содержать список шаблонов ограничения доступа, которые описываются на закладке Шаблоны ограничений формы роли. Также шаблоны ограничения доступа можно редактировать в редакторе группового редактирования ограничений доступа и шаблонов .
Каждый шаблон ограничения доступа имеет имя и текст. Имя шаблона подчиняется обычным правилам для имен, принятых в системе «1С:Предприятие».
Текст шаблона содержит часть текста на языке ограничения доступа к данным и может содержать параметры, которые выделяются при помощи символа
“#”.
После символа “#” могут следовать:
● Одно из ключевых слов:
● Параметр, после которого в скобках указывается номер параметра в шаблоне;
ТекущаяТаблица – обозначает вставку в текст полного имени таблицы, для которой               строится ограничение;
ИмяТекущейТаблицы – обозначает вставку в текст полного имени таблицы (как                        строковое значение, в кавычках), к которой применяется инструкция, на текущем                  варианте встроенного языка;
● ИмяТекущегоПраваДоступа – содержит имя права, для которого выполняется                         текущее ограничение: ЧТЕНИЕ/READ, ДОБАВЛЕНИЕ/INSERT, ИЗМЕНЕНИЕ/
          UPDATE, УДАЛЕНИЕ/DELETE;
● имя параметра шаблона – означает вставку в текст ограничения соответствующего параметра шаблона;
● символ “#” – обозначает вставку в текст одного символа “#”.

В выражении ограничения доступа могут содержаться:

● Шаблон ограничения доступа, который указывается в формате
#ИмяШаблона(“Значение параметра шаблона 1”, “Значение параметра шаблона 2”, …). Каждый параметр шаблона заключается в двойные кавычки. При необходимости указания в тексте параметра символа двойной кавычки следует использовать две двойные кавычки.
● Функция СтрСодержит(ГдеИщем, ЧтоИщем). Функция предназначена для поиска вхождения строки ЧтоИщем в строке ГдеИщем. Возвращает Истина в случае, если вхождение обнаружено и Ложь – в противном случае.

● Оператор + для конкатенации строк.
Для удобства редактирования текста шаблона на закладке Шаблоны ограничений в форме роли нужно нажать кнопку Установить текст шаблона. В открывшемся диалоге ввести текст шаблона и нажать кнопку ОК.
Система «1С:Предприятие» выполняет проверку синтаксиса текстов шаблонов, проверку синтаксиса использования шаблонов и макроподстановку текстов шаблонов ограничения доступа роли в текст запроса.
Макроподстановка шаблона заключается:
● в замене вхождений параметров в тексте шаблона на значения параметров из выражения использования шаблона в тексте ограничения;
● в замене выражения использования шаблона в тексте запроса на получившийся текст шаблона.
При вызове конструктора запроса для условия, содержащего шаблоны ограничения доступа, выдается предупреждение о замене всех шаблонов.
Далее приведены примеры шаблонов ограничений:

Общие рекомендации по ограничению прав

Чтобы гибко управлять доступом пользователей к данным в соответствии с функциями при установке ограничений доступа к данным, рекомендуется
придерживаться следующих принципов:
● Нужно выбрать совокупность информации (может быть зависимой от текущего пользователя), для которой целесообразна предварительная подготовка. Выбранная информация должна, с одной стороны, максимально упростить ограничения доступа к данным, а с другой стороны, не должна иметь слишком большой объем. Распределить ее по параметрам сеанса.
● Установить значения параметров сеанса в обработчике УстановкаПараметровСеанса() модуля сеанса.
● Задать ограничения доступа к тем данным, для которых это оправданно (данные являются секретными или наиболее важными для сохранения целостности системы). Необходимо иметь в виду, что установка ограничения доступа может привести к замедлению любого обращения к этим данным. Излишняя сложность ограничений также может привести к замедлению.
● При необходимости обеспечить выполнение некоторого ограниченного количества операций над данными со стороны пользователя, которому полный доступ к этим данным давать нецелесообразно, вынести эти действия в привилегированные модули или явно включать и выключать привилегированный режим в соответствующих местах программного кода.
● Доступ к данным при различных проверках, выполняемых системой при записи объектов, выполняется в привилегированном режиме.

Это позволяет не отключать ограничения в правах на уровне записей для соответствующих полей, если работа конфигурации с этими данными
планируется только в управляемом режиме:

● для справочников при проверке родителя, владельца и уникальности кода;
● для документов, бизнес-процессов и задач при проверке уникальности номера;
● для планов обмена отключена при проверке уникальности кода;
● для планов счетов и планов видов характеристик при проверке родителя и уникальности кода.

При создании запроса ограничения к данным следует помнить о некоторых ограничениях и особенностях:

● Если для объектной таблицы заданы ограничения доступа к данным и в запросе к данным используется объединение с такой таблицей, то в условии соединения (секция запроса ПО) не допускается использование табличной части объекта с заданным ограничением доступа.
● Если в запросе указана таблица, у которой в запросе не используется ни одного поля, то на эту таблицу накладываются все ограничения доступа к данным. Например, запрос ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ Справочник.Контрагенты будет исполнен с учетом всех ограничений доступа, заданными для справочника Тест. Ограничения накладываются «по ИЛИ». Это значит, что будут доступны все записи, доступные хотя бы по одному условию. Если для каких-то полей не задано условий, то запрос будет выполнен для всех записей таблицы.
Если в запросе используется таблица верхнего уровня, то ограничения, заданные для колонок вложенных таблиц, не накладываются.
Если в запросе используется вложенная таблица, то накладываются ограничения как для вложенной таблицы, так и для таблицы верхнего уровня.
Например, запрос ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ Справочник.Контрагенты.Договора будет исполнен с учетом всех ограничений для справочника Контрагенты, а также с учетом ограничений, относящихся к табличной части Договора.

● Если доступ к полям, необходимым для получения представления ссылочного объекта метаданных, запрещен с помощью ограничений доступа к
данным или доступ к объекту запрещен на уровне прав доступа, то получение представления такого объекта не влияет на ход текущей транзакции.

Конструктор ограничения доступа к данным

Для вызова конструктора в табличном поле Ограничения доступа к данным в колонке Ограничение доступа нужно перейти в режим редактирования и
нажать кнопку выбора, а в открывшейся форме нажать кнопку Конструктор запроса….
На экран выводится форма конструктора:

Рис. 3. Закладка «Таблицы и поля» конструктора ограничений

С его помощью производится формирование условий для установки ограничения доступа к данным.
На закладке Таблицы и поля следует выбрать нужные объекты в списке База данных и перенести их в список Таблицы. Если указано несколько таблиц, то в форме конструктора добавляется закладка Связи.

Рис. 4. Закладка «Связи» конструктора ограничений

На закладке Связи формируются условия, которые накладываются на связи между полями таблиц. Для ввода нового условия нужно нажать кнопку Добавить и в колонке Таблица1 выбрать одну из таблиц. В колонке Таблица2 выбрать таблицу, поля которой связаны с полями первой. Ниже списка условий расположены элементы управления, с помощью которых формируется условие связи таблиц.
Если выбран простой тип условия, то в Поле1 и Поле2 выбираются связанные поля указанных таблиц и задается условие сравнения. Если выбраны поля, сравнение которых не производится, то в строке списка условий в колонке Условие связи выводится текст: Неверно заполненное условие.
На закладке Условия, если требуется, нужно указать условия, по которым будет выполняться отбор исходных данных.

Рис. 5. Закладка «Условия» конструктора ограничений

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

Групповое редактирование ограничений прав доступа и шаблонов

Режим группового редактирования ограничений прав доступа и шаблонов вызывается командой Все ограничения доступа контекстного меню ветки Роли. В открывшейся форме присутствуют две закладки: Ограничения доступа и Шаблоны ограничений.

Рис. 6 Все ограничения прав доступа и шаблоны

На закладке Ограничения доступа можно просматривать все введенные ограничения доступа в общем списке (по всем ролям, объектам, правам,комбинациям полей).
Существует возможность добавлять ограничение доступа сразу для нескольких ролей, объектов, прав и комбинаций ролей.
Можно фильтровать список по различным критериям.

Рис. 7. Отбор ограничений доступа

Режим группового редактирования позволяет удалять выделенные в списке ограничения.
Существует возможность редактировать выделенные ограничения. При этом можно заменять состав полей и/или ограничение доступа.
Режим группового редактирования позволяет также копировать выделенные ограничения в другие роли.

На закладке Шаблоны ограничений можно видеть все шаблоны ограничения доступа, присутствующие в прикладном решении, при этом из собственно текста шаблона в таблице отображаются только первые 10 строк, которые завершаются символом “…”, если текст шаблона более 10 строк. В окне редактирования шаблона будет отображаться полный текст шаблона.

Рис 8. Все шаблоны ограничения доступа

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

Рис. 9. Отбор шаблонов ограничения доступа

При необходимости имеется возможность выполнить копирование одного или нескольких шаблонов в другие роли.

1С RLS

Роли, права доступа

Объект конфигурации «роль» дает набор прав на операции (действия) над объектами конфигурации.

Роль «Полные права».

Это всего лишь роль (не предопределенная), в которой установлены флажки на все виды прав на все объекты конфигурации.

Отличие ее от остальных ролей – наличие права «Администрирование».

В случае создания хотя бы одного пользователя, система начинает проверять наличие права «Администрирование»  — оно должно быть минимум у одного пользователя.

Ограничение доступа на уровне записей

Row Level Security (RLS) – ограничение на уровне записей.

Механизм ограничений доступа к данным позволяет управлять правами доступа не только на уровне объектов метаданных, но и на уровне объектов базы данных. Для ограничения доступа к данным могут быть использованы следующие объекты:

  • роли,
  • параметры сеанса,
  • функциональные опции,
  • привилегированные общие модули,
  • ключевое слово РАЗРЕШЕННЫЕ в языке запросов.

Механизм предназначен для ограничения доступа к записям таблицы объектов метаданных по произвольным условиям, накладываемым на значения полей строк этих таблиц. Например, чтобы видеть записи только по «своим» контрагентам, организациям и т.д.

1С формирует запрос к СУБД. Кластер серверов добавляет к запросу секцию ГДЕ, в которой содержится текст условия на ограничение доступа по RLS, затем этот запрос отправляется в СУБД, извлеченные данные возвращаются на клиент 1С.

Упрощенная схема работы механизма RLS в 1С

Такой механизм будет работать при любом запросе из клиента:

  • в отчетах,
  • в динамических списках и в обычных формах списков
  • в произвольных запросах.

Подобная реализация механизма сильно влияет на производительность.

Пути обхода ограничений доступа.

В больших ресурсоемких операциях (обработки перепроведения документов, например) часть кода можно выносить в привилегированные модули.

А) Привилегированный модуль — это общий модуль с флагом «Привилегированный» в свойствах.

Его особенность заключается в том, что код в нем исполняется без какого-либо контроля прав доступа, в том числе и RLS.

Флаг Привилегированный

Б) Также привилегированный режим можно включить для модулей объектов документов. Это делается в свойствах документа, флаг

  • Привилегированный режим при проведении
  • Привилегированный режим при отмене проведения

Привилегированный режим в документах 1С

В) Метод УстановитьПривилегированныйРежим()

Системная команда, позволяет сделать часть кода любого модуля привилегированной.

Со следующей строки кода будет действовать привилегированный режим исполнения.

Действовать он будет до строки отключения этого режима или до конца процедуры / функции

УстановитьПривилегированныйРежим (Истина);

// любой код тут будет исполнен без контроля прав и RLS

УстановитьПривилегированныйРежим (Ложь); // либо конец процедуры / функции

Количество включений привилегированного режима должно совпадать с количеством выключений. Однако если внутри процедуры или функции происходило включение привилегированного режима (один раз или более), но не происходило его выключение, то система автоматически выполнит выключение столько раз, сколько незавершенных включений было в покидаемой процедуре или функции

Если в процедуре или функции вызовов метода УстановитьПривилегированныйРежим(Ложь) сделано больше, чем вызовов метода УстановитьПривилегированныйРежим(Истина), то будет вызвано исключение

Функция ПривилегированныйРежим() возвращает Истина, если привилегированный режим еще включен, и Ложь, если он полностью выключен. При этом не анализируется количество установок привилегированного режима в конкретной функции.

Все вызванные процедуры и функции также будут исполняться в привилегированном режиме.

Демонстрация привилегированного режима

Также существует возможность стартовать привилегированный сеанс. Это сеанс, в котором привилегированный режим установлен с самого начала работы системы. При этом во время работы метод ПривилегированныйРежим() будет всегда возвращать Истина, а возможность отключить привилегированный режим не поддерживается. Стартовать привилегированный сеанс может только пользователь, которому доступны административные права (право Администрирование). Запуск сеанса можно выполнить с помощью ключа командной строки запуска клиентского приложения UsePrivilegedMode или параметра строки соединения с информационной базой prmod.

Привилегированный сеанс 1С

Закономерно возникает вопрос: Зачем тогда вообще настраивать ограничения доступа, если его можно так легко обойти?

Безопасный режим.

Да, можно написать внешнюю обработку с привилегированным режимом исполнения и выгрузить / испортить данные. Для предотвращения этого в системе есть метод глобального контекста

УстановитьБезопасныйРежим().

Безопасный режим кроме прочего игнорирует привилегированный режим.

Его нужно устанавливать перед программным вызовом внешних обработок или экспортных процедур и функций из их модулей.

При выполнении запрещенных операций во время выполнения генерирует исключение.

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

Настройка ограничения доступа

RLS можно настроить только для прав:

  • чтение           (select)
  • добавление (insert)
  • изменение   (update)
  • удаление     (delete)

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

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

Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан).

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

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

Это означает, что при попытке получить доступ к отмеченным флажками полям, ограничение сработает, а при попытке получить доступ к неотмеченным полям ограничение не сработает.

Если выбрать флаг «Прочие поля», ограничение будет настроено для всех полей таблицы, кроме полей, для которых ограничения заданы явным образом.

Выбор полей для ограничения доступа

*Особенность: для прав добавление, изменение, удаление:

  • Ограничение может быть настроено только для всех полей.
  • Ограничение может быть только одно.

Для права «Чтение» можно настроить несколько условий, они будут объединяться логическим оператором «И».

В ограничениях на объекты базы данных следующих типов могут быть использованы не все поля основного объекта данных ограничения:

  • в регистрах накопления ограничения доступа могут содержать только измерения основного объекта ограничения;
  • в регистрах бухгалтерии в ограничениях можно использовать только балансовые измерения основного объекта ограничения

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

Механизм наложения ограничений доступа.

Любая операция над данными, хранимыми в базе данных, в «1С:Предприятии» в конечном счете приводит к обращению к базе данных с некоторым запросом на чтение или изменение данных. В процессе исполнения запросов к базе данных внутренние механизмы «1С:Предприятия» выполняют наложение ограничений доступа. При этом:

  • Формируется список прав (чтение, добавление, изменение, удаление), список таблиц базы данных и список полей, используемых этим запросом.
  • Из всех ролей текущего пользователя выбираются ограничения доступа к данным для всех прав, таблиц и полей, задействованных в запросе. При этом если какая-нибудь роль не содержит ограничений доступа к данным какой-нибудь таблицы или поля, то это значит, что в данной таблице доступны значения требуемых полей из любой записи. Иначе говоря, отсутствие ограничения доступа к данным означает наличие ограничения ГДЕ Истина.
  • Получаются текущие значения всех параметров сеанса и функциональных опций, участвующих в выбранных ограничениях.

Для получения значения параметра сеанса или функциональной опции от текущего пользователя не требуется наличие права на получение этого значения. Однако если значение некоторого параметра сеанса не было установлено, то произойдет ошибка и запрос к базе данных выполнен не будет.

Ограничения, полученные из одной роли, объединяются операцией И.

Ограничения, полученные из разных ролей, объединяются операцией ИЛИ.

Построенные условия добавляются к SQL-запросам, с которыми «1С: Предприятие» обращается к СУБД. При обращении к данным со стороны условий ограничения доступа проверка прав не выполняется (ни к объектам метаданных, ни к объектам базы данных). Причем механизм добавления условий зависит от выбранного способа действия ограничений «все» или «разрешенные».

Принцип сложения ограничений доступа

*Особенность: Если пользователю доступны несколько ролей с настроенными ограничениями на уровне записей к одному объекту, то в этом случае условия ограничений складываются логической операцией «ИЛИ». Другими словами полномочия пользователя складываются.

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

Способ «Все».

При наложении ограничений способом «все» к SQL-запросам добавляются условия и поля так, чтобы «1С:Предприятие» могло получить информацию о том, были ли в процессе исполнения запроса к базе данных использованы данные, запрещенные для данного пользователя или нет. Если запрещенные данные были использованы, то инициируется аварийное завершение запроса из-за нарушения прав доступа.

Наложение ограничений доступа способом «все» схематически представлено на рисунке:

Схема доступа к данный ВСЕ

Способ «Разрешенные».

При наложении ограничений способом «разрешенные» к SQL-запросам добавляются такие условия, чтобы запрещенные текущему пользователю записи не оказывали влияния на результат запроса. Иначе говоря, при наложении ограничений в режиме «разрешенные» запрещенные данному пользователю записи считаются отсутствующими и на результат операции не влияют, что схематически представлено на рисунке:

Схема доступа к данным РАЗРЕШЕННЫЕ

Ограничения доступа к данным накладываются на объекты базы данных в момент обращения «1С:Предприятия» к базе данных.

В клиент-серверном варианте «1С:Предприятия» наложение ограничений выполняется на сервере «1С:Предприятия».

Однако эта опция (РАЗРЕШЕННЫЕ) не сработает в случае, если мы в запросе обратимся к таблице, для которой не настроены ограничения доступа, но в которой есть ссылки на строки таблицы с настроенными ограничениями. В этом случае результат запроса выдаст «<Объект не найден>……» вместо значения ссылочного поля.

РАЗРЕШЕННЫЕ в запросе - Объект не найден

Если вы разрабатываете отчет или обработку с использованием запросов типовой или самописной конфигурации, всегда ставьте флаг «Разрешенные», чтобы отчет работал под любым пользователем с любым набором прав.

В случае объектного чтения данных из базы нет возможности поставить флаг «Разрешенные». Поэтому нужно настраивать отборы для объектного чтения с учетом возможных ограничений прав доступа для пользователя. Средств получения только разрешенных данных в объектной технике не предусмотрено.

Важно, что если в запросе не указано ключевое слово РАЗРЕШЕННЫЕ, то все отборы, заданные в этом запросе, не должны противоречить ни одному из ограничений на чтение объектов базы данных, используемых в запросе. При этом если в запросе используются виртуальные таблицы, то соответствующие отборы должны быть наложены и на сами виртуальные таблицы.

Практика 1. Конструктор запросов в настройках RLS.

Составим текст секции «ГДЕ» в запросе к справочнику. Можно воспользоваться конструктором запросов.
Конструктор имеет урезанный вид.

Вызов конструктора запросов RLS в 1С

Закладка «Таблицы»

Основная таблица будет таблицей объекта, для которого настраивается ограничение.

Можно также выбирать и другие таблицы и настраивать между ними различные связи на закладке «Связи».

Закладка «Условия»

Здесь настраиваются собственно условия ограничения доступа


Добавим условия на реквизит «Цена» справочника номенклатура для права на «чтение» ко всем полям таблицы.

«Номенклатура ГДЕ Номенклатура.Цена > 500»

Проверим, как сработает это простое правило. Таблица справочника содержит такие элементы:

Пример: Номенклатура - все элемента

После настройки ограничения доступа таблица покажет только элементы, удовлетворяющие условию:

Пример: Номенклатура - отобранные элементы

Пропали также и группы. Изменим текст ограничения

«Номенклатура ГДЕ Номенклатура.Цена > 500

ИЛИ Номенклатура.ЭтоГруппа»

Ну вот теперь то, что нужно.

Пример: Номенклатура - отобранные элементы с группами

Далее попробуем сделать то же самое для конкретных полей таблицы. Поставим в настройке ограничения флаг для поля «Код».

Пример: Номенклатура - выбор поля Код

Если в настройке списка убрать отображение поля «код», будут выведены все элементы справочника, т.е. ограничение не сработало. Если поставить отображение поля «Код», ограничение будет работать.

Пример: Номенклатура - сравнение при выборе поля Код

При этом, несмотря на то, что элемент справочника виден в поле списка, его форму нельзя будет открыть, потому что настроено ограничение на реквизит. То же самое в произвольном запросе: при попытке получить «ограниченный» реквизит, будет ошибка доступа.

Пример: Номенклатура - ошибка доступа в консоли

Если попытаться получить «ограниченный» реквизит программным образом, также будет вызвана ошибка доступа.

Пример: Номенклатура - ошибка доступа в коде

Более того, нельзя будет обратиться к любым полям объекта через ссылку, т.к при получении ссылки система считывает весь объект целиком, и если в нем есть «ограниченные» реквизиты, объект считан не будет.

Поэтому при программной работе с объектами БД нужно иметь в виду возможные ограничения на уровне записей и получать все нужные данные объекта запросом и затем помещать их в структуру или исполнять часть кода в привилегированном модуле.


После настройки ограничения доступа изменилось отображение строки в списке прав – она стала серой и появилась пиктограмма.

Ограничения при настройке доступа (RLS).

  • Нет секции Итоги;
  • Нельзя обращаться к виртуальным таблицам регистров;
  • В явном виде нельзя использовать параметры;
  • Во вложенных запросах могут использоваться любые>/span> средства языка запросов, кроме:
    • оператора В ИЕРАРХИИ;
    • предложения ИТОГИ;
    • результаты вложенных запросов не должны содержать табличные части>/span>;
    • виртуальных таблиц, в частности ОстаткиИОбороты

Практика 2. Номенклатура с актуальной ценой.

Сделать ограничение доступа, если нужно выводить номенклатуру с актуальной ценой больше определенного значения, например, 100.

Решение:

Добавляем новое правило ограничения доступа для справочника «Номенклатура» на право «чтение».
Выбираем «прочие поля».
В конструкторе добавляем вложенный запрос. В нем выбираем таблицу регистра сведений «Цены номенклатуры».
Вкладки «порядок» нет – это особенность конструктора запросов для построения запроса ограничения доступа.
На вкладке «Дополнительно» ставим «первые 999999999», вкладка «порядок» появилась.
Настраиваем упорядочивание по полю «Период» по убыванию.
Затем настраиваем связь основной таблицы с вложенным запросом по ссылке.

Номенклатура - текст запроса с актуальной ценой

Шаблоны ограничений доступа.

Практика 3. Ограничение на «контрагенты» по значению в константе.

Настроим ограничение доступа для справочника Контрагенты по значению, которое хранится в Константе.

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

Решение

Для справочника «Контрагенты» для права «чтение» настроим ограничение, добавив в секцию «Условия» вложенный запрос к константе. Не забыть ЭтоГруппа.

Видим проблему, справочник Контрагенты фильтруется верно, а документы с реквизитом «Контрагент» отображаются все, некоторые с «битыми» ссылками в реквизите «Контрагент».

Теперь нужно настроить ограничение доступа для всех объектов, использующих ссылку на «Контрагенты». Найдем их сервисом «поиск ссылок на объект».

Скопируем и немного доработаем текст условия RLS из справочника «Контрагенты». Это нужно сделать столько раз, сколько найдено объектов.

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


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

Можно вынести в шаблон любой кусок текста ограничения доступа. Вызов шаблона осуществляется через символ «#». Например, #ШаблонКонтрагент.

Через # в 1С пишутся инструкции препроцессору. В контексте исполнения настроек ограничений доступа платформа заменяет текст вызова шаблона на текст шаблона.


Вынесем в шаблон «ШаблонКонтрагент» текст после слова ГДЕ, кроме текста про ЭтоГруппа.

Параметры в шаблонах ограничений доступа.

Продолжим решение задачи 2.

Проблема заключается теперь в том, что основная таблица в справочнике называется «контрагент», в документе «Приходная накладная». Проверяемое поле в справочнике называется «ссылка», в документе – «Контрагент».

Изменим в тексте шаблона название основной таблицы на «#ТекущаяТаблица»

«#ТекущаяТаблица» — это предопределенный параметр.

И через точку укажем номер входного параметра – «.#Параметр(1)

«#Параметр» — это тоже предопределенное значение. Может содержать произвольное количество входных параметров. Обращение к ним происходит по порядковому номеру.

В тексте ограничения доступа для справочника укажем следующее:

«Контрагенты ГДЕ #ШаблонКонтрагент(«Ссылка») ИЛИ ЭтоГруппа»

Для документа следующее:

«РеализацияТоваров ГДЕ #ШаблонКонтрагент(«Контрагент»)»


При вызове шаблона ограничения доступа параметры в него передавать нужно только как Строка, т.е в кавычках.

Пример.

Основная таблица — Номенклатура

Текст шаблона такой:

#ТекущаяТаблица ГДЕ #ТекущаяТаблица.#Параметр(1) = #Параметр(2)

Вызов Результирующий текст
#Шаблон(«ЭтоГруппа»,»Истина») Номенклатура ГДЕ Номенклатура.ЭтоГруппа = Истина
#Шаблон(«Наименование»,»Стул») Номенклатура ГДЕ Номенклатура.Наименование = «Стул»
#Шаблон(«Цена»,»100″) Номенклатур ГДЕ Номенклатура.Цена = 100

Текст шаблона содержит часть текста на языке ограничения доступа к данным и может содержать параметры, которые выделяются при помощи символа «#».

После символа «#» могут следовать:

  • Одно из ключевых слов:
    • Параметр, после которого в скобках указывается номер параметра в шаблоне;
    • ТекущаяТаблица – обозначает вставку в текст полного имени таблицы, для которой строится ограничение;
    • ИмяТекущейТаблицы – обозначает вставку в текст полного имени таблицы (как строковое значение, в кавычках), к которой применяется инструкция, на текущем варианте встроенного языка;
    • ИмяТекущегоПраваДоступа – содержит имя права, для которого выполняется текущее ограничение: ЧТЕНИЕ/READ, ДОБАВЛЕНИЕ/INSERT, ИЗМЕНЕНИЕ/UPDATE, УДАЛЕНИЕ/DELETE;
  • имя параметра шаблона – означает вставку в текст ограничения соответствующего параметра шаблона;
  • символ «#» – обозначает вставку в текст одного символа «#».

В выражении ограничения доступа могут содержаться:

  • Шаблон ограничения доступа, который указывается в формате #ИмяШаблона(«Значение параметра шаблона 1», «Значение параметра шаблона 2»,…). Каждый параметр шаблона заключается в двойные кавычки. При необходимости указания в тексте параметра символа двойной кавычки следует использовать две двойные кавычки.
  • Функция СтрСодержит(ГдеИщем, ЧтоИщем). Функция предназначена для поиска вхождения строки ЧтоИщем в строке ГдеИщем. Возвращает Истина в случае, если вхождение обнаружено и Ложь – в противном случае.
  • Оператор + для конкатенации строк.

Для удобства редактирования текста шаблона на закладке Шаблоны ограничений в форме роли нужно нажать кнопку Установить текст шаблона. В открывшемся диалоге ввести текст шаблона и нажать кнопку ОК.

Редактирование шаблона

Использование параметров в запросе ограничения доступа

В запросах на ограничение доступа можно использовать параметры &ИмяПараметра.

Однако, это не те параметры в обычном понимании, которые мы используем в отчетах и произвольных запросах.
Их нельзя установить методом УстановитьПараметр() или чем-то подобным.

В качестве параметров в данном случае выступают:

  • Параметры сеанса
  • Функциональные опции

Чтение параметров сеанса в запросе ограничения доступа происходит в привилегированном режиме, т.е без контроля прав на операции с ними.

Практика 4. Доступ к «своим» контрагентам

Необходимо настроить ограничение доступа текущего пользователя к «своим» контрагентам.

Есть справочник «Пользователи», справочник «Контрагенты», документы с реквизитом «Контрагент».

Текущий пользователь должен видеть данные только по тем контрагентам, для которых с ним установлена связь.

Связь тоже нужно настроить.

Возможные варианты:

Установления связей пользователь + контрагент

  • Реквизит в справочнике контрагенты
  • Регистр сведений

Возможные решения задачи:

  • Хранить пользователя в константе – плохой вариант, константа доступна всем пользователям.
  • Хранить в параметрах сеанса фиксированный массив контрагентов текущего пользователя – не очень хороший вариант, контрагентов может быть много
  • Хранить в параметрах сеанса текущего пользователя, затем запросом получать список «его» контрагентов – приемлемый вариант.
  • Другие варианты.

Решение.

Создадим новый параметр сеанса «ТекущийПользователь» и пропишем его заполнение в модуле сеанса.

Создадим регистр сведений «Соответствие менеджеров и контрагентов»

Создадим новую роль и в ней новое ограничение доступа для документа «ПриходнаяНакладная».

В тексте запроса соединим основную таблицу с регистром сведений по Контрагент = Контрагент и Менеджер = &ТекущийПользователь. Вид соединения Внутреннее.

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

Проверяем – ограничения работают

*Особенность: Если изменить список контрагентов пользователя в регистре ограничения доступа будут действовать сразу без перезапуска сеанса пользователя.

Практика 5. Дата запрета изменений.

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

Решение.

Создадим регистр сведений «ДатыЗапретаИзменений» с измерением Пользователь, ресурс ДатаЗапрета.

Построим логику решения таким образом:

  • если не указан пользователь, значит, запрет действует для всех пользователей
  • если есть ограничение для всех пользователей и ограничение для конкретного пользователя, тогда действует ограничение для конкретного пользователя, а для остальных по общему принципу.

Очевидно, что такое ограничение можно настроить для объектов базы данных, которые имеют некоторую позицию на оси времени. Это могут быть

  • Документы
  • Периодические регистры сведений

Создадим новую роль «ОраниченияПоДатеЗапретаИзменений».

В ней для документа «ПриходнаяНакладная» для права «изменение» добавим новое ограничение доступа.

Настройку указываем для всех полей.

Текст ограничения такой:

ПриходнаяНакладная ИЗ Документ.ПриходнаяНакладная КАК ПриходнаяНакладная
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
ДатыЗапретаИзменений.ДатаЗапрета КАК ДатаЗапрета
ИЗ
РегистрСведений.ДатыЗапретаИзменений КАК ДатыЗапретаИзменений
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
МАКСИМУМ(ДатыЗапретаИзменений.Пользователь) КАК Пользователь
ИЗ
РегистрСведений.ДатыЗапретаИзменений КАК ДатыЗапретаИзменений
ГДЕ
(ДатыЗапретаИзменений.Пользователь = &ТекущийПользователь
ИЛИ ДатыЗапретаИзменений.Пользователь = ЗНАЧЕНИЕ(Справочник.пользователи.ПустаяСсылка))) КАК ВЗ_Пользователь
ПО ДатыЗапретаИзменений.Пользователь = ВЗ_Пользователь.Пользователь) КАК ВложенныйЗапрос
ПО ПриходнаяНакладная.Дата > ВложенныйЗапрос.ДатаЗапрета

Проверяем – ограничение работает.

Использование инструкций препроцессору

#Если Условие1 #Тогда

Фрагмент запроса 1

#ИначеЕсли Условие2 #Тогда

Фрагмент запроса 2

#Иначе

Фрагмент запроса 3

#КонецЕсли

В условиях можно использовать логические операции (и. или, не и т.д) и обращение к параметрам сеанса.

Такой подход в контексте построения ограничений доступа удобен тем, что в зависимости от условий будет скомпилирован более короткий текст запроса. А более простой запрос меньше нагружает систему.

Минус заключается в том, что конструктор запроса с таким текстом работать не будет.

*Особенность:

В отличие от инструкций препроцессору встроенного языка в текстах ограничения доступа перед оператором Тогда нужно ставить решетку — #Тогда

Практика 6. Переключатель «Использовать RLS»

Дополним нашу систему ограничений переключателем, который включает/выключает использование ограничение на уровне записей.

Для этого добавим Константу и параметр сеанса с именем «ИспользоватьRLS».

Пропишем в Модуле сеанса установку значения параметра сеанса из значения константы.

Добавим во все тексты ограничения доступа такой код:

«#Если &ИспользоватьRLS #Тогда …..   #КонецЕсли»

Проверяем – все работает.

Однако, теперь после включения флага «использовать РЛС» изменения сразу в силу не вступят. Почему?

Потому что параметр сеанса устанавливается при запуске сеанса.

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

Работа со всеми ролями и ограничениями доступа.

Часто может возникать ситуация когда одинаковое ограничение нужно настроить для нескольких ролей.

Для этого в платформе есть возможность просматривать и редактировать все ограничения доступа.

Дерево метаданных — > Роли — > контекстное меню — > Все ограничения прав.

Все органичения доступа

В этом окне можно:

  • просмотреть все имеющиеся в системе ограничения прав доступа
  • отредактировать ограничения прав доступа
  • добавить новое ограничение сразу для нескольких ролей
  • скопировать ограничение прав на другие роли (копирование шаблона нужно будет выполнять вручную)
  • удалить сразу несколько ограничений доступа

Решение проблем с RLS

В 1С можно настроить ограничения по ролям, т.е. запретить пользователям с определенной ролью изменять какие либо реквизиты или объекты конфигурации. Например, при создание или открытии какого либо документа (справочника) можно запретить изменять номер, дату или другие необходимые элементы. На практики подобные задачи встречаются довольно часто, так как некоторые пользователи могут поменять дату документ или его номер, тем самым нарушить учет документооборота. Реализовать все это достаточно просто.

Программное ограничения по ролям в 1С

Допустить у нас в базе есть роль «Пользователь» и нам необходимо всем учетным записям с данной ролью запретить изменять номер и дату документа поступления, а так же указывать в поле «Ответственный» наименование роли.

1C Ограничения по ролям

Для этого в обработчике события «При создании на сервере» пишем вот такой код.

Если РольДоступна("Пользователь") Тогда
     Элементы.Номер.РедактированиеТекста = Ложь;
     Элементы.Дата.РедактированиеТекста = Ложь;
     Объект.Отвественный = Справочники.Пользователи.НайтиПоКоду("000000002");
     Сообщить("У Вас не хватает прав для редактирования реквизитов документа!!!");
КонецЕсли;

Думаю в нем все понять, если учетная запись под которой создается документ имеет роль «Пользователь» тогда запрещаем редактировать «Номер», «Дату» и в поле «Ответственный» подставляем значение из справочника «Пользователи» которое найдем по коду. Под данным кодом в справочнике находиться «Пользователь».

1C Как ограничить доступ к некоторым реквизитам документа для определённой роли программно

Запустим 1С и посмотрим что получилось, в итоге ввести что-то с клавиатуры в поля «Номер», «Дата» не получиться.

1C Как ограничить доступ к некоторым реквизитам для определённой роли

Но если у данного поля есть возможность выбора, например, как у даты то изменить её все же буде возможно.

1C Как ограничить доступ к некоторым реквизитам для определённой роли программно

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

Элементы.Дата.Доступность = Ложь;
Элементы.Номер.Доступность = Ложь;
Элементы.Отвественный.Доступность = Ложь;
1C отключаем доступность

В этом случае пользователь уже ни чего не сможет сделать.

1С как отключить доступность по ролям

Вариантов реализации подобных задач очень много, я показал один из, возможно он даже не самый оптимальной. Если Вы знаете другой обязательно поделитесь!!!

Кстати механизм подставления «Ответственного» тут не совсем корректен, так как в базе может быть много пользователей 10, 20 и если у всех у них есть роль «Пользователь» то она и будет подставляться, тут необходимо подставлять имя пользователя а не роли, с помощью ПользователиИнформационнойБазы.ТекущийПользователь() но об этом в следующей статье.

Эту и другие технические статьи написали наши программисты 1С и получили за них премии. Если вы тоже работаете с 1С и любите делиться опытом, приходите разработчиком в Neti

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Оба режима RLS в 1С имеют свои преимущества и недостатки.

RLS в 1С

Для гибкой настройки прав пользователей в конфигурациях на базе БСП (подсистема УправлениеДоступом) реализован механизм настройки доступа на уровне записей (RLS). Этот механизм позволяет ограничивать доступ не только по видам объектов (для конкретных справочников, документов…), но и по данным в этих объектах (т.е., например, ограничить список документов только по одной организации или по конкретному менеджеру).

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в тексте далее.

Для дальнейших скриншотов, примеров кода, а также для решения задачи будем использовать демонстрационную конфигурацию «Библиотека стандартных подсистем», редакция 3.1 (3.1.5.132).

Ограничения RLS описываются в роли для конкретного объекта. Например, ограничение на чтение документа _ДемоСчетНаОплатуПокупателю в роли
_ДемоЧтениеДокументовПокупателей описывается следующим образом:

Производительный режим RLS в 1С

Производительный режим RLS в 1С

Производительный режим RLS в 1С

Как мы видим, для описания ограничений используются специальные шаблоны. В данном случае #ДляОбъекта и #ПоЗначениям. Шаблоны, которые могут быть использованы в роли необходимо описать на вкладке “Шаблоны ограничений”:

Производительный режим RLS в 1С

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

Рассмотрим текст ограничения доступа подробнее.

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

Как мы видим, выбор шаблона зависит от параметра &ОграничениеДоступаНаУровнеЗаписейУниверсально, который как раз и определяет режим, в котором должно использоваться RLS — стандартный или производительный. Значение этого параметра хранится в параметрах сеанса, а в самой базе выбрать режим можно двумя способами:

1. Зайти в раздел Администрирование — Настройки пользователей и прав — Группы доступа — Вариант работы — Производительный

Производительный режим RLS в 1С

2. В окне “Все функции” изменить значение константы “Ограничивать доступ на уровне записей универсально” на ИСТИНА, если нужен производительный режим и, соответственно на ЛОЖЬ, если стандартный.

Производительный режим RLS в 1С

Соответственно, если &ОграничениеДоступаНаУровнеЗаписейУниверсально = ЛОЖЬ, то будет использоваться стандартный метод и выполняться код

#ПоЗначениям( "Документ._ДемоСчетНаОплатуПокупателю", "","",
"_ДемоОрганизации", "Организация",
"_ДемоГруппыПартнеров","Партнер", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "",""),

а если &ОграничениеДоступаНаУровнеЗаписейУниверсально = ИСТИНА, то будет использоваться производительный метод и выполняться код

#ДляОбъекта("").

Подробнее о синтаксисе и использовании шаблонов можно почитать в их описании.

При стандартном режиме ограничение прописывается прямо в роли (установлен отбор по разрешенным организации и партнеру). Эти отборы добавляются к итоговому запросу при обращении к СУБД. При наличии нескольких ролей с описанными ограничениями все условия собираются в один запрос, растет количество левых соединений, повышается риск неправильного использования индексов, выбора неоптимального плана выполнения запроса, что значительно его усложняет и замедляет выполнение. А так как при стандартном режиме работы ограничения рассчитываются “на лету” при каждом обращении к данным (формирование списков справочников и документов, их открытие и записи), то работа пользователя может значительно замедлиться из-за сложности сформированного запроса.

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

Как мы видим, в ограничении роли для производительного режима не описаны никакие условия, нет никакой информации о видах доступа, по которым необходимо ограничивать данные. Где же они указаны? Для этого в подсистеме УправлениеДоступом предусмотрена специальная экспортная процедура ПриЗаполненииОграниченияДоступа(), который описывается в модуле менеджера объекта, указанного в роли.

Так, для документа _ДемоСчетНаОплатуПокупателю эта процедура описана следующим образом:

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

Здесь мы видим, что ограничение описывается с помощью некоторых типов ограничения (РазрешитьЧтениеИзменение) и функций ограничений (ЗначениеРазрешено()). Это нужно понимать так: пользователю будет разрешено читать и изменять документ _ДемоСчетНаОплатуПокупателю, когда ему будут разрешены значения организации и партнера, указанные в этом документе.

Примечание. Подробно о типах, функциях, синтаксисе ограничений описано на сайте ИТС в разделе — Инструкции по разработке на 1С

— Библиотека стандартных подсистем 3.1.6. Документация

— Глава 3. Настройка и использование подсистем при разработке конфигурации

— Управление доступом

— Разработка ограничений прав доступа

Далее в статье рассмотрим кратко лишь некоторые.

Некоторые типы ограничений

Типы ограничения могут быть:

  • РазрешитьЧтениеИзменение
  • РазрешитьИзменениеЕслиРазрешеноЧтение
  • РазрешитьИзменение 

Основным способом описания ограничений необходимо считать функцию ЗначениеРазрешено(). Функция выполняет поиск проверяемого значения среди разрешенных значений в группах доступа, профили которых предоставляют соответствующие права на список.

  • ЗначениеРазрешено(<Реквизит> [<проверяемые типы>] [, <уточнение сравнения 1> [, <уточнение сравнения 2>] …]), где проверяемые типы могут быть (значения непроверяемых типов запрещены, если не уточнены отдельно):

— ТОЛЬКО <Имя таблицы>;
— ТОЛЬКО (<Имя таблицы 1>, <Имя таблицы 2>, … );
— КРОМЕ <Имя таблицы>;
— КРОМЕ (<Имя таблицы 1>, <Имя таблицы 2>, … );

  • Уточнение сравнения может быть:

— ПустаяСсылка КАК Ложь/Истина;
— Неопределено КАК Ложь/Истина;
— Null КАК Ложь/Истина;
— Отключено КАК Ложь/Истина (только для функции ЗначениеРазрешено);
— <Таблица> КАК Ложь/Истина (например, Справочник.Проекты КАК Истина).

Также существуют следующие функции:

  • ЧтениеОбъектаРазрешено
  • ЧтениеСпискаРазрешено
  • ИзменениеОбъектаРазрешено
  • ИзменениеСпискаРазрешено

Синтаксис этих функций аналогичен функции ЗначениеРазрешено().

Эти функции необходимо использовать, когда необходимо установить доступность (чтение/изменение) объекта в зависимости от доступности его реквизита. Например, документ _ДемоСчетНаОплатуПокупателю должен быть доступен, когда доступен его реквизит Организация. В таком случае ограничение будет описано как:

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

Функция выполняет проверку в строках с помощью логического «И». Используется для одновременного выполнения условия во всех строках табличной части объекта.

  • ДляОднойИзСтрок(<Условие>)

Функция выполняет проверку в строках с помощью логического «ИЛИ». Используется для выполнения условия хотя бы в одной строке табличной части объекта.

Примеры возможных ограничений

Организация и контрагент в шапке документа:

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

Организация в шапке документа, контрагент в табличной части, достаточно одного разрешенного контрагента:

Ограничение.Текст =
"РазрешитьЧтениеИзменение
|ГДЕ
| ЗначениеРазрешено(Организация)
|И ЗначениеРазрешено(Поставщики.Контрагент)";

Организация в шапке документа, контрагент в табличной части, достаточно одного разрешенного контрагента (если табличная часть пустая, тогда доступ по контрагенту разрешен):

Ограничение.Текст =
"РазрешитьЧтениеИзменение
|ГДЕ
| ЗначениеРазрешено(Организация)
|И ЗначениеРазрешено(Поставщики.Контрагент, Null КАК Истина)";

Организация в шапке документа, контрагент в табличной части, и требуется, чтобы все контрагенты были разрешены (если табличная часть пустая, тогда доступ по контрагенту запрещен):

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

Организация и контрагент в табличной части, при этом достаточно, чтобы любая из пар организации с контрагентом была разрешена:

Ограничение.Текст =
"РазрешитьЧтениеИзменение
|ГДЕ
| ЗначениеРазрешено(Поставщики.Организация)
|И ЗначениеРазрешено(Поставщики.Контрагент)";

Организация и контрагент в табличной части, при этом требуется, чтобы все пары организации с контрагентом были разрешены:

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

Организация и контрагент в табличной части, при этом требуется, чтобы одна из организаций и один из контрагентов были разрешены:

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

Отправитель – измерение составного типа, при этом требуется проверять только ссылки Справочник.Склады:

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

Отличительная особенность производительного режима RLS в 1С

Вернёмся к основной отличительной особенности производительного режима RLS в 1С. Она заключается в том, что в этом режиме расчет прав происходит предварительно и записывается в специальные таблицы (справочник и регистры сведений). Это позволяет достичь высокой производительности запросов с RLS, так как добавляет простой и статический фрагмент к текстам запросов в ролях. За счет этого обеспечивается одинаково хорошая скорость работы при различной прикладной логике ограничений доступа, при различных условиях и их комбинациях. Но, так как предварительный расчет прав доступа занимает некоторое время, поэтому изменения в правах вступают в силу с некоторой задержкой.

Для хранения этих предварительно рассчитанных данных (ключей) используются следующие таблицы:

  • справочник КлючиДоступа
  • регистр сведений КлючиДоступаКОбъектам
  • регистр сведений КлючиДоступаПользователей

Справочник КлючиДоступа имеет структуру:

Производительный режим RLS в 1С

В реквизитах Значение1 — Значение5 хранятся комбинации конкретных значений доступа. В зависимости от ограничений каждого конкретного типа объектов конфигурации состав значений разный. Например, как упоминалось выше, для документа _ДемоСчетНаОплатуПокупателю определено ограничение по Организации и Партнеру. Соответственно, будут сформированы ключи с возможными комбинациями организации и партнера.

В реквизит Хэш реквизит рассчитывается специальный хеш функции. Он позволяет быстро понять, существует ли уже в системе ключ с такой комбинацией значений или нет.

Структура регистров следующая:

Производительный режим RLS в 1С

Причем Объект РС КлючиДоступаКОбъектам имеет тип ОпределяемыйТип.ВладелецЗначенийКлючейДоступа, которые содержит в себе ссылки на все объекты, которые могут быть ограничены с помощью RLS.

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

Таким образом при проверке ограничений доступа вне зависимости от количества настроенных для конкретного проверяемого объекта видов доступа запрос всегда будет дополняться одним соединением с регистром «Ключи доступа к объектам» по проверяемому объекту и с регистром «Ключи доступа пользователей» по текущему пользователю:

Производительный режим RLS в 1С

Обновление ключей объектов и ключей доступа к ним выполняются регламентным заданием. А также оно может быть запущено из обработки “Обновление доступа на уровне записей”:

Производительный режим RLS в 1С

Эта обработка позволяет запускать процесс обновления ключей вручную, а также настраивать и контролировать процесс выполнения.

Запуск обработки выполняется по кнопке

Производительный режим RLS в 1С

Можно настроить обновление ключей по определенным объектам. Эта настройка выполняется по кнопке Ещё — Ручное управление… На этой форме можно выбрать конкретные справочники, документы или регистры, по которым необходимо обновить ключи, отметить их флажками, после этого запланировать обновление и запустить обработку:

Производительный режим RLS в 1С

Также есть возможность выводить более подробную информацию о ходе выполнения обработки

Производительный режим RLS в 1С

Для удобного написания и контроля текстов ограничений в комплекте поставки есть специальная обработка УправлениеДоступом:

Производительный режим RLS в 1С

Она позволяется в пользовательском режиме, без редактирования конфигурации формировать и проверять тексты ограничения доступа для объектов. Для этого необходимо во вкладке “Разработка ограничений доступа” необходимо выбрать список, ограничение на который нужно отредактировать:

Производительный режим RLS в 1С

После этого на форму загрузится текст ограничений из процедуры ПриЗаполненииОграниченияДоступа, а также шаблон ограничения в роли, а также кнопки для проверки текста вставки его в код:

Производительный режим RLS в 1С

При наличии ошибки в тексте ограничения и нажатии на кнопку “Проверить” появляется вкладка “(ошибки)”, в которой описаны ошибка как самого текста, так и всего внедрения механизма ограничений по записям для объекта:

Производительный режим RLS в 1С

Производительный режим RLS в 1С

Несколько конкретных примеров внедрения

Допустим, нам необходимо создать новый документ и подключить его к механизму ограничений RLS. Для этого необходимо выполнить следующие операции:

— создать новый документ ТестовыйДокументСОграничениями

Производительный режим RLS в 1С

— добавить объект в определяемые типы ВладелецЗначенийКлючейДоступа и ВладелецЗначенийКлючейДоступаДокумент.

Примечание. В определяемый тип ВладелецЗначенийКлючейДоступаДокумент добавляются документы. Справочники нужно добавить в ВладелецЗначенийКлючейДоступаОбъект, регистры сведений — в ВладелецЗначенийКлючейДоступаНаборЗаписей, регистры расчета — в ВладелецЗначенийКлючейДоступаНаборЗаписейРегистраРасчета.

— в процедуру ПриЗаполненииСписковСОграничениемДоступа общего модуля УправлениеДоступомПереопределяемый вставить текст

Списки.Вставить(Метаданные.Документы.ТестовыйДокументСОграничениями, Истина);
Процедура ПриЗаполненииСписковСОграничениемДоступа(Списки) Экспорт

…
Списки.Вставить(Метаданные.Документы.ТестовыйДокументСОграничениями, Истина);
КонецПроцедуры

— на форме документа в обработчики ПриЧтенииНаСервере и ПослеЗаписиНаСервере добавить следующий код:

&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
// СтандартныеПодсистемы.УправлениеДоступом
Если ОбщегоНазначения.ПодсистемаСуществует("СтандартныеПодсистемы.УправлениеДоступом") Тогда
МодульУправлениеДоступом = ОбщегоНазначения.ОбщийМодуль("УправлениеДоступом");
МодульУправлениеДоступом.ПриЧтенииНаСервере(ЭтотОбъект, ТекущийОбъект);
КонецЕсли;
// Конец СтандартныеПодсистемы.УправлениеДоступом
КонецПроцедуры
&НаСервере
Процедура ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
// СтандартныеПодсистемы.УправлениеДоступом
УправлениеДоступом.ПослеЗаписиНаСервере(ЭтотОбъект, ТекущийОбъект, ПараметрыЗаписи);
// Конец СтандартныеПодсистемы.УправлениеДоступом
КонецПроцедуры

— создать новые роли для чтения и добавления/изменения нового документа: ЧтениеТестовыхДокументовСОграничениями и ДобавлениеИзменениеТестовыхДокументовСОграничениями. Для них определить соответствующие права (чтение, добавление, изменение), скопировать шаблон ограничений ДляОбъекта() из роли ИзменениеУчастниковГруппДоступа и прописать код ограничения доступа для необходимых прав:

#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляОбъекта("")
#Иначе
ИСТИНА
#КонецЕсли

Примечание. В данном конкретном случае принимаем, что производительный режим RLS используется, поэтому ограничение для обычного режима не прописываем и в соответствующей ветке прописываем просто ИСТИНА.

Производительный режим RLS в 1С

  • Нужно для этого документа реализовать ограничение, чтобы были доступны только те документы, в которых доступны организация и подразделение. Необходимо выполнить следующие действия:

— в модуле менеджера документа в процедуре ПриЗаполненииОграниченияДоступа прописать текст ограничения:

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт

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

— в пользовательском режиме создать профили доступа с созданными ранее ролями, группы доступа и прописать в них ограничения по организациям и подразделениям и назначить их пользователям:

Производительный режим RLS в 1С Производительный режим RLS в 1С Производительный режим RLS в 1С

— создать документы и запустить задание обновления ключей доступа.

В результате получим ограниченный список документов для тестового менеджера:

под полными правами

Производительный режим RLS в 1С

под ограниченными правами

Производительный режим RLS в 1С

  • Нужно реализовать ограничение, чтобы были доступны только те документы, в которых доступны организация и было доступно хотя бы одно место хранения из ТЧ Запасы.

— в модуле менеджера документа в процедуре ПриЗаполненииОграниченияДоступа прописать текст ограничения:

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт

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

— добавить вид ограничения в профиль доступа, прописать в группе доступа ограничения по местам хранения, обновить ключи:

Производительный режим RLS в 1С Производительный режим RLS в 1С

В результате под пользователем с ограниченными правами увидим только те документы, у которых доступна организация и в ТЧ Запасы хотя бы в одной строке указан Розничный склад:

Производительный режим RLS в 1С Производительный режим RLS в 1С Производительный режим RLS в 1С Производительный режим RLS в 1С

  • Рассмотрим пример, когда необходимо реализовать ограничение по какому-то новому реквизиту, тип которого не описан в доступных видах доступа. Реализуем такую задачу. Для этого нужно выполнить следующее:

— создать новый справочник ТестовыйРегион. Выполнить для него все те же операции, что и для самого документа ТестовыйДокументСОграничениями (роли можно создать новые или прописать в какие-то существующие, например для чтения/изменения документа. В данном примере это не принципиально. В ПриЗаполненииОграниченияДоступа прописать ограничение на само себя: ЗначениеРазрешено(Ссылка)).

— добавить ссылку и объект ТестовыйРегион в определяемые типы соотстветственно ЗначениеДоступа и ЗначениеДоступаОбъект

— в процедуру ПриЗаполненииВидовДоступа общего модуля УправлениеДоступомПереопределяемый вставить текст:

Процедура ПриЗаполненииСписковСОграничениемДоступа(Списки) Экспорт

…
ВидДоступа = ВидыДоступа.Добавить();
ВидДоступа.Имя = "ТестовыйРегион";
ВидДоступа.Представление = НСтр("ru = 'Тестовый регион'");
ВидДоступа.ТипЗначений = Тип("СправочникСсылка.ТестовыйРегион");
КонецПроцедуры

— запустить обработку ОбновлениеВспомогательныхДанных (из Инструментов разработчика) и  обновить всё.

— добавить новый вид доступа в профиль доступа и определить конкретные ограничения в группе доступа:

Производительный режим RLS в 1С Производительный режим RLS в 1С

— добавить реквизит в документ, вывести на форму, заполнить (скриншот от пользователя с полными правами):

Производительный режим RLS в 1С

— изменить текст ограничения в процедуре ПриЗаполненииОграниченияДоступа документа ТестовыйДокументСОграничениями, чтобы он учитывал новый реквизит:

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт

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

— обновить ключи доступа.

В результате на пользователя с ограниченными правами распространяются ограничения по организациям (ООО Тестовая организация и Новые технологии ООО) и регионам (Центральный и Южный) и он получит такой список документов:

Производительный режим RLS в 1С

   dave2000

08.04.19 — 09:17

Есть некий объект с данными (справочник/документ/регистр), необходимо закрыть доступ к одному реквизиту. Т.е. скрывать не записи целиком, а один реквизит. Как это можно реализовать?

Пробовал через RLS, там можно выбирать, на какие поля распространяется ограничение доступа, но пока не получается, либо я что-то неправильно делаю.

  

Партнерская программа EFSOL Oblako

   1CIlya

1 — 08.04.19 — 10:13

Не рассматривали возможность внести изменения в архитектуру конфигурации? Вынести этот реквизит в регистр сведений и там навесить RLS.

   Fram

2 — 08.04.19 — 10:20

(0) это вроде без рлсов галочками можно сделать

   dave2000

3 — 08.04.19 — 11:07

(1) слишком много таких изменений будет, это ЗУП… прийдется все механизмы расчета переписывать, отчеты и т.д.

(2) Дал право «чтение/просмотр» на регистр, а на сам реквизит снял галки «просмотр/редактирование» — отображаются все поля и все реквизиты. Что-то оно так не работает.

   Жан Пердежон

4 — 08.04.19 — 11:19

(0 RLS — котлеты, реквизиты — мухи.

смотри в правах на подписи возле галочек

   dave2000

5 — 08.04.19 — 11:57

(4) Не совсем понял, что имелось в виду? Для реквизита снимаю галочки «Просмотр» и «Редактирование»

   Жан Пердежон

6 — 08.04.19 — 12:21

   Вафель

7 — 08.04.19 — 12:22

лучше кодом делать

Элементы.Реквизит.Видимость = РольДоступна("МояРоль");
   Жан Пердежон

8 — 08.04.19 — 12:36

(7) образец говнокода

   1Сергей

9 — 08.04.19 — 12:37

(7) линейкой по пальцам за такое

   Сияющий в темноте

10 — 08.04.19 — 14:05

запрос на уровне полей не умеет.

   vvp91

11 — 08.04.19 — 14:20

Типовые конфигурации, к сожалению, предоставляют доступ ко всем реквизитам, всех объектов, во всех ролях.

Поэтому, если пользователь, кроме специальной (своей) роли с ограничением по реквизитам, получает еще и типовые роли, то он получает доступ и к реквизиту.

Если дать пользователю только свои роли, в которых отключен доступ к реквизитам, то все заработает.

   Вафель

12 — 08.04.19 — 14:23

(8) ты еще скажи, что лучше в элементе настраивать раздел «видимость по ролям»

   Вафель

13 — 08.04.19 — 14:24

(6) собственно сама 1с не рекомендует независимые права для реквизитов

   fisher

14 — 08.04.19 — 15:22

(0) Через RLS не получится. RLS либо «пропускает» запрашиваемые данные строки, либо нет. Если пытаться прочитать данные строки включая «запретный» реквизит, то RLS не пропустит ничего.

   fisher

15 — 08.04.19 — 15:23

А если не через RLS, то костылить придется везде.

   fisher

16 — 08.04.19 — 15:29

Хотя не. Может и не везде. Я в этом вопросе плаваю.

Надо курить, как сочетаются права в ролях по реквизитам и комбинации галок пользовательской видимости в настройках форм.

   LLeonidov

17 — 08.04.19 — 15:34

(8) расскажи это создателям типовых. В данном случае плохое решение, но когда на роль повешен бизнес процесс, то почему бы и нет?

(0) Если тебе только спрятать или закрыть на редактирование, то ты что-то не договариваешь. Реквизит прекрасно прячется проверял на 1с 8.3.13.1513, 1с что-то поменяла в последних релизах, может доделают до конца, но это не точно.

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

   Fram

18 — 08.04.19 — 17:55

(3) > Дал право «чтение/просмотр» на регистр, а на сам реквизит снял галки «просмотр/редактирование»

это единственная роль у пользователя?

   АнализДанных

19 — 08.04.19 — 19:11

(0) А если функциональную опцию на реквизит повесить, значение опции брать из настроек пользователя?

   dave2000

20 — 10.04.19 — 17:07

В ЗУП есть регистр ПлановыеНачисления, в котором нужно убрать видимость реквизита Показатель1. Добавляю ограничение: поле «Показатель1», условие «ГДЕ ЛОЖЬ». Не показывает вообще записей.

(14) Похоже, что оно так и работает

(17) Мне нужно это поле спрятать, т.е. чтобы данные этого поля не подтягивалась запросами в документы, регистры и т.д. Чтобы были видны просто нули.

   Eiffil123

21 — 10.04.19 — 17:12

(20) если скрыть этот реквизит из формы списка, тогда будет всё видно. А если показать — тогда ничего.

Но это только для реквизитов, привязанных к полю объекта. А так, если он программно куда-то печатается, то его ничем не скрыть.

   craxx

22 — 10.04.19 — 17:31

(0) как верно заметили в (19), функциональная опция спасет отца русской демократии

   dave2000

23 — 10.04.19 — 17:33

(21) Нашел доступное описание:

https://fs.kursypo1c.ru/free/1C-Administration/03-rls-data-access-restrictions—-kursy-po-1c_ru.pdf

«Механизм позволяет накладывать ограничение не только на всю запись базы данных

целиком, но и на отдельные ее поля. При этом можно указать имя конкретного поля или

специальное поле Прочие поля.

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

присутствует поле, для которого задано ограничение.

Во втором случае ограничение будет накладываться для всех полей объекта, кроме полей,

для которых ограничения заданы явным образом.»

   dave2000

24 — 10.04.19 — 17:34

(22) Опция просто спрячет поле из документа или списка. А что делать с запросами, отчетами, печатными формами, где выбрается это поле?

  

Said_We

25 — 11.04.19 — 00:27

(0) Ответ уже дали в (14).

Если простым языком, то…

RLS умеет закрывать или не закрывать запись целиком. Условие RLS либо отрабатывает либо нет в зависимости к обращению полям, на которые наложено условие. Если среди полей, которые из БД считываются есть поля, на которые наложены условия, то эти RLS отрабатывают, но действует условие всегда на всю запись.

В (23) говориться что условие можно привязывать к отдельным полям, но не говориться, что это условие будет действовать только на отдельные поля.

Не надо оклад директоров и руководства скрывать. Получают слишком много денег, так значит заработали — чего стесняться. :-)

Если все-таки стесняетесь, то не надо получать много — получайте меньше. :-)

Часто возникает необходимость в частичном ограничении доступа к данным. Например, когда пользователь должен видеть документы только своей организации. В таких случаях в 1С используется механизм ограничения доступа на уровне записей (так называемый, RLS – Record Level Securiy).

Для примера предположим, что перед нами стоит следующая задача. На предприятии ведется многофирменный учет и каждый контрагент и пользователь базы данных относится к определенной организации. Необходимо обеспечить доступ к справочнику “Контрагенты” таким образом, чтобы каждый пользователь мог просматривать, редактировать и добавлять контрагентов только своей организации.

Для решения задачи будем использовать платформу “1С:Предприятие 8.2″. Создадим новую конфигурацию в свойствах которой в качестве основного режима запуска будет выбран вариант “Управляемое приложение”.

Далее создадим справочник “Организации” и ещё два справочника – “Контрагенты” и “Пользователи” с реквизитом “Организация”. Кроме справочников нам понадобятся два параметра сеанса – “Организация” и “Пользователь” (соответствующих типов). Значения этих параметров устанавливаются при запуске сеанса работы с конфигурацией и хранятся до его завершения. Именно значения этих параметров мы и будем использовать при добавлении условий ограничения доступа на уровне записей.

Установка параметров сеанса выполняется в специальном модуле – “Модуль сеанса”

В этом модуле опишем предопределенную процедуру “УстановкаПараметровСеанса” в которой вызовем функцию заранее подготовленного общего модуля “ПолныеПрава”. Это необходимо в силу особенностей работы базы данных в режиме управляемого приложения, когда часть программного кода может выполняться только на стороне сервера (подробно на объяснении этих принципов в данной статье я останавливаться не буду).

Код 1C v 8.х

 Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
ПолныеПрава.УстановитьПараметрыСеанса();
КонецПроцедуры<br>

В свойствах модуля “ПолныеПрава” необходимо отметить флажки “Сервер”, “Вызов сервера” и “Привилегированный” (последнее означает, что процедуры и функций данного модуля будут выполнятся без контроля прав доступа). Текст модуля будет выглядеть так:

Код 1C v 8.х

 Функция ОпределитьТекущегоПользователя()
ТекПользователь = Справочники.Пользователи.НайтиПоНаименованию(ИмяПользователя(),Истина);
Возврат ТекПользователь;
КонецФункции

Процедура УстановитьПараметрыСеанса() Экспорт
ТекущийПользователь = ОпределитьТекущегоПользователя();
ТекущаяОрганизация = Справочники.Организации.ПустаяСсылка();
Если ЗначениеЗаполнено(ТекущийПользователь) Тогда
ТекущаяОрганизация = ТекущийПользователь.Организация;
КонецЕсли;
ПараметрыСеанса.Пользователь = ТекущийПользователь;
ПараметрыСеанса.Организация = ТекущаяОрганизация;
КонецПроцедуры

Функция ПараметрСеансаУстановлен(ИмяПараметра) Экспорт
Возврат ЗначениеЗаполнено(ПараметрыСеанса[ИмяПараметра]);
КонецФункции

Функция РольДоступнаПользователю(ИмяРоли) Экспорт
Возврат РольДоступна(ИмяРоли);
КонецФункции<br>

В модуле управляемого приложения будем проверять наличие пользователя конфигурации в справочнике “Пользователи” (для простоты будем искать его по наименованию) и завершать работу системы если он не найден. Это необходимо для того, чтобы обеспечить заполнение параметров сеанса.

Код 1C v 8.х

 Процедура ПередНачаломРаботыСистемы(Отказ)
// всех кроме администратора будем проверять на наличие в справочнике "Пользователи"
Если Не ПолныеПрава.РольДоступнаПользователю("ПолныеПрава") Тогда
Если НЕ ПолныеПрава.ПараметрСеансаУстановлен("Пользователь") Тогда
Предупреждение("Пользователь """ + ИмяПользователя() + """ не найден в справочнике!");
Отказ = Истина;
Возврат;
КонецЕсли;
КонецЕсли;
КонецПроцедуры<br>

Теперь можем перейти непосредственно к описанию ограничений доступа. Для этого создадим роль “Пользователь” и перейдем на закладку “Шаблоны ограничений”, где добавим новый шаблон “КонтрагентыЧтениеИзменение” со следующим текстом шаблона: ГДЕ Организация =Организация #Параметр(1)

Текст шаблона ограничений является расширением языка запросов. В отличии от обычного запроса, текст ограничения должен в обязательном порядке содержать условие “ГДЕ”. В качестве значений параметров запроса (в нашем случае это “&Организация”) используются значения одноименных параметров сеанса. Конструкция вида #Параметр(1) означает, что на это место система подставит текст, переданный в качестве первого параметра в месте использования шаблона. С помощь приведенного шаблона будет выполняться проверка каждой записи таблицы (в нашем случае это будет справочник “Контрагены”). Для записей, значение реквизита “Организация” которых совпадает с заданным в соответствующем параметре сеанса, условие описанное в шаблоне будет выполняться. Таким образом эти записи будут доступны для чтения, изменения или добавления (в зависимости от того для какого из этих прав применяется шаблон). Продемонстрирую вышеизложенное на нашем примере.

Перейдем на закладку “Права” роли “Пользователь” и откроем список прав справочника “Контрагенты”. Будем использовать шаблон ограничений “КонтрагентыЧтениеИзменеие” для прав “Чтение”, “Изменение” и “Доблавление”.

Для права “Чтение” будем использовать шаблон с параметром “ИЛИ ЭтоГруппа”. При этом пользователям данной роли будет разрешено чтение не только элементов справочника “Контрагенты” своей организации, но и всех групп этого справочника.

#КонтрагентыЧтениеИзменение(«ИЛИ ЭтоГруппа»)

Поскольку при добавлении новых элементов справочника системой выполняется неявное чтение предопределенных реквизитов (это нужно, например, для нумерации), то необходимо обеспечить беспрепятственное чтение этих полей. Для этого добавим дополнительную строку с пустым текстом ограничения в таблицу ограничения доступа к данным и перечислим поля для которых действует данное правило – Ссылка, Версия данных, Родитель, Код.

Таким образом, поставленная задача ограничения доступа на уровне записей решена. Пользователи с действующими ограничениями получат доступ на просмотр и редактирование данных только своей организации.

Источник

Понравилась статья? Поделить с друзьями:
  • 1с отбор в форме по дополнительному реквизиту
  • 1с ошибка метода контекста найти по реквизиту
  • 1с перебрать все документы изменить реквизиты
  • 1с перед записью на сервере изменить реквизит
  • 1с получить значение реквизита формы по имени