Восьмая версия платформы «1С:Предприятие» (сегодня 8.3) несла в себе множество изменений по отношению к «семерке», среди которых особенно выделялся механизм ограничения прав доступа на уровне записей. Несмотря на то, что можно, теоретически, обойтись и без него, используя исключительно роли, RLS позволяет добиться более тонкой настройки доступа. Но для правильной эксплуатации этого механизма, нужно четко понимать его суть и иметь достаточный опыт в разработке в 1С.
Суть этого функционала заключается в возможности разработчика предотвратить доступ определенного пользователя или группы пользователей к таблицам или полям таблиц базы данных. Обычно ограничения используются, чтобы не дать возможность пользователям 1С увидеть и отредактировать конфиденциальную, секретную информацию, например, ограничить сотрудников компании, входящей в группу, просмотром документов только по своей организации. Также механизм ограничений прав доступа на уровне записи можно использовать, чтобы убрать лишнюю информацию из интерфейса.
Чтобы получить возможность писать запросы для ограничений по RLS, необходимо создать роль или взять уже имеющуюся. Настройка RLS в 1С 8.3 может применяться для следующих действий пользователя:
Кроме широчайших возможностей настройки доступа, RLS несут в себе и недостатки:
Еще одной проблемой, которая может возникнуть уже после настройки 1С RLS, могут стать отчеты. Дело в том, что разработчики предусматривают возможные ограничения RLS и строят отчеты таким образом, чтобы они показывали лишь разрешенные данные. Если у пользователей настроены разные ограничения RLS, то и данные в отчете по одинаковым параметрам у них могут быть разные. Это может вызвать вопросы, поэтому при проектировании отчетов или написании запросов в RLS нужно учесть подобные ситуации.
Для того чтобы добавить ограничение по RLS, необходимо найти нужную роль и открыть ее двойным щелчком.
Открывшееся окно содержит 2 вкладки: «Права» и «Шаблоны ограничений». Чтобы наложить определенные ограничения на конкретное действие, необходимо выделить его и в правой нижней части нажать на зеленый плюс. Появиться строчка, в которой мы сможем задать ограничения 1С RLS на встроенном в 1С языке.
Если вы знаете синтаксис 1С (как свои пять пальцев), то можете писать прямо в поле «Ограничение доступа». Разработчики 1С предусмотрели возможность открывать конструктор запроса, который поможет и подскажет, на что можно сделать ограничение. Чтобы его открыть, нужно нажать на кнопку с тремя точками (Выбрать) или F4 и появиться окно с кнопкой «Конструктор запроса…».
В появившемся окне вы сможете настроить ограничения не только по данному справочнику, но и по другим объектам системы. Для этого необходимо добавить их на вкладке «Таблицы и поля». Прописываем ограничения на поля справочника «Номенклатура» и нажимаем на «ОК». Внимательно относитесь к названию переменных: параметры RLS задаются при старте сессии пользователя и должны содержаться в объекте метаданных.
На вкладке «Шаблоны ограничений» задаются запросы, которые необходимы при копировании одинаковых настроек RLS в 1С 8.3. После того как вы добавили свой шаблон, по его имени можете обращаться в настройках прав доступа.
Также есть возможность одновременно добавлять ограничения на несколько ролей. Для этого в дереве конфигурации необходимо нажать правой кнопкой мыши на раздел «Роли» и выбрать пункт «Все роли».
В качестве заключения хотелось бы отметить, что данная статья направлена на консультантов-разработчиков 1С и может помочь в первую очередь тем, кто уже имел опыт разработки на «1С:Предприятие». Несмотря на кажущуюся простоту, знание семантики и понимание структуры бизнес-процессов собственного предприятия или организации заказчика для правильной раздачи прав – требуют определенного уровня знаний и опыта.
В совете приведена пошаговая инструкция для настройки 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:
Собственно говоря, все! RLS настроен. Сейчас пользователь Тест получил права на чтение данных из модуля Расчеты с клиентами и право на создание и удаление заказов. Кроме того, на таблицу клиентов наложен фильтр. Начиная с этого момента, пользователи, принадлежащие группе тстГруппа1, смогут увидеть только прочих клиентов (клиентов, для которых установлена группа Прочие).
Зайдите в Аксапту под пользователем Тест. Откройте список клиентов (Главное меню \ Расчеты с клиентами \ Клиенты). Убедитесь, что список клиентов отображает только тех клиентов, для которых установлена группа с кодом Прч.
Обратите внимание, что в главном меню открылась не только закладка Расчеты с клиентами. Открылась также закладки Главная книга, Денежные средства, CRM, Управление запасами, Основное. Дело в том, что дав права на модуль клиентов, мы затронули множество таблиц из других модулей. Да, конечно, ненужные закладки почти пустые. Но все равно, в реальной жизни права надо давать намного аккуратнее.
Кроме того, в реальной жизни никогда не появляются закладки из незакупленных модулей. Например, попробуйте отключить модуль CRM в настройке конфигурационных ключей.
Попробуйте наложить фильтр "*" на группу (Установите мышку на колонку Группа клиентов, нажмите правую кнопку, выберите пункт Найти..., введите фильтр "*").
Попробуйте также наложить фильтр "!Прч". Попробуйте наложить фильтры на другие поля. Убедитесь, что фильтр по клиентами действительно работает правильно во всех случаях.
Проверьте как работает RLS в отчетах. Откройте отчет со списком клиентов (Главное меню \ Расчеты с клиентами \ Отчеты \ Базовые данные \ Клиент). Попробуйте построить этот же отчет с фильтрами. Убедитесь, что фильтр по клиентам работает правильно и в отчетах.
Обратите внимание, что программисту не нужно ничего изменять или переделывать, чтобы в его отчете заработал RLS, если он в формах или для построения отчетов использовал ядро и не переопределял механизм получения данных. Если же программист вручную кодировл запросы, то ему необходимо добавить вызов метода recordLevelSecurity(true) для тех таблиц, где необходимо включить ограничение доступа на записи. См. подробнее руководство разработчика по ключевому слову Record Level Security.
Откройте заказы. Оп! А заказы показываются по всем клиентам. Почему? А потому, что в заказах содержатся коды клиентов, а не сами клиенты. Попробуйте перейти к основной таблице с клиентами - вы не сможете увидеть параметры скрытых клиентов.
Вообще говоря, в реальной жизни для настройки ограничения на уровне прав доступа недостаточно настроить одну таблицу. Как правило взаимосвязанные ограничения необходимо накладывать на несколько связанных таблиц.
Права доступа на уровне записей действуют не только в формах и отчетах, но и в выпадающих списках. Откройте заказ и нажмите на кнопку выпадающего списка у клиента. Да, все правильно. Пользователь Тест видит только прочих клиентов.
Теперь рассмотрим ситуацию, когда необходимо настроить несколько разных групп с разными правами и с разными ограничениями прав.
Предположим, что одна группа менеджеров имеет доступ к Прочим клиентам (группа клиентов = Прч), а другая группа менеджеров имеет доступ к Обычным клиентам (группа клиентов = ТиУ). Первую группу мы уже настроили. Остается настроить вторую группу.
Повторите шаги 8-10. Только установите группе тстГруппа2 полные права на модуль Расчеты с клиентами и и в качестве критерия укажите "ТиУ" в настройке RLS для групы тстГруппа2.
Для проверки зайдите в Аксапту под пользователем Тест и убедитесь, что формы и отчеты работают корректно, убедитесь, что вы получили полные права на клиентов и можете редактировать параметры клиентов.
Что произойдет, если у клиента изменить группу? В форме клиент будет виден до тех пор, пока он не уйдет за пределы экранной формы. Как только Аксапта считает заново данные с сервера, сработает RLS и менеджер больше не увидит "чужого" клиента.
Этот пример снова показывает, что права надо настраивать комплексно. В данной ситуации можно либо запретить менеджерам редактирование поля группа клиентов, либо настроить ограничение на уровне записей (RLS) и на таблицу с группами.
Для того, чтобы некоторым пользователям разрешить доступ ко всему списку клиентов, необходимо третьей группе дать права на таблицу клиентов, но не настраивать RLS. Axapta смотрит на обычные права доступа. И, если право доступа есть, то смотрит в настройки RLS. Если для данной группы и данной таблицы настроек RLS нет, то Аксапта показывает все записи из таблицы.
Обратите внимание, что группа тстГруппа3 не влияла на поведение RLS до тех пор пока она не имела прав на таблицу клиентов. Как только в этой группе появилось право на клиентов, так сразу эта группа стала участвовать в RLS. Чтобы проверить этот тезис, уберите права на модуль Расчеты с клиентами в группе тстГруппа2 и проверьте RLS для клиента Тест. Вы увидите только прочих клиентов.
Настройка доступа на уровне записей справочников.
Данная настройка в конфигурацию была включена не так давно, я лично считаю, что настройка весьма полезная.
Данная настройка необходима тем, кому необходимо разграничить доступ к справочнику в разрезе элементов этого справочника. Например, менеджеру необходимо видеть только покупателей, а также отчеты и журналы документов, только по контрагентам, к которым ему разрешен доступ, а бухгалтеру необходимо иметь полный доступ ко всем элементам справочника, к примеру «Контрагенты».
Предлагаю рассмотреть пример на примере конфигурации УПП.
Администраторы;
Менеджеры продаж;
Менеджеры закупок;
Покупатели;
Поставщики;
Обычно вышеописанные списки групп обсуждаются с руководством и только после вводятся в программу.
Теперь необходимо описать собственно те настройки, которые нужно выполнить в 1С.
Откроется форма обработки «Параметры доступа на уровне записей» см. Рис. 2.
На данной форме необходимо собственно включить ограничение, за что отвечает флаг «Ограничить доступ на уровне записей по видам объектов» и выбрать те справочники, по которым ограничение будет действовать. В данной статье рассматривается только справочник «Контрагенты».
Группы контрагентов вводятся в справочнике «Группы пользователей» см. Рис. 3.
Откроется форма элемента справочника «Группы пользователей» см. Рис. 4.
В левой части окна указывается объект доступа (у нас это «контрагенты»), справа указываются пользователи, которые входят в группу, в данном примере это «Администраторы».
Для каждой группы пользователей определенной вами необходимо выполнить данную настройку, не должно остаться ни одного пользователя, который не входит в группу.
Для нашего примера это: Покупатели, Поставщики, Прочие. См. Рис. 6.
Группа доступа для контрагента назначается на закладке «прочие». Обычно я использую вспомогательную стандартную обработку для назначения данных групп. «Групповая обработка справочников и документов», она позволяет массово установить нужную группу для этого реквизита.
Красным цветом выделено отношение групп пользователей к группам доступа контрагентов. Для групп «Менеджеры закупа» и «Менеджеры продаж» настраиваются отношения точно также, только объекты доступа указываются те к которым они должны иметь доступ, например, только «Поставщики» или только «Покупатели». Флаги, к примеру «Видимость в списке» это права «Объекта доступа». Из названия я думаю, что понятна и функциональность этих прав.
После выше указанных манипуляций у Вас должен появиться разграниченный доступ к справочнику «Контрагенты».
По аналогии настраиваются и остальные справочники.
Важно:
Разграниченный доступ не распространяется на роль «ПолныеПрава»;
В наборе ролей пользователя должна присутствовать роль «Пользователь»;
Если у Вас собственные роли, то необходимо в вашу роль вставить шаблоны и ограничения как в роли «Пользователь» по отношению к справочнику «Контрагенты» (см. код в роли Пользователь кликнув на справочнике контрагенты).
Конструктор ограничений позволяет составить ограничения доступа на уровне записей и полей базы данных. Список ограничений доступен из контекстного меню ветки Роли дерева конфигурации; конструктор вызывается при добавлении нового ограничения (кнопка Далее
) или редактировании существующего:
Для вызова конструктора при создании нового ограничения нажимаем кнопку Конструктор запроса:
Язык конструирования ограничений похож на язык запросов, конструктор соответственно тоже. В нем можно определить одну или несколько связанных таблиц, по которым будут задаваться ограничения:
Само ограничение также формулируется в виде текста запроса:
Вопрос 04.51 экзамена 1С:Профессионал по платформе. В конструкторе ограничений доступа к данным:
Правильный ответ третий. Если в конструкторе задано несколько таблиц с данными, то в нем появляется закладка Связи:
В которой и можно прописать ограничения, связанные с другими таблицами:
Вопрос 04.52 экзамена 1С:Профессионал по платформе. При определении ограничения доступа в конструкторе ограничений доступа к данным...
Правильный ответ третий - можно конструктором, можно вручную.
Вопрос 04.53 экзамена 1С:Профессионал по платформе. При определении ограничения доступа в конструкторе ограничений доступа к данным:
Правильный ответ третий, нужны обе закладки, иначе зачем они.
Вопрос 04.54 экзамена 1С:Профессионал по платформе. При определении ограничения доступа в конструкторе ограничений доступа к данным текст условия:
Правильный ответ четвертый - в отличие от языка запросов, слова Выбрать тут нет.
Вопрос 07.01 экзамена 1С:Профессионал по платформе. При настройке ограничения доступа к данным допускается установка нескольких (по числу полей) ограничений:
Роль является объектом метаданных, благодаря которому определяется, к какому объекту и какие действия над этим объектом может выполнять тот или иной пользователь. Каждая роль содержит права и в зависимости от того какие права установит администратор БД будут происходить разграничения доступа. В технологической платформе предусмотрено два типа прав, это: основные и интерактивные. Под основными понимаются права на Чтение, Изменение,Добавление и Удаление. Интерактивные осуществляются только при выполнение таких операций, как редактирование или удаление в форме: Интерактивное удаление, Интерактивное добавление и другие.
Таким образом можно раз и навсегда включить доступ к тому или иному справочнику, документу и другим объектом метаданных, причем целиком. Вы можете дать доступ или забрать. Дать на немножко у вас не получиться. Но ведь часто возникает такая ситуация, когда существует, к примеру, огромный справочник и каждый пользователь должен видеть только определенные элементы в нем. То есть по какому- то определенному условию должен происходить отбор элементов объекта! И вот начиная с версии технологической платформы 1С 8.1 появился очень мощный механизм ограничения доступа к данным на уровне записей под названием RLS (Record Level Security). Ограничения представляют собой набор определенных условий, при выполнении которых будет предоставлять доступ или нет.
Ограничения доступа при использовании динамической системы RLS применяется к основным операциям: Чтение, Изменение, Добавление и Удаление. Существует важная особенность, заключающаяся в том, что к операции Чтение может быть применено несколько ограничений на уровне записей, в то время как ко всем остальным операциям только одно условие. Данный механизм позволяет накладывать ограничения не только на определенные записи, но и на определенные поля записей. При чем указать возможно нужно поле, а так же специальное поле <Прочие поля>.
Язык ограничения данных представляет собой ничто иное как язык запросов, но очень сильно урезанный. Если условие принимает значение ИСТИНА, то текущему пользователю предоставляется доступ к данным, если же ЛОЖЬ, тогда отказ. Какие же основные отличия от полноценного языка запросов?
В запросе RLS всегда присутствует только одна таблица данных и она собственно используется для условий.
Используются только конструкции ИЗ и ГДЕ.
В таких условиях можно указывать в качестве параметров запроса функциональные опции и параметры сеанса.
Не допускается использование виртуальных таблиц.
Возможно использование шаблонов для создания ограничений
Операторы ИТОГИ и В ИЕРАРХИИ не применимы.
Рассмотри как произвести ограничения. к примеру на рис. 1 приведено самое простое ограничение. Оно состоит в том, что пользователь увидит только одного контрагента с определенным наименованием «Сибирская Корона ООО». Можно производить фильтр по определенному полю. Например, мы хотим,чтобы пользователь видел только контрагентов, которые находятся в папке родителе «Сотрудники».
Текст ограничения может быть набран как вручную, а также может быть набран при использовании привычного конструктора запросов. Конструктор запросов в данном случае также будет не полноценен, а буден наделен ограничениями для RLS. В запрос ограничений можно также передавать любые параметры &.
Иногда при использовании RLS у пользователя может появляться ошибка, сообщающая, что недостаточно прав. Это может быть связано со способами функционирования ограничений.
Способ РАЗРЕШЕННЫЕ очень часто используется при формировании динамических списков, в противном случае постоянно бы появлялись ошибки о нарушении прав. Способ ВСЕ используется при получении объектов функциями встроенного языка и запросов. Собственно где устанавливаются данные способы? По умолчанию используется ВСЕ.
Для более удобного использования ограничений в системе 1С предприятие предусмотрено использование шаблонов. То есть если вы используете одно и тоже ограничение или вы знаете,что оно будет отличаться только некоторыми параметрами, то вы создаете свой шаблон. Таким образом можно вообще оформить повторяющийся код ограничений как процедуру.Шаблон имеет имя и текст. Текст содержит программный код ограничений, в нем как и в процедуре можно использовать параметры, при чем параметры выделяются префиксом #.
Рассмотри на примере конфигурации 1С:Бухгалтерия 8.2 использование встроенных шаблонов. Откроем роль БУХГАЛТЕР и перейдем во вкладку Шаблоны ограничений. Здесь используется шаблон ОсновноеУсловиеЧтение следующего содержания:
Где мы видим #Параметр(1)=НастройкиПравДоступаПользователей.ОбъектДоступа. Это и есть тот самый параметр который может меняться в зависимости от передаваемых данных. Далее в любом месте где мы желаем ввести ограничения мы используем шаблон так:
То есть вместо
#Параметр(1)=НастройкиПравДоступаПользователей.ОбъектДоступа
в тексте шаблона окажется
Организация=НастройкиПравДоступаПользователей.ОбъектДоступа.
Или на более простом шаблоне. Наименование шаблона #МоиОграничения следующего содержания:
ГДЕ #Параметр(1) = &ТекущийПользователь
В результате передачи параметров в шаблон #МоиОграничения(“Исполнитель”) мы получаем следующее
ГДЕ Исполнитель= &ТекущийПользователь.
Механизм ограничения доступа к данным на уровне записей очень мощная штука, но ее настройка требует большого опыта, так как в этих «дебрях» можно легко заблудиться. Благодаря ему можно производить любое частичное разграничение данных. С другой стороны добавление различных условий приводит к падению производительности системы, правда незначительной. Так как платформа 1С к запросу пользователя добавляет дополнительные запросы в виде ограничений. Во всем остальном- это просто отличная штука для разработчиков!
