для чего нужны параметры сеанса при работе с rls
Параметры сеанса в 1С 8.3
Параметры сеанса
Параметры сеанса предназначены для хранения каких-либо значений в течении всего сеанса пользователя. Например, имя текущего пользователя.
Параметры сеанса находятся в узле метаданных Общие — Параметры сеанса:
При создании нового параметра сеанса для него нужно указать имя и тип. Перечень возможных типов ограничен:
Помимо ссылочных типов, примитивных типов и других типов, можно указывать такие типы как: ФиксированныйМассив, ФиксированноеСоответствие и ФиксированнаяСтруктура.
Значения параметров сеанса хранятся отдельно для каждого пользователя, в течении всего сеанса пользователя.
Значения параметров сеанса сохраняются в сеансовых данных, на сервере. Изменять и читать значения параметров сеанса можно только на сервере. Если попытаться обратиться к параметрам сеанса на клиенте будет вызвана ошибка «Переменная не определена (ПараметрыСеанса)».
Для параметров сеанса можно назначать права доступа: на получение и на установку.
Если у пользователя нет права «Установка» для параметра сеанса, то установить параметр можно только в привилегированном общем модуле или в модуле сеанса (который всегда выполняется в привилегированном режиме).
Модуль сеанса
Данный модуль выполняется самым первым при загрузке конфигурации. Он всегда выполняется без контроля прав доступа (в привилегированном режиме).
В модуле сеанса есть только один обработчик УстановкаПараметровСеанса с одним параметром ТребуемыеПараметры (при этом ничто не мешает переименовать данный параметр). Данный обработчик предназначен для инициализации параметров сеанса.
При запуске системы и вызове данного обработчика, параметр ТребуемыеПараметры будет равен Неопределено. В дальнейшем, если обратиться к неинициализированному параметру сеанса, то будет вызван данный обработчик, а в параметре ТребуемыеПараметры будет содержаться массив с именами параметров сеанса, к которым было выполнено обращение. Если после вызова хотя бы один из параметров сеанса из данного массива все еще будет равен Неопределено, то будет вызвано исключение «Попытка получения неинициализированного значения параметра сеанса».
Работа с параметрами сеанса из встроенного языка
К параметрам сеанса можно обращаться только на сервере. Причем, можно как получать значения параметров, так и изменять. Обращение выполняется через свойство ПараметрыСеанса, после которого указывается имя параметра:
Использование параметров сеанса
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. Параметры сеанса предназначены для хранения значений определенных типов для каждого клиентского сеанса на время работы этого сеанса. Инициализацию параметров сеанса следует выполнять в модуле сеанса (см. ниже раздел 2.1), а их значения рекомендуется использовать в запросах и условиях ограничения доступа к данным для текущего сеанса.
Примеры параметров сеанса:
В этом случае, для установки или получения значения параметра сеанса текущий пользователь должен быть наделен соответствующим правом.
Также они могут использоваться в текстах ограничений доступа, например:
ГДЕ Документ.Автор = &ТекущийПользователь
В последнем случае для получения значения параметра сеанса наличия у текущего пользователя соответствующего права не требуется.
1.2. Не рекомендуется использовать параметры сеанса для хранения значений, используемых исключительно в клиентской логике. Поскольку в клиент-серверном варианте 1С:Предприятия параметры сеанса хранятся на сервере, то любое их считывание или изменение в процессе работы на клиенте потребует дополнительного серверного вызова и увеличит объем передаваемых данных с клиента на сервер и обратно.
В таких случаях следует использовать глобальные переменные модуля управляемого приложения (и обычного приложения – для режима обычного приложения, соответственно).
1.3. Также не рекомендуется использовать параметры сеанса для кеширования вычисленных значений, которые многократно используются в серверной бизнес-логике. В таких случаях следует определять функцию в серверном общем модуле с повторным использованием возвращаемых значений. Исключение составляют случаи, когда время вычисления результата функции модуля с повторным использованием возвращаемых значений соизмеримо с периодом сброса платформенного кеша.
Установка параметров сеанса «по требованию»
2.1. Не следует производить инициализацию параметров сеанса при запуске программы, так как:
Правильным способом установки значений параметров сеанса является установка значений «по требованию» в обработчике УстановкаПараметровСеанса модуля сеанса. Т.е. параметры сеанса должны быть инициализированы только в тот момент, когда к ним происходит первое обращение, как к неустановленным.
Пример установки параметров сеанса «по требованию»:
Если ИменаПараметровСеанса = Неопределено Тогда
// Раздел установки параметров сеанса при начале сеанса (ИменаПараметровСеанса = Неопределено)
// Выполняется установка параметров сеанса, которые можно инициализировать
// при начале работы системы
Иначе
// Установка параметров сеанса «по требованию»
// Параметры сеанса, инициализация которых требует обращения к одним и тем же данным
// следует инициализировать сразу группой. Для того, чтобы избежать их повторной инициализации,
// имена уже установленных параметров сеанса сохраняются в массиве УстановленныеПараметры
УстановленныеПараметры = Новый Массив;
Для Каждого ИмяПараметра Из ИменаПараметровСеанса Цикл
УстановитьЗначениеПараметраСеанса(ИмяПараметра, УстановленныеПараметры);
КонецЦикла;
Если ИмяПараметра = «ТекущийПользователь» Тогда
ПараметрыСеанса.ТекущийПользователь = ;
ПараметрыСеанса. = ;
УстановленныеПараметры.Добавить(ИмяПараметра);
УстановленныеПараметры.Добавить(» «);
КонецЕсли;
Ограничение доступа к данным на уровне записей (RLS) в 1С 8.3
Настройка RLS
Роли позволяют назначить права доступа на весь объект. Но иногда требуется разделить права доступа на конкретные значения объекта. Например, в справочнике контрагентов могут быть и покупатели и поставщики. И нужно, чтобы менеджеры по продажам видели только покупателей, а менеджеры по закупкам только поставщиков.
Для этого используются ограничения доступа к данным на уровне записей или RLS (Record Level Security).
RLS настраиваются в роли в группе Ограничения доступа к данным:
RLS настраиваются отдельно для каждого права. При этом ограничения можно настроить только для следующих прав:
В колонке Поля указывается список полей объекта, на которые настраивается ограничение. Можно выбрать Прочие поля, что значит ограничение на все поля объекта, кроме тех на которые явно настроены ограничения.
Для права Чтение можно настроить несколько ограничений. Между собой они будут объединены по условию И. У пользователя будут права только при выполнении всех ограничений.
На права Добавление, Изменение и Удаление можно настроить только одно ограничение.
Если на какое-то право были настроены RLS, то в списке прав они выделяются цветом, а также пиктограммой:
В примере выше RLS настроены для прав Чтение и Изменение.
Ограничения доступа можно настраивать для:
Язык ограничения доступа к данным
В колонке Ограничение доступа указывается текст самого ограничения. Он пишется на специальном языке ограничения доступа к данным, который является подмножеством языка запросов 1С. В тексте можно использовать только секции ИЗ и ГДЕ.
Если запрос из ограничения доступа вернет хотя бы одну запись или условие в секции ГДЕ будет истинным, то у пользователя есть права на этот объект базы банных. В противном случае прав не будет.
Простое ограничение доступа может выглядеть следующим образом:
Здесь Контрагенты — это псевдоним таблицы, а ГДЕ ИСТИНА — условие.
Таблица объекта, на который настраиваются ограничения всегда присутствует в тексте запроса. Именно ее псевдоним указывается в начале запроса. При необходимости можно добавить несколько таблиц в запрос:
Стоит отменить что в тексте запроса RLS нельзя обращаться к реквизитам и ресурсам регистра накопления или бухгалтерии. А также можно обращаться только к балансовым измерениям регистра бухгалтерии.
Примеры RLS
Чтобы лучше разобраться как работает RLS в 1С настроим ограничения доступа на справочник Контрагенты, чтобы менеджеры по продажам видели только покупателей.
У справочника Контрагенты есть реквизит ГруппаДоступа, который имеет тип ПеречислениеСсылка.ГруппыДоступаКонтрагентов:
По значению данного реквизита можно определить кем является контрагент.
Сейчас в списке контрагентов 2 покупателя и 2 поставщика:
Создадим роль Покупатели и для справочника Контрагенты и права Чтение настроим следующее ограничение:
И дадим пользователю только эту роль. В результате ему будут доступны только покупатели:
Удалим ограничение доступа для права Чтение и добавим такое же, но для права Добавление:
В результате пользователь может видеть всех контрагентов, но создать нового контрагента может только с группой Покупатели. Если указать любую другую группу, то будет выдана ошибка «У пользователя недостаточно прав на исполнение операции над базой данных»:
Удалим ограничение для права Добавление и добавим такое же для права Изменение:
Теперь пользователь может добавлять контрагентов с любой группой доступа, но изменять может только покупателей. При этом нельзя сначала изменить группу доступа на Покупатели, а потом изменить сам объект. Проверка выполняется как до изменения, так и после изменения.
Удалим ограничения для права Изменение и добавим такое же для права Удаление:
Теперь пользователь может и читать и добавлять и изменять любых контрагентов, но удалить может только покупателей. Именно удалить, а не пометить на удаление.
Вернем снова ограничение только для права Чтение, чтобы пользователь мог видеть только покупателей. Если сейчас пользователю дать еще одну роль, которая дает права на чтение и просмотр контрагентов, но для нее не настроены RLS, то пользователь увидит всех контрагентов. Так происходит, потому что из разных ролей RLS складываются по условию ИЛИ. Если хотя бы в одной роли нет ограничений, то считается, что разрешены все контрагенты.
Если для права Чтение добавить еще одно ограничение с условием:
Возможности типовых шаблонов ограничения доступа на уровне записей (RLS)
Во всех конфигурациях, созданных на базе БСП, применяются четыре стандартных шаблона для ограничения прав доступа к объектам на уровне записей:
В данной статье я рассматриваю основные возможности использования указанных шаблонов. Некоторые, специфические варианты применения рассматривать не буду по причине их кране редкого использования. При необходимости их можно посмотреть в описании приведенном на ИТС.
Перед прочтением, рекомендую посмотреть информацию про основные принципы реализации ограничений прав на уровне записей в типовых конфигурациях в этой статье. Здесь, я описываю исключительно применение типовых шаблонов, без подробного описания подсистемы в целом.
Наиболее часто используемый шаблон. Применяется, когда необходимо ограничить доступ по каким либо реквизитам объекта.
Значения всех параметров начиная с четвертого, это пары вид доступа – проверяемый реквизит объекта. Соответственно, шаблон поддерживает указание ограничений по 16 реквизитам объекта.
Проверяется соответствие реквизитов разрешенным значениям видов доступа для текущего пользователя. Для доступности объекта, разрешение должно быть найдено хотя бы в одной группе доступа, в которую включен пользователь, для всех указанных реквизитов одновременно. Также у пользователя должен быть доступ к данному объекту на уровне ролей.
Пример для выше приведенного ограничения доступа к документу «ПриобретениеТоваровУслуг»:
Для пользователя в настройках его групп доступа указаны следующие разрешения:
Следовательно, для данного пользователя будут доступны документы по складу «Основной», с подразделениями отличными от: «Администрация», «Отдел закупок».
В шаблоне #ПоЗначеним можно использовать конструкции на языке запросов для указания жестких отборов. Для этого используется специальный вид доступа «Условие»:
Также, можно проверить доступ на уровне ролей, к объектам, на которые ссылаются реквизиты проверяемого объекта (это может быть владелец проверяемого объекта или любой другой реквизит). Для этого, в качестве вида доступа необходимо указать «ПравоЧтения» или «ПравоИзменения»:
Шаблон необходимо применять, когда набор требуемых для проверки значений может быть различным для каждого конкретного проверяемого элемента. Это могут быть журналы документов, объекты в которых проверяемые значения находятся в табличных частях или иные случаи. Во всех выше перечисленных случаях необходимо заранее подготовить и записать наборы значений доступа для каждого проверяемого объекта. Соответственно, для доступности объекта, все значения набора должны быть доступны хотя бы в одной из групп доступа пользователей.
В качестве четвертого параметра можно указать ссылку на объект, который будет являться владельцем набора значений доступа. По умолчанию, эта ссылка на текущий объект.
Для использования шаблона, у каждого проверяемого вида объектов должна быть добавлена специальная табличная часть «Наборы значений доступа». В данную ТЧ перед записью объекта, помещаются значения доступа, которые должны быть доступны водной из групп доступа пользователя.
Сама же логика формирования значений видов доступа должна быть реализована в экспортной процедуре модуля объекта «ЗаполнитьНаборыЗначенийДоступа».
Пример из документа «Установка цен номенклатуры»
Все добавленные значения доступа проверяются по логическому «И». Если необходимо использовать более сложную проверку, можно заполнить дополнительный реквизит табличной части «Номер набора». Значения доступа, объединенные в разные наборы проверяются по логическому «ИЛИ».
Логика проверки будет следующей:
Само же заполнение табличной части объекта происходит в подписке на событие перед записью объекта «ЗаполнитьНаборыЗначенийДоступаТабличныхЧастей».
После этого в еще одной подписке на событие при записи объекта «ЗаписатьНаборыЗначенийДоступа», происходит перенос данных табличной части в специальный регистр сведений «Наборы значений доступа».
Шаблон #ПоНаборамЗначений при проверке разрешения на запись объекта, обращается к его табличной части, так как, если это новый объект, данных в регистре сведений еще нет. При проверке разрешения на чтение объекта, шаблон обращается к регистру сведений.
Шаблон #ПоЗначениям имеет одно серьезное ограничение – все заданные ограничения соединяются по логическому «И». Соответственно, нельзя указать такие условия, при которых объект будет доступен в случае доступности одного из нескольких указанных значений.
Для решения данной проблемы используется шаблон #ПоЗначениямРасширенный, который является расширенной версией шаблона #ПоЗначениям, и предоставляет возможности для применения логики «ИЛИ» для указания ограничений.
Как видно из примера, присутствуют дополнительные параметры, в которых можно задать логические связи используемых ограничений. Для указанного примера, документ будет доступен, при доступности организации и одного из двух кладов: «Склад отправитель» или «Склад получатель».
Также, в расширенном шаблоне можно указать дополнительные таблицы, которые необходимы для проверки. Допустим, можно указать табличную часть документа:
Реквизиты присоединенных таблиц также можно использовать в логике проверки доступности:
В случае с табличной частью, объект будет доступен, если будет доступен проверяемый реквизит (в данном случае «Номенклатура») хотя бы по одной строке.
Из-за того, что в шаблоне могут применяться дополнительные таблицы, требуется обязательное указания псевдонима основной таблицы «Т».
Последний, используемый шаблон предоставляет весь функционал предыдущего шаблона, с добавлением функционала шаблона #ПоНаборамЗначений. По сути, это объединение всех возможностей предыдущих шаблонов. Данный шаблон является самым «тяжелым» с точки зрения производительности, по этому не рекомендуется его применять без действительной необходимости.
Для реализации возможностей шаблона #ПоНаборамЗначений используется специальный вид доступа «Объект», с указанием ссылки на владельца наборов значений доступа, которые необходимо проверить:
В остальном, данный шаблон идентичен предыдущему шаблону.
Другие мои статьи по использованию механизмов БСП в типовых конфигурациях 1С
Использование подсистемы БСП «Заполнение объектов»
Новый подход к обмену данными EnterpriseData
Пример доработки правил конвертации без использования КД 3.0
Специальные предложения
Несмотря на то, что все это уже описано на ИТС, мне статья оказалась полезной для понимания тонкостей импользования шаблонов.
В свое время решал проблему производительности работы шаблона ПоЗначениямРасширенный, который из-за операции ИЛИ при соотношении малого количества разрешенных данных к большой выборке давал низкую производительность при выводе динамических списков. Недоразобравшись изобрел велосипед: добавил табличную часть и сделал свой запрос RLS, хотя мог бы использовать ПоНаборЗначений.
Такие обзорные статьи полезны: тот же материал, поданный по другому, позволяет увидеть тонкости, которые «замыленное» сознание не увидело в первоисточнике.
Честно говоря, складывается впечатление, что автор сам не понимает о чем пишет и переписал в своем исполнении инфу с ИТС, поэтому написано так же непонятно
После прочтения ИТС, лучше почитать «справку» в комментариях к самим шаблонам, тогда становиться более понятно
RLS – гибкая и тонкая настройка ограничений доступа к данным
Классическая задача: открыть пользователю доступ к какому-либо объекту, но не ко всем элементам / документам, а только к некоторым.
Или это может быть ограничение “все, кроме некоторых”.
Или ограничение не на справочники/документы, а на данные регистров…
По сути – это тонкая и очень гибкая настройка “что можно видеть этому пользователю, а о чем ему и не нужно догадываться”.
Почему именно RLS?
На большинстве внедрений требуется для разных пользователей установить различные уровни доступа к информации в базе.
В конфигурациях за возможные права доступа к данным отвечают специальные объекты метаданных – роли. Каждому пользователю информационной базы назначается одна или несколько ролей. Они определяют, возможны ли операции с конкретными объектами метаданных (чтение, запись, проведение и т.д.).
Часто бывает необходимо не просто открыть/запретить доступ к определенному объекту, а ограничить доступ к части данных в нем.
Только при помощи ролей решить такую задачу нельзя – для этого реализован механизм ограничения доступа на уровне записей (RLS).
Ограничения представляют собой условия, при выполнении которых действие над данными (чтение, запись и т.д.) будет разрешено. – так можно ограничить доступ не к объекту в целом, а только к части его данных.
Про RLS – более подробно: 8 видео и PDF
Поскольку это распространенная задача администрирования 1С – предлагаем посмотреть более детальные материалы:
PDF с вводной информацией.
21 страница, которые нужно прочесть сначала.
Видео 01:
Ограничение доступа к данным при помощи ролей
В этом видео рассказывается, как ограничивается доступ к данным при помощи ролей. Уточняется, что роли ограничивают доступ к виду объектов информационной базы (отдельный справочник, но не конкретные элементы справочника).
Видео 02:
Ограничение доступа на уровне записей (RLS)
В этом видео рассказывается о механизме ограничений доступа на уровне записей (RLS), когда можно настроить доступ не ко всему справочнику в целом, а к отдельным его элементам, в зависимости от хранящихся в информационной базе данных. Подобные ограничения прописываются в ролях.
Видео 03:
Реализация ограничения доступа на уровне записей для справочника Контрагенты
В этом видео рассказывается, как в демонстрационной конфигурации «Управляемое приложение» настроить доступ менеджеров только к собственным контрагентам, закрепленным за ними.
Видео 04:
Принцип работы ограничений доступа на уровне записей на низком уровне
В этом видео рассказывается, как платформа трансформирует запросы, передаваемые для выполнения на сервер СУБД, при наличии ограничений доступа на уровне записей.
Видео 05:
Совместное применение нескольких ограничений доступа на уровне записей
Пользователю информационной базы может быть назначено несколько ролей. При этом в каждой роли могут быть свои ограничения доступа на уровне записей. В этом видео рассказывается, как ведет себя система при наложении ограничений.
Видео 06:
Наложение ограничений методом ВСЕ
В этом видео описывается первый способ наложения ограничений на уровне записей – метод ВСЕ. При этом, если в выборку попадают записи, к которым доступ ограничен, будет выведено сообщение об ошибке.
Видео 07:
Наложение ограничений методом РАЗРЕШЕННЫЕ
В этом видео описывается первый способ наложения ограничений на уровне записей – метод РАЗРЕШЕННЫЕ. При этом в выборку попадут только те записи, к которым у пользователя есть права доступа.
Видео 08:
Исправление ошибки, возникающей из-за наложения прав доступа на уровне записей
В этом видео рассматривается, как при помощи ключевого слова РАЗРЕШЕННЫЕ исправить ошибку, возникающую под пользователем с ограниченными правами.
Не пропустите – все сразу и в полном объеме!
Этот курс позволит решать ВСЕ задачи по развертыванию и поддержке информационных систем на 1С.
Вот несколько тем из курса:
Даже на 3-5 пользователей. Тем более – если их хотя бы десяток…
Вам в любом случае когда-то придется разворачивать 1С, настраивать резервирование, права доступа, различные режимы запуска, тестировать целостность баз, обеспечивать работу серверов и т.д.
И лучше это сразу делать правильно.
Чтобы потом не было “…! Ну что за …! Твою же …!” – и прочих выражений сожаления 🙂
Комментарии / обсуждение (161):
Добрый день!
Используется конфигурация 1С:ERP 2.4. Учет в базе ведется более 3 лет, 150 пользователей.
Механизм ограничения доступа на уровне записей ранее не был включен. При включении опции “Ограничивать доступ на уровне записей” предупреждается, что выполнение заполнения данных при этом будет выполняться частями и может замедлить работу программы.
Вопрос 1. Заполнение данных, пусть и частями, будет выполнено один раз?
В курсе «Настройка и доработка прав доступа, профилей пользователей и RLS в типовых конфигурациях УТ 11.4 (11.3), КА 2.4 (2.2) и 1C:ERP 2.4 (2.2)» говорится, что при включенной указанной опции работа пользователей может быть замедлена в части работы интерфейса.
Вопрос 2. На сколько работа пользователей может быть замедлена, при размере базы 300 Гб?
Добрый день!
1. Для того, чтобы работали ограничения доступа на уровне записей, в служебных регистрах сведений должны быть записи, описывающие доступ к отдельным объектам.
До включения указанной галочки в регистрах не было нужных записей, значит, первоначально нужно сформировать эти записи по всей базе, затем поддерживать регистр в актуальном состоянии по мере заполнения базы новыми данными.
Для выполнения этого действия в конфигурациях на базе БСП (ERP как раз к таким относится) существует специальное регламентное задание, которое выполнит первоначальное заполнение (разовая операция), затем будет доформировывать записи для новых объектов (это уже будет регулярная операция, которая должна часто выполняться, чтобы для всех новых объектов базы были сформированы записи в регистрах, отвечающих за ограничения доступа).
2. Замедление работы зависит от нескольких факторов – какой режим ограничений будет выбран (стандартный и производительный), а также какое количество групп доступа будет у каждого пользователя. В общем случае – чем больше групп доступа у пользователя, тем сложнее может получиться запрос к СУБД, который извлекает данные из базы.
Поэтому рекомендуется провести нагрузочное тестирование на копии базы в условиях, приближенных к реальной работе пользователей. Тогда Вы точно сможете оценить степень замедления работы системы.
Добрый день!
Подскажите, пожалуйста, как можно с помощью шаблонов ограничения доступа ограничить доступ к данным некоторых отчетов. Например, есть профиль Менеджер по продажам, состоящий из нескольких ролей, у которого настроено ограничение доступа к группе партнеров. Исключения настроены в группе доступа. В отчете, например, Воронка продаж, нужно установить ограничение на разрешенную группу партнеров. А в другом отчете, например, Анализ встреч, по текущему пользователю, но также для пользователя с данным профилем.
Добрый день!
В типовых конфигурациях на базе БСП (например, УТ 11) в ролях используются стандартные шаблоны ограничений доступа из БСП.
Они универсальные, поэтому для решения большинства задач их не требуется менять. Предполагается, что настройку нужно выполнять в пользовательском режиме, создавая профили и группы доступа.
Если Вы ограничиваете доступ к справочнику Партнеры, оставляете доступными определенные группы, то в форме списка справочника, в списке документов, в отчетах будут видны данные только по этим разрешенным партнерам. Других (запрещенных) партнеров и данных по ним увидеть нельзя.
Если нужно в отчетах видеть не всех разрешенных партнеров, а только часть из них, то можно настроить отборы в отчете и сохранить такой вариант отчета. В отборе указать конкретных разрешенных партнеров, тогда отчет будет формироваться только по ним. Сохраненный вариант отчета можно разместить в Избранном, тогда пользователь сможет быстро формировать его, не выполняя предварительную настройку.
Добрый день, в учебной версии при использовании rls столкнулся с проблемой при записи или проведении документа (у пользователя недостаточно прав на использование операций над базой данных), причём в полной версии 1с данной проблемы не встречал.
В журнале регистраций ссылается на отказ доступа (действие-чтение)
Ограничение делал простое:
Как можно решить данную проблему?
Заранее огромное спасибо!
P.S.: не судите строго я недавно начал изучать 1с.
У учебной версии нет ограничений по RLS. Проверяйте, скорее всего у пользователя действительно недостаточно прав на использование операций над базой данных.
Добрый день!
Хотел уточнить, при установки ограничения по текущему пользователю на документ, сам пользователь проводить свои документы может или он их сможет только просмотреть и ему всё же будет отказано в доступе, как в моем случае?
Это зависит от-того на какое право наложено ограничение, чтение или запись.