Кварц

Рассматриваемые параметры в 1С:Предприятие представлены в виде объекта метаданных. По существу, это не что иное, как глобальная переменная, привязанная к текущему сеансу.

Рис.1 Параметры в виде объекта метаданных

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

Поскольку параметр сеанса является объектом метаданных, он имеет определенные особенности:

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

Рис.2 Хранение в параметре в виде строки

• Права на него, как и на любой другой объект метаданных, можно ограничивать ролями (как на запись, так и на чтение). При этом существует особенность при использовании его в RLS, но об этом будет написано ниже.
• Он имеет ограничение на объем помещаемых данных в сериализованном виде. Их объем не должен превышать 4 Гб.

Если тип параметра сеанса:

• ФиксированныйМассив
• ФиксированнаяКоллекция
• ФиксированнаяСтруктура

Тогда значение элемента коллекции может быть Неопределено.

Основная область параметров – применение их значений в запросах RLS (ограничение доступа на уровне записей).

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

ПараметрыСеанса.ТекущийПользователь =

Далее в запросе RLS позволено обращаться к данному параметру:

Таблица.Пользователь = &ТекущийПользователь

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

ТекущийПользователь = ПараметрыСеанса.ТекущийПользователь;

При этом у текущего пользователя должны быть права на получение (чтение) значения.

Рис.3 При этом у текущего пользователя должны быть права на получение (чтение) значения

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

Рекомендовано использовать отложенную (ленивую) инициализацию, то есть инициализировать параметры сеанса по требованию, а не при старте системы, так как не все параметры сеанса требуются непосредственно при старте системы. Отложенная инициализация выполняется так:

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

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

С помощью RLS можно скрыть некоторые записи от пользователей, которые не должны их видеть.

Такую настройку можно привязать чисто к роли, или же создать справочник, в котором будет информация о том, какой пользователь к чему имеет доступ. Типичный пример — никто кроме расчетчика и кадровика не должен видеть РКО с видом операции «Выплата зарплаты». Делаем справочник, к примеру «Группы доступа РКО», а в его табличной части добавляем два реквизита: 1) пользователь, 2) Вид операции РКО. И к примеру далее отталкиваемся от того, что если есть комбинация Пользователь/Вид операции РКО — тогда пользователю можно видеть РКО с таким видом операций.

Касательно ролей, есть один интересный вопрос: Что если в одной роли есть ограничение доступа на уровне записей, а в другой нет? Будет ли ограничение потому что в одной из ролей оно есть, или не будет, потому что в другой роли его нет? В этом случае 1С будет работать привычным для программиста образом — Если хотя бы в одной роли что то разрешено, то разрешение преобладает над запретом. Иными словами в описанном случае ограничение доступа не будет действовать, будут видны все записи.

Поэтому обычно используют две роли: «Пользователь», и «Наша Роль» — в которой мы и творим ограничение на уровне записей, далее (ОУЗ
(RLS) ).

Можно поступить хитрее. Для всех ролей внести ОУЗ
(RLS) , а для отдельной роли нет. И у кого будет эта роль — тот будет видеть все записи.

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

ОУЗ используется только для действий «Чтение»,»Изменение»,»Добавление» и «Удаление». Причем для каждого действия правила могут быть различными. Это дает большую гибкость.

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

Таким образом запрос вида «ГДЕ ЛОЖЬ» сделает то, ни одной записи мы не увидим. А «ГДЕ ИСТИНА» — покажет все записи. Что касается нашего РКО, то чтобы не увидели зарплатные документы, запрос будет выглядеть так

ГДЕ
ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыРаботнику)
И
ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыПоВедомостям)

То же самое будет, если обратиться напрямую к таблице

ТекущаяТаблица ИЗ Документ.РасходныйКассовыйОрдер КАК ТекущаяТаблица ГДЕ
ТекущаяТаблица.ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыРаботнику)
И
ТекущаяТаблица.ВидОперации<>Значение(Перечисление.ВидыОперацийРКО.ВыплатаЗаработнойПлатыПоВедомостям)

Есть специальные зарезервированные фразы, которые начинаются с символа #. Так можно обратиться к текущей таблице с помощью выражения #ТекущаяТаблица. Зачем это нужно, для универсальности наверно. Использовать псевдонимы можно и нужно, если у вас используется несколько таблиц, у которых есть одинаковые реквизиты. В предыдущем запросе вы увидели, как мы создали псевдоним «ТекущаяТаблица» для таблицы «Документ.РасходныйкассовыйОрдер». А можно то же самое сделать вот так.

1С (Код)

Если такой запрос с выражением «#ТекущаяТаблица» использовать в разных объектах, то каждый раз будет иметься ввиду именно таблица этого объекта. То-есть — это относительная ссылка на таблицу конкретного документа, справочника, регистра, в котором используется данное выражение.

Как вы заметили — в запросах ОУЗ нет слова ВЫБРАТЬ и так же нет полей. Зачем последние два запроса начинаются со слова «ТекущаяТаблица» — если это псевдоним таблицы, сказать не могу. Просто все так делают.

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

1С (Код)

Здесь мы увидели новый элемент — такой как &ТекущийПользователь. Это параметр. Параметры берутся из одноименных переменных сеанса. По другому установить параметры для отбора невозможно.

Если у пользователя нет доступа к какому нибудь из объектов , указанных в запросе (Например «Справочник.ГруппыДоступаСкладов») , то ограничение будет вести себя неожиданно. Например, в форме самого регистра «Продажи» он будет действовать, а при выборке из обработки — будут видны все записи без ограничений.

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

Куда вводятся правила ОУЗ (RLS) в 1С 8. Есть много способов записать эти правила. Можно их писать непосредственно в документе, в роли, в окне «Все роли», в окне «Ограничения доступа». Выбираете роль, объект, и действие (чтение, запись, изменение или удаление) — и в поле редактирования нужно написать правило.

В окне редактирования одной роли, или в окне редактирования «Все ограничения доступа» имеется закладка «Шаблоны ограничений», в котором можно написать шаблон, а потом вместо того, чтобы каждый раз копировать весь запрос, вносить только имя шаблона в формате #ИмяШаблона. Это предпочтительный метод, так как при изменении запроса не нужно искать и переклацывать его повсюду.

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

Изменили шаблон, и всё. Вот для примера на картинке мы создали шаблон.

А вот мы им воспользовались.

или так, в окне «Все роли»

Или так, в окне «Все ограничения доступа».

Кто не знает, это в окне метаданных нужно открыть «Общие» ->»Роли» и щелкнуть по пункту «Роли» правой кнопкой мыши, и выбрать нужный пункт.

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

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