Главная · Программы · 1c rls примеры. Конструктор ограничений доступа к данным

1c rls примеры. Конструктор ограничений доступа к данным

В системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).

Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.

1С RLS (Record Level Security) или ограничение прав на уровне записи — это прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.

Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).

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

Недостатки 1С 8 RLS

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

Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.

Настройка ограничения прав на уровне записей 1С RLS

Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:

  • Чтение
  • Добавление
  • Изменение
  • Удаление

Получите 267 видеоуроков по 1С бесплатно:

Внешне настройка RLS (прав на уровне записей) похожа на составление простого . Пример шаблона для ограничения доступа видимости документов по клиенту из шапки документа:

##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда

ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли

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

Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — « «. Как правило, они задаются при старте сессии пользователя.

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

Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:

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

Подготовка

Пример реализуем в демонстрационной конфигурации УПП 1.3. Создадим пользователя "Кладовщик" и добавим ему одноименную роль "Кладовщик".

Теперь приступим непосредственно к настройке прав доступа на уровне записей. Переключимся на интерфейс "Администрирование пользователе". В главном меню выберем "Доступ на уровне записей -> Параметры". Здесь отметим галкой "Ограничить доступ на уровне записей по видам объектов", а в списке объектов выберем "Организации".

Тем самым мы включили использование RLS. Теперь нужно его настроить.

Разграничение доступа на уровне записей настраивается не отдельно для каждого пользователя или профилей полномочий. RLS настраивается для групп пользователей. Добавим новую группу пользователей, назовем ее "Кладовщики"

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

В список объектов доступа для группы добавим организацию "ИЧП "Предприниматель"". Вид наследования прав оставим без изменений. Право на объект доступа установим для чтения и записи. Нажмем "ОК", настройки готовы. Мы только что настроили RLS на уровне организаций.

Что видит пользователь

Запустим программу под созданным ранее пользователем и откроем справочник "Организации". Вот так будет выглядеть список для нашего пользователя и для пользователя с полными правами:

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

Таким образом, пользователь не только не увидит организации, доступ на которые не установлен для него, но и не сможет прочитать/записать документы и другие объекты в информационной базе, на которые установлены права в роля на реквизит "Организация".

Мы рассмотрели простейший пример настройки RLS. В следующей статье поговорим о реализации механизма RLS в конфигурации "Управление производственным предприятием" версии 1.3.

В совете приведена пошаговая инструкция для настройки Record Level Sceurity (RLS) в Аксапте 3.0.

Где об этом написано в Документации

Русская версия: Users Guide for Admin (Russian)_3.0.pdf (стр.126)
Английская версия: User"s Guide for Administration (стр. 40, 101)

Введение


Ограничение прав на уровне записей (Record Level Security - RLS) позволет ограничить доступ к записям разным группам пользователей. Например, одна группа менеджеров может видеть российских клиентов, а другая - зарубежных. Причем менеджеры, работающие с российскими клиентами не должны видеть зарубежных клиентов. Мало того, менеджеры даже видеть их не должны.

RLS в Аксапте работает совместно с системой настройки обычных прав. Это значит, что для того, чтобы ограничить доступ к тому или иному полю таблицы, необходимо настроить обычные права на эти таблицу. Задача RLS - незаметно для пользователя отфильтровать записи.

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

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

Настройка

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

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

Можно приступать к настройке RLS:

  1. Настроим обычные права для группы тстГруппа1.

  • Теперь настроим RLS
  • Для созданной настройки отредактируйте запрос.
    • Нажмите на кнопку Запрос;

    • Собственно говоря, все! RLS настроен. Сейчас пользователь Тест получил права на чтение данных из модуля Расчеты с клиентами и право на создание и удаление заказов. Кроме того, на таблицу клиентов наложен фильтр. Начиная с этого момента, пользователи, принадлежащие группе тстГруппа1, смогут увидеть только прочих клиентов (клиентов, для которых установлена группа Прочие).

    Проверим настройку


    Зайдите в Аксапту под пользователем Тест. Откройте список клиентов (Главное меню \ Расчеты с клиентами \ Клиенты). Убедитесь, что список клиентов отображает только тех клиентов, для которых установлена группа с кодом Прч.

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

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

    Попробуйте наложить фильтр "*" на группу (Установите мышку на колонку Группа клиентов, нажмите правую кнопку, выберите пункт Найти..., введите фильтр "*").

    Попробуйте также наложить фильтр "!Прч". Попробуйте наложить фильтры на другие поля. Убедитесь, что фильтр по клиентами действительно работает правильно во всех случаях.

    Проверьте как работает RLS в отчетах. Откройте отчет со списком клиентов (Главное меню \ Расчеты с клиентами \ Отчеты \ Базовые данные \ Клиент). Попробуйте построить этот же отчет с фильтрами. Убедитесь, что фильтр по клиентам работает правильно и в отчетах.

    Обратите внимание, что программисту не нужно ничего изменять или переделывать, чтобы в его отчете заработал RLS, если он в формах или для построения отчетов использовал ядро и не переопределял механизм получения данных. Если же программист вручную кодировл запросы, то ему необходимо добавить вызов метода recordLevelSecurity(true) для тех таблиц, где необходимо включить ограничение доступа на записи. См. подробнее руководство разработчика по ключевому слову Record Level Security.

    Откройте заказы. Оп! А заказы показываются по всем клиентам. Почему? А потому, что в заказах содержатся коды клиентов, а не сами клиенты. Попробуйте перейти к основной таблице с клиентами - вы не сможете увидеть параметры скрытых клиентов.


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

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

    RLS для нескольких групп

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

    Предположим, что одна группа менеджеров имеет доступ к Прочим клиентам (группа клиентов = Прч), а другая группа менеджеров имеет доступ к Обычным клиентам (группа клиентов = ТиУ). Первую группу мы уже настроили. Остается настроить вторую группу.

    Повторите шаги 8-10. Только установите группе тстГруппа2 полные права на модуль Расчеты с клиентами и и в качестве критерия укажите "ТиУ" в настройке RLS для групы тстГруппа2.

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

    Что произойдет, если у клиента изменить группу? В форме клиент будет виден до тех пор, пока он не уйдет за пределы экранной формы. Как только Аксапта считает заново данные с сервера, сработает RLS и менеджер больше не увидит "чужого" клиента.

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

    Для того, чтобы некоторым пользователям разрешить доступ ко всему списку клиентов, необходимо третьей группе дать права на таблицу клиентов, но не настраивать RLS. Axapta смотрит на обычные права доступа. И, если право доступа есть, то смотрит в настройки RLS. Если для данной группы и данной таблицы настроек RLS нет, то Аксапта показывает все записи из таблицы.

    Обратите внимание, что группа тстГруппа3 не влияла на поведение RLS до тех пор пока она не имела прав на таблицу клиентов. Как только в этой группе появилось право на клиентов, так сразу эта группа стала участвовать в RLS. Чтобы проверить этот тезис, уберите права на модуль Расчеты с клиентами в группе тстГруппа2 и проверьте RLS для клиента Тест. Вы увидите только прочих клиентов.

    Начиная с платформы 8.0 системы 1С Предприятие, существует возможность ограничивать права доступа пользователей на уровне записей. Для этого используется механизм RLS (Record Level Security). Такая «тонкая» настройка может быть полезна для ограничения доступа по организациям, клиентам, номенклатуре и др.

    RLS - это возможность разработчика задать условие на таблицы базы данных для тех или иных пользователей (групп пользователей) и не дать им увидеть лишнего. Условие имеет булевый тип. Если значение условия принимает значение «истина», то доступ предоставляется, в противном случае – запрещается.

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

    RLS применяется для следующих видов прав доступа:
    * Чтение
    * Добавление
    * Изменение
    * Удаление

    Порядок настройки RLS

    Рассмотрим простой пример выполнения настройки. Снимки экрана сделаны на версии 1С Предприятие 8.2 (8.2.9.356). Синтаксис шаблонов текстов ограничений описан в документации по 8.2 в книге «Руководство разработчика. Часть 1», поэтому на нем останавливаться не будем.

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

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

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

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

    Вот и все. Можно проверить результат.

    Недостатки использования RLS:
    1. Применение механизма ограничения доступа на уровне записей приводит к неявному увеличению таблиц, участвующих в запросе, что может привести к ошибкам в клиент-серверном режиме работы базы данных.
    2. Для контроля записи бывает трудно или невозможно реализовать сложную логику приложения. В таких случаях лучше использовать условия в процедуре ПриЗаписи().
    3. Написание условия (запроса) требует определенной квалификации разработчика.
    4. Дополнительные трудности может создать невозможность отладки условия (запроса).

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

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

    Информация взята с сайта