Рассматриваемые параметры в 1С:Предприятие представлены в виде объекта метаданных. По существу, это не что иное, как глобальная переменная, привязанная к текущему сеансу.
Рис.1 Параметры в виде объекта метаданных
Глобальная переменная – такая же переменная, как и любая другая, но особенность ее в том, что обратиться к ней можно из любой точки программы, а в случае с параметром сеанса это работает только в пределах текущего сеанса.
Поскольку параметр сеанса является объектом метаданных, он имеет определенные особенности:
- Он может быть определенного типа. Разрешенные типы определяются платформой. Перечень их достаточно обширный, но даже если в данном списке нет нужного для вас, всегда можно сериализовать значение и хранить его в параметре в виде строки.
Рис.2 Хранение в параметре в виде строки
- Права на него, как и на любой другой объект метаданных, можно ограничивать ролями (как на запись, так и на чтение). При этом существует особенность при использовании его в RLS, но об этом будет написано ниже.
- Он имеет ограничение на объем помещаемых данных в сериализованном виде. Их объем не должен превышать 4 Гб.
Если тип параметра сеанса:
- ФиксированныйМассив
- ФиксированнаяКоллекция
- ФиксированнаяСтруктура
Тогда значение элемента коллекции может быть Неопределено.
Основная область параметров – применение их значений в запросах RLS (ограничение доступа на уровне записей).
Например, нам нужно в запросе RLS установить условие по текущему пользователю. Для этого заводим параметр сеанса «ТекущийПользователь», из кода встроенного языка устанавливаем значение:
ПараметрыСеанса.ТекущийПользователь =
Далее в запросе RLS позволено обращаться к данному параметру:
Таблица.Пользователь = &ТекущийПользователь
При таком использовании параметра сеанса права на чтение параметра не учитываются, однако можно попытаться получить их значение из встроенного языка:
ТекущийПользователь = ПараметрыСеанса.ТекущийПользователь;
При этом у текущего пользователя должны быть права на получение (чтение) значения.
Рис.3 При этом у текущего пользователя должны быть права на получение (чтение) значения
Установить параметр сеанса, то есть его значение, можно только программно и только на сервере. Для этого с клиента потребуется вызвать серверную процедуру. При обращении к параметру сеанса (установка, получение), если параметр не инициализирован, будет вызвана процедура УстановкаПараметровСеанса в модуле сеанса. Данная процедура имеет один параметр ТребуемыеПараметры – массив устанавливаемых идентификаторов параметров сеанса. УстановкаПараметровСеанса вызывается также при установке соединения с информационной базой до вызова всех остальных обработчиков. В этом случае ТребуемыеПараметры будет равен Неопределено.
Рекомендовано использовать отложенную (ленивую) инициализацию, то есть инициализировать параметры сеанса по требованию, а не при старте системы, так как не все параметры сеанса требуются непосредственно при старте системы. Отложенная инициализация выполняется так:
Процедура УстановкаПараметровСеанса(ИменаПараметровСеанса) Если ИменаПараметровСеанса Неопределено Тогда Если ИмяПараметра = «ТекущийПользователь» Тогда ПараметрыСеанса.ТекущийПользователь = ; ИначеЕсли ИмяПараметра = » ТекущаяОрганизация» Тогда ПараметрыСеанса.ТекущаяОрганизация = ; // и т.д. КонецЕсли; КонецЕсли; КонецПроцедуры
Так как параметр сеанса привязан к сеансу, не получится обратиться к параметру сеанса из метода, выполняющегося в фоне, поскольку это будет уже другой сеанс. Этот нюанс может стать неожиданностью, поэтому лучше к нему подготовиться заранее, передав нужное значение как параметр метода и инициализировав из параметра сеанса в начале процедуры.
С помощью RLS можно скрыть некоторые записи от пользователей, которые не должны их видеть.
Такую настройку можно привязать чисто к роли, или же создать справочник, в котором будет информация о том, какой пользователь к чему имеет доступ. Типичный пример — никто кроме расчетчика и кадровика не должен видеть РКО с видом операции «Выплата зарплаты». Делаем справочник, к примеру «Группы доступа РКО», а в его табличной части добавляем два реквизита: 1) пользователь, 2) Вид операции РКО. И к примеру далее отталкиваемся от того, что если есть комбинация Пользователь/Вид операции РКО — тогда пользователю можно видеть РКО с таким видом операций.
Касательно ролей, есть один интересный вопрос: Что если в одной роли есть ограничение доступа на уровне записей, а в другой нет? Будет ли ограничение потому что в одной из ролей оно есть, или не будет, потому что в другой роли его нет? В этом случае 1С будет работать привычным для программиста образом — Если хотя бы в одной роли что то разрешено, то разрешение преобладает над запретом. Иными словами в описанном случае ограничение доступа не будет действовать, будут видны все записи.
Поэтому обычно используют две роли: «Пользователь», и «Наша Роль» — в которой мы и творим ограничение на уровне записей, далее (ОУЗ
(RLS) ).
Можно поступить хитрее. Для всех ролей внести ОУЗ
(RLS) , а для отдельной роли нет. И у кого будет эта роль — тот будет видеть все записи.
Роли, у которых нет прав на данный объект, не влияют на ОУЗ (RLS) . Поэтому вносить правило можно только в роли, у которых имеется доступ к объекту, который мы хотим ограничить.
ОУЗ используется только для действий «Чтение»,»Изменение»,»Добавление» и «Удаление». Причем для каждого действия правила могут быть различными. Это дает большую гибкость.
По сути ОУЗ (RLS) — это запрос, со своими конечно ограничениями. Видны будут те записи, которые войдут в этот запрос. При этом в запросе нет полей, только таблицы. По умолчанию это текущая таблица (справочник или документ и т.д), в которой мы настраиваем ОУЗ (RLS) . Можно использовать произвольные таблицы.
Таким образом запрос вида «ГДЕ ЛОЖЬ» сделает то, ни одной записи мы не увидим. А «ГДЕ ИСТИНА» — покажет все записи. Что касается нашего РКО, то чтобы не увидели зарплатные документы, запрос будет выглядеть так
ГДЕ
ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыРаботнику)
И
ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыПоВедомостям)
То же самое будет, если обратиться напрямую к таблице
ТекущаяТаблица ИЗ Документ.РасходныйКассовыйОрдер КАК ТекущаяТаблица ГДЕ
ТекущаяТаблица.ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыРаботнику)
И
ТекущаяТаблица.ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыПоВедомостям)
Есть специальные зарезервированные фразы, которые начинаются с символа #. Так можно обратиться к текущей таблице с помощью выражения #ТекущаяТаблица. Зачем это нужно, для универсальности наверно. Использовать псевдонимы можно и нужно, если у вас используется несколько таблиц, у которых есть одинаковые реквизиты. В предыдущем запросе вы увидели, как мы создали псевдоним «ТекущаяТаблица» для таблицы «Документ.РасходныйкассовыйОрдер». А можно то же самое сделать вот так.
1С (Код)
1 2 3 4 5 6 7 | ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица ГДЕ ТекущаяТаблица.ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыРаботнику) И ТекущаяТаблица.ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыПоВедомостям) |
Если такой запрос с выражением «#ТекущаяТаблица» использовать в разных объектах, то каждый раз будет иметься ввиду именно таблица этого объекта. То-есть — это относительная ссылка на таблицу конкретного документа, справочника, регистра, в котором используется данное выражение.
Как вы заметили — в запросах ОУЗ нет слова ВЫБРАТЬ и так же нет полей. Зачем последние два запроса начинаются со слова «ТекущаяТаблица» — если это псевдоним таблицы, сказать не могу. Просто все так делают.
Покажу ещё пример, как сделал настраиваемые ограничения, с помощью нового справочника. Здесь присутствует объединения. Пользователь не видит продажи отчетах по регистру «Продажи», у которых ему не имеется соответствующей строки «пользователь/склад» в этом справочнике.
1С (Код)
1 2 3 4 5 6 | ТекущаяТаблица ИЗ РегистрНакопления.Продажи КАК ТекущаяТаблица ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ГруппыДоступаСкладов.Склады КАК ГруппыДоступаСклады ПО ( ТекущаяТаблица.Подразделение = ГруппыДоступаСклады.Склад.Подразделение ) И (ГруппыДоступаСклады.Ссылка.Пользователь = &ТекущийПользователь)) |
Здесь мы увидели новый элемент — такой как &ТекущийПользователь. Это параметр. Параметры берутся из одноименных переменных сеанса. По другому установить параметры для отбора невозможно.
Если у пользователя нет доступа к какому нибудь из объектов , указанных в запросе (Например «Справочник.ГруппыДоступаСкладов») , то ограничение будет вести себя неожиданно. Например, в форме самого регистра «Продажи» он будет действовать, а при выборке из обработки — будут видны все записи без ограничений.
Как видите, пользователь будет видеть только те записи, в которых склад соответствует строчке из табличной части справочника в которой указаны склады, к записям с которымы пользователь имеет возможность видеть. И в шапке справочника указан сам пользователь. Какой справочник придумать — это зависит от вашей фантазии. У меня он выглядит так:
Куда вводятся правила ОУЗ (RLS) в 1С 8. Есть много способов записать эти правила. Можно их писать непосредственно в документе, в роли, в окне «Все роли», в окне «Ограничения доступа». Выбираете роль, объект, и действие (чтение, запись, изменение или удаление) — и в поле редактирования нужно написать правило.
В окне редактирования одной роли, или в окне редактирования «Все ограничения доступа» имеется закладка «Шаблоны ограничений», в котором можно написать шаблон, а потом вместо того, чтобы каждый раз копировать весь запрос, вносить только имя шаблона в формате #ИмяШаблона. Это предпочтительный метод, так как при изменении запроса не нужно искать и переклацывать его повсюду.
Каждая отдельно взятая роль «видит» только свои шаблоны. Так что для использования того же запроса в другой роли, нужно в ней создать аналогичный шаблон.
Изменили шаблон, и всё. Вот для примера на картинке мы создали шаблон.
А вот мы им воспользовались.
или так, в окне «Все роли»
Или так, в окне «Все ограничения доступа».
Кто не знает, это в окне метаданных нужно открыть «Общие» ->»Роли» и щелкнуть по пункту «Роли» правой кнопкой мыши, и выбрать нужный пункт.
Кстати в окне «Все ограничения доступа» есть удобный конструктор запроса. А вот в шаблонах почему то конструктора нет. Поэтому для удобства первоначально можно создать запрос в этом конструкторе, а затем скопировать в шаблон и там уже корректировать при необходимости.
Для этого откройте для редактирования нужную строчку ограничений, и выберите кнопку конструктора.