Ограничить доступ на уровне записей 1с ут 11
Эффективная работа ограничений доступа к данным на уровне записей
В статье дается условное разделение ограничений прав доступа на уровне записей на простые и сложные; показано, как эти ограничения влияют на запрос к СУБД; даются рекомендации по написанию эффективных ограничений на уровне записей.
1. Режимы наложения ограничений
Существует 2 режима наложения ограничений на уровне записей. Первый, со словом РАЗРЕШЕННЫЕ в запросе, используется для исключения записей из результата выборки, которые пользователю запрещены (например, вывод списка документов). Второй, без слова РАЗРЕШЕННЫЕ, не включает фильтр для отсеивания запрещенных записей, но определяет поведение механизма работы с базой данных таким образом, чтобы при попытке доступа к запрещенным данным произошло исключение.
2. Различие между простым и сложным ограничением
Ограничения доступа на уровне записей задаются запросом, определяющим, какие записи пользователю доступны. В этом запросе всегда определена главная таблица, которая соответствует защищаемой таблице. Если таблица не указана (запрос может начинаться с "ГДЕ"), то это равносильно включению только одной таблицы в раздел ИЗ.
Ограничения доступа на уровне, задаваемые для объектов метаданных, можно разделить на 2 вида: простые и сложные. К простым относятся ограничения, которые имеют только одну таблицу в разделе ИЗ (и эта таблица – защищаемая). В этом случае ограничение доступа задается лишь с помощью реквизитов этой таблицы, без использования соединений с другими таблицами. Неявные соединения (обращение через точку к реквизиту ссылочного типа), добавляемые в запрос автоматически, переводят ограничение в категорию сложных. К сложному классу ограничений относятся запросы с более чем одной таблицей в разделе ИЗ.
Иногда ограничение, которое выглядит простым, на самом деле исполняется как сложное ограничение. Это случается, когда ограничение задано для регистра остатков или регистра бухгалтерии, поскольку в этом случае механизм работы с базой данных защищает не только таблицу движений этих регистров, но и таблицу остатков. Таким образом, запрос к таблице остатков получает ограничения, заданные для регистра. И чтобы эти ограничения включить в запрос к СУБД (чтобы иметь доступ к реквизитам регистра), механизм работы с базой данных добавляет таблицу движений в условие ограничений доступа.
3. Принципы трансляции ограничения доступа на уровне записей в запрос к СУБД
Рассмотрим самый простой случай, когда запрос выбирает данные из одной таблицы.
В случае, если запрос содержит слово РАЗРЕШЕННЫЕ, простое ограничение будет добавлено в раздел ГДЕ исходного запроса. Запрос к СУБД получит дополнительные инструкции по отбору только тех записей, которые разрешено видеть пользователю, и от СУБД придут только те данные, которые пользователю разрешены.
На большинстве внедрений требуется для разных пользователей установить различные уровни доступа к информации в базе.
Это либо требования конфиденциальности, либо чтобы не испортить данные, за которые пользователь не отвечает и, возможно, даже не разбирается в них (например, бухгалтерские данные для менеджера по продажам).В конфигурациях за возможные права доступа к данным отвечают специальные объекты метаданных – роли. Каждому пользователю информационной базы назначается одна или несколько ролей. Они определяют, возможны ли операции с конкретными объектами метаданных (чтение, запись, проведение и т.д.).
Часто бывает необходимо не просто открыть/запретить доступ к определенному объекту, а ограничить доступ к части данных в нем.
PDF с вводной информацией.
21 страница, которые нужно прочесть сначала.
Видео 01:
Ограничение доступа к данным при помощи ролей
В этом видео рассказывается, как ограничивается доступ к данным при помощи ролей. Уточняется, что роли ограничивают доступ к виду объектов информационной базы (отдельный справочник, но не конкретные элементы справочника).
Видео 02:
Ограничение доступа на уровне записей (RLS)
В этом видео рассказывается о механизме ограничений доступа на уровне записей (RLS), когда можно настроить доступ не ко всему справочнику в целом, а к отдельным его элементам, в зависимости от хранящихся в информационной базе данных. Подобные ограничения прописываются в ролях.
Видео 03:
Реализация ограничения доступа на уровне записей для справочника Контрагенты
В этом видео рассказывается, как в демонстрационной конфигурации «Управляемое приложение» настроить доступ менеджеров только к собственным контрагентам, закрепленным за ними.
Видео 04:
Принцип работы ограничений доступа на уровне записей на низком уровне
В этом видео рассказывается, как платформа трансформирует запросы, передаваемые для выполнения на сервер СУБД, при наличии ограничений доступа на уровне записей.
Видео 05:
Совместное применение нескольких ограничений доступа на уровне записей
Пользователю информационной базы может быть назначено несколько ролей. При этом в каждой роли могут быть свои ограничения доступа на уровне записей. В этом видео рассказывается, как ведет себя система при наложении ограничений.
Видео 06:
Наложение ограничений методом ВСЕ
Видео 07:
Наложение ограничений методом РАЗРЕШЕННЫЕ
Видео 08:
Исправление ошибки, возникающей из-за наложения прав доступа на уровне записей
Этот курс позволит решать ВСЕ задачи по развертыванию и поддержке информационных систем на 1С.
Вот несколько тем из курса:
Этот курс актуален для всех, кто внедряет или поддерживает 1С.Вам в любом случае когда-то придется разворачивать 1С, настраивать резервирование, права доступа, различные режимы запуска, тестировать целостность баз, обеспечивать работу серверов и т.д.
И лучше это сразу делать правильно.
Курс по Администрированию систем на 1С.Описание курса, программа и оформление заказа Курс по RLS.
Описание курса, программа и оформление заказа
Комментарии / обсуждение (161):
Добрый день!
1. Для того, чтобы работали ограничения доступа на уровне записей, в служебных регистрах сведений должны быть записи, описывающие доступ к отдельным объектам.
До включения указанной галочки в регистрах не было нужных записей, значит, первоначально нужно сформировать эти записи по всей базе, затем поддерживать регистр в актуальном состоянии по мере заполнения базы новыми данными.
Для выполнения этого действия в конфигурациях на базе БСП (ERP как раз к таким относится) существует специальное регламентное задание, которое выполнит первоначальное заполнение (разовая операция), затем будет доформировывать записи для новых объектов (это уже будет регулярная операция, которая должна часто выполняться, чтобы для всех новых объектов базы были сформированы записи в регистрах, отвечающих за ограничения доступа).
Добрый день!
Подскажите, пожалуйста, как можно с помощью шаблонов ограничения доступа ограничить доступ к данным некоторых отчетов. Например, есть профиль Менеджер по продажам, состоящий из нескольких ролей, у которого настроено ограничение доступа к группе партнеров. Исключения настроены в группе доступа. В отчете, например, Воронка продаж, нужно установить ограничение на разрешенную группу партнеров. А в другом отчете, например, Анализ встреч, по текущему пользователю, но также для пользователя с данным профилем.
Добрый день!
В типовых конфигурациях на базе БСП (например, УТ 11) в ролях используются стандартные шаблоны ограничений доступа из БСП.
Они универсальные, поэтому для решения большинства задач их не требуется менять. Предполагается, что настройку нужно выполнять в пользовательском режиме, создавая профили и группы доступа.
Если Вы ограничиваете доступ к справочнику Партнеры, оставляете доступными определенные группы, то в форме списка справочника, в списке документов, в отчетах будут видны данные только по этим разрешенным партнерам. Других (запрещенных) партнеров и данных по ним увидеть нельзя.
Если нужно в отчетах видеть не всех разрешенных партнеров, а только часть из них, то можно настроить отборы в отчете и сохранить такой вариант отчета. В отборе указать конкретных разрешенных партнеров, тогда отчет будет формироваться только по ним. Сохраненный вариант отчета можно разместить в Избранном, тогда пользователь сможет быстро формировать его, не выполняя предварительную настройку.
Добрый день, в учебной версии при использовании rls столкнулся с проблемой при записи или проведении документа (у пользователя недостаточно прав на использование операций над базой данных), причём в полной версии 1с данной проблемы не встречал.
В журнале регистраций ссылается на отказ доступа (действие-чтение)
Ограничение делал простое:
Как можно решить данную проблему?
Заранее огромное спасибо!
P.S.: не судите строго я недавно начал изучать 1с.
У учебной версии нет ограничений по RLS. Проверяйте, скорее всего у пользователя действительно недостаточно прав на использование операций над базой данных.
Добрый день!
Хотел уточнить, при установки ограничения по текущему пользователю на документ, сам пользователь проводить свои документы может или он их сможет только просмотреть и ему всё же будет отказано в доступе, как в моем случае?
Это зависит от-того на какое право наложено ограничение, чтение или запись.
Ваш ответ исчерпывает сам себя. Наложили ограничение на чтение, получили отказ в доступе при попытке чтения данных.
Добрый день!
Спасибо за Ваши ответы!
Я понял свою ошибку.
Пожалуйста!
Интересного обучения!
Приветствую Василий, есть задача в ут 10.3 ограничить доступ пользователей на доп свойства справочника контрагентов сейчас RLS используется для доступа к контрагентам не могу сообразить на какой объект лучше написать правило ограничения на регистрсведений.ЗначенияСвойствОбъектов или на планВидовХарактеристик.СвойстваОбъектов?
В Вашем случае может быть два варианта решения:
1. Вы не используете сложные типовые шаблоны, самостоятельно прописываете собственное ограничение при помощи простого запроса.
2. Вы анализируете существующие в типовой конфигурации шаблоны, подбираете подходящий, используете его. Можно поискать в конфигурации похожие примеры в ролях, взять их в качестве образца.
Добрый день. Имеется такая задача, есть ветка номенклатуры, которая привязана к магазину, и всю номенклатуру в этой группе и подгруппах необходимо разрешить изменять только 1-2м пользователям.
У соответствующей роли можно убрать галку прав на чтение, но как сделать, что бы эти правила распространялись только на группу магазин, а не блокировали абсолютно все.
Спасибо за помощь и видео, очень интересно!
Добрый день!
Предлагаю сделать регистр сведений РазрешеннаяНоменклатура, куда записывать все номенклатуры, которые можно изменять указанным пользователям. Например, в регламентном задании выбираем номенклатуры из определенных групп, записываем в регистр. Получается что-то похожее на состав сегментов номенклатуры из УТ 11.
Затем в роли для справочника Номенклатура для права Изменение прописать ограничение доступа, например, вот так:
(ВЫБРАТЬ
РазрешеннаяНоменклатура.Номенклатура КАК Номенклатура
ИЗ
РегистрСведений.РазрешеннаяНоменклатура КАК РазрешеннаяНоменклатура)
Т.е. пользователю с этой ролью можно изменять только те элементы справочника Номенклатура, которые содержатся в указанном регистре.
Спасибо за совет, сделал как вы сказали, все работает! Единственное, не смог самостоятельно доработать. Не поможете довести до ума?)
Единственное, не понимаю, как добить условие в Роли ограничение доступа Изменение. Запрет редактирование всего, что есть в РегистреСведений, по группам. Разматывать всю иерархию не нужно, достаточно только 1 погружение, мне не влом добавить все подгруппы. Просто как-то нужно правильно свести код:
Выборка = Справочники.Номенклатура.Выбрать(ЗапрещеннаяГруппаНоменклатуры);
Пока Выборка.Следующий() Цикл
Наименование = Выборка.Наименование;
КонецЦикла;
Номенклатура ГДЕ НЕ Номенклатура.Ссылка В
(ВЫБРАТЬ
ЗапрещеннаяНоменклатура.Номенклатура КАК Номенклатура
ИЗ
РегистрСведений.ЗапрещеннаяНоменклатура КАК ЗапрещеннаяНоменклатура)
Отлично, что заработало!
Поскольку в регистре хранятся группы номенклатуры, а не элементы, то будем работать с реквизитом Родитель.
Ограничение доступа может выглядеть, например, вот так:
(ВЫБРАТЬ
ЗапрещеннаяНоменклатура.Номенклатура КАК Номенклатура
ИЗ
РегистрСведений.ЗапрещеннаяНоменклатура КАК ЗапрещеннаяНоменклатура)
Добрый человек, все работает как нужно и спасибо еще раз за помощь! Вы крутые!
Номенклатура ГДЕ НЕ Номенклатура.Родитель В(ВЫБРАТЬ
ЗапрещеннаяНоменклатура.Номенклатура КАК Номенклатура
ИЗ
РегистрСведений.ЗапрещеннаяНоменклатура КАК ЗапрещеннаяНоменклатура)
Добрый день! Наблюдаю интересную картину. Есть 3 типа заказов. По ним есть счета. В один счет могут входить разные типы заказов. Заказы перечислены в табличной части. На заказ с Типом1 у пользователя права чтение/запись, на Тип2 только чтение, на Тип3 ничего. Так вот если в одном счете есть Тип1 и Тип2, то счет можно записать (да как. ). Если только Тип2, то записать нельзя. Если Тип1 и Тип3, то записать тоже нельзя. Я не понимаю, почему дает записать счет с типами заказов Тип1 и Тип2. Что это за метаморфозы?? Как я понимаю, счет это у нас целостная сущность. Внутри нее есть подсущности с разными правами доступа. Возможно, есть какие-то приоритеты, по которым RLS выбирает, какой уровень доступа наложить на счет?
Добрый день! Вы правы , именно обновление вспомогательных данных не выполнил. Спасибо.
Может ли RLS помочь в ситуации , когда нужно одной и той же роли разрешить или запретить Запись и Проведение документа по Отбору ?
Добрый день!
Да, можно ограничить запись документа в базу при помощи RLS. Для этого нужно будет настроить ограничение доступа в роли. Если условие выполняется, документ может быть записан в базу. Если условие не выполняется, документ нельзя записать.
При помощи RLS нельзя ограничить проведение, можно только Чтение, Добавление, Изменение, Удаление.
Но помещать такого рода алгоритм, наверно не стоит , например:
В рлс , перед изменением Документа , Рлс контролирует остаток после записи и если Отрицательный остаток , то не даст пользователю изменить документ . Да я конечно понимаю , что для этого есть кучу и других мест
Нет, такой алгоритм не стоит использовать в выражениях ограничений доступа из соображений производительности.
Эти действия лучше выполнять при проведении документа.
Механизм ограничения доступа на уровне записей (RLS) позволяет ограничить доступ к части данных в определенной таблице. Например, видеть не всех контрагентов, а только тех, за которых отвечает конкретный менеджер.
Подскажите, а чтобы обратиться к реквизиту текущего пользователя в рлс напирмер физлицо то для этого отдельно нужно создавать параметр сеанса? ГДЕ ФизЛицо = &ТекущийПользователь (нужно физ лицо которое задано у пользователя
Курс не требует специальных знаний для его прохождения, достаточно базовых знаний в части программирования и запросов.
Что входит в курс
Детальное содержание курса
Задача 1. Реализация запрета доступа к данным формы
Темы занятия:
- Варианты решения задачи
- Подключение нового документа к интерфейсу конфигурации
- Работа с формой документа
- Подключение механизма БСП для блокирования реквизитов
- Настройка вариантов вывода плановых данных на форме документа
- Блокирование кнопок записи документа
Задача 2. Создание дополнительных прав на функционал (выделение привилегированных пользователей)
Темы занятия:
- Проблемы с правами доступа – поиск ошибок с помощью журнала регистрации
- Типовая система прав доступа
- Настройка доступа – профили и группы пользователей
- Проверка доступа программным кодом
Задача 3. Собственные алгоритмы для ограничения доступа на уровне записей
Темы занятия:
Задача 4. Добавление нового вида доступа
Темы занятия:
- Добавление описания нового вида доступа в общем модуле
- Организация значений доступа при помощи определяемого типа
- Редактирование ограничений доступа в ролях
- Обновление вспомогательных данных при помощи параметра запуска
- ЗапуститьОбновлениеИнформационнойБазы
- Проверка добавленного вида доступа в пользовательском режиме
- Доработка отчета «Права доступа» для отображения нового вида доступа
Задача 5. Стандартные шаблоны для ограничения прав доступа
Темы занятия:
Данный курс ранее входил в состав курса «Доработка и Адаптация типовых конфигураций УТ, КА и 1С:ERP»
В декабре 2018 года мы выделили из курса «Доработка и адаптация типовых конфигураций УТ 11, КА 2.4 и 1С:ERP 2.4» блок по настройке прав доступа и RLS и за счет этого уменьшили его стоимость.
Поэтому, если Вы уже приобретали курс «Доработка и адаптация типовых конфигураций УТ 11, КА 2.4 и 1С:ERP 2.4» до декабря 2018, то все материалы этого курса Вы уже получили.
автор курса
Евгений Гилев
- Под авторством и при участии Евгения выпущено 17 курсов.
- Обучено 11 000+ слушателей
- 10 сертификатов 1С:Специалист по платформе и решениям
- 12 сертификатов преподавателя 1С.
автор курса
Василий Ханевич
- Автор 4 курсов по платформе, программированию и администрированию 1С
- Обучено более 6000 слушателей
- 6 сертификатов 1С:Специалист + 1С:Эксперт
- Продолжает вести реальные проекты в мясопереработке, производстве электроники, мебели, металлообработке, пищевке, оптовых и розничных торговых сетях
Время на изучение
Вместе с практикой Вы уложитесь в 2-3 дня.
В то же время, Вы сможете задавать все возникающие вопросы и получать ответы в Мастер-группе в течение месяца.
Этого будет более чем достаточно на все тесты и эксперименты.
Примеры видео из курса
Типовая система прав пользователей
В этом уроке рассмотрим, как реализована система прав доступа в типовых конфигурациях УТ 11, КА 2, ERP 2.
Поясним, что хранится справочниках системы и как взаимосвязаны:
- Профили групп доступа
- Группы доступа
- Пользователи.
Настройка RLS (ограничений доступа на уровне записей) в типовых на базе БСП
В этом видео происходит настройка ограничений по пользователям на базе типовых шаблонов БСП. Это, например, ограничения доступа к документам по авторам или кураторам.
Формат курса, график и поддержка
Это НЕ очный курс, он проводится в дистанционном формате.
После оплаты курса Вы получаете доступ к закрытым разделам и скачиваете видео-уроки с сайта.
Возникающие вопросы Вы задаете тренерам на страницах обсуждений (Мастер-группы), там же Вы можете увидеть ответы на свои вопросы и вопросы других участников.
Поддержка по данному курсу – 31 день, ее можно активировать в любое удобное время.
По такой схеме мы обучаем несколько тысяч человек в год. Это работает : )
Защита и доступ к материалам
Все материалы скачиваются с сайта и доступны Вам без ограничения сроков.
Далее можете изучать их в своем темпе – график обучения свободный.
Стоимость курса
Регулярная стоимость курса:
9 700 рублей
Дополнительная информация
Мы ведем обучение с 2008 года, уверены в качестве наших курсов и даем на этот курс нашу стандартную 60-дневную гарантию.
Это значит, что если Вы начали заниматься по нашему курсу, но вдруг передумали (или, скажем, не имеете возможности), то у Вас есть 60-дневный срок для принятия решения – и если Вы производите возврат, мы возвращаем 100% оплаты.
Текущий уровень возвратов наших курсов: менее 1 процента…
Наши курсы можно оплатить по частям или в рассрочку, в том числе без процентов. При этом доступ к материалам Вы получаете сразу.
Это возможно при оплате от физических лиц на сумму от 3 000 руб. до 150 000 руб.
Все, что Вам нужно сделать – это выбрать способ оплаты “Оплата через ЮKassa”. Далее на сайте платежной системы выбираете “Заплатить по частям”, указываете срок и размер выплат, заполняете небольшую анкету – и через пару минут получаете решение.
Мы принимаем все основные формы платежей.
От физических лиц – оплаты с банковских карт, электронными деньгами (WebMoney, ЮMoney), через интернет-банкинг, оплаты через салоны связи и так далее.
От организаций и ИП мы принимаем безналичную оплату, естественно, предоставляются все стандартные документы. Вы вводите заказ – и сразу можете распечатать счет на оплату.
Наши курсы предназначены для индивидуального обучения. Групповое обучение по одному комплекту является незаконным распространением.
Сегодня рассмотрим вопрос по типовой конфигурации УТ 11. Нашему слушателю в процессе изучения курса Профессиональная разработка отчетов в 1С 8.3 на Системе Компоновки Данных (СКД) понадобилось ограничить доступность некоторых дополнительных отчетов.
Вопрос
Работает ли в УТ 11.3.4.197 ограничение на уровне записи для дополнительных отчётов и обработок? Если да, то какие настройки необходимо поставить?
Интересует вариант разрешить все доп. отчёты, кроме указанных в профиле/группе доступа. Не получается, чтобы сработал запрет. В чём он должен выражаться?
Ответ
Да, в роли Чтение дополнительных отчетов и обработок реализовано ограничение доступа на уровне записей.
Создаем новый профиль, указываем роль Чтение дополнительных отчетов и обработок , назначаем ограничение доступа Дополнительные отчеты и обработки :
В группе доступа указываем разрешенные значения:
После этого в панели отчетов пользователя этой группы будут отображаться варианты из отчета «Внешний отчет доп »:
Остальные варианты из дополнительных отчетов не отображаются в панели.
Ну что, подведем итоги? В типовых конфигурациях при разработке отчетов нужно уметь работать не только со схемой компоновки данных и подсистемами БСП, которые обслуживают работу отчетов, но и уметь настраивать ограничения доступа к отчету, опять же, через соответствующую подсистему БСП. И тут у нас три варианта:
Пишите в комментариях, что думаете о ситуации. Если работаете с типовыми конфигурациями, было бы здорово, если бы описали свой опыт: как вырабатывали навыки, обучались ли на курсах/сами, с какими трудностями столкнулись? А если кто уже давно в типовых, может, и совет дадите менее опытным? :)
Читайте также: