Запрет создания номенклатуры 1с

Обновлено: 07.07.2024

Тема актуальна уже много лет. Интерес к ней у слушателей не ослабевает.

Вопрос

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

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

Спасибо за помощь и видео, очень интересно!

Ответ

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

Например, в регламентном задании выбираем номенклатуры из определенных групп, записываем в регистр. Получается что-то похожее на состав сегментов номенклатуры из УТ 11.

Затем в роли для справочника Номенклатура для права Изменение прописать ограничение доступа, например, вот так:

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

Комментарий слушателя

Спасибо за совет, сделал, как вы сказали, все работает! Единственное, не смог самостоятельно доработать. Я в регистр сведений ЗапрещеннаяНоменклатура добавил измерение ЗапрещеннаяНоменклатура с типом данных СправочникСсылка.Номенклатура, установил свойство ВыборГрупп, создал форму регистра и выставил тип ВыборГрупп.

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

Комментарий тренера

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

Комментарий слушателя

Добрый человек, все работает как нужно и спасибо еще раз за помощь! Вы крутые!

Не могу понять, куда добавить наше условие: “при перемещении смотреть ограничение на запрещенные группы”.

Комментарий тренера

Поскольку перемещение номенклатуры в другую папку – это запись в базу, для справочника Номенклатура нужно создать ограничение доступа для права Изменение:

Для реализации данной задачи пришлось редактировать конфигурацию. Для примера выкладываю демо базу ут 10.3.24.1 с измененной конфигурацией. Все изменения можно получить путем сравнения с типовой конфигурацией. Ниже идет описание использования доступа к номенклатуры для пользователя:

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

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

Настраивать ограничения доступа может только администратор (пользователь с полными правами).
Настройки доступа не распространяются на пользователей с полными правами. Пользователь, имеющий полные права, имеет доступ ко всей номенклатуре, независимо от выполненных в базе настроек.
Настроенные ограничения действуют, только если в базе включен флаг «Ограничивать права доступа на уровне записей».
Настроенные ограничения вступают в силу при следующем входе пользователя в базу.

Чтобы сделанные нами настройки работали, включим в базе флаг «Ограничивать права доступа на уровне записей». Для этого откроем настройки параметров учета.

Меню: Сервис – Настройка учета – Настройка параметров учета

В форме настроек на закладке «Общее» поставим соответствующий флаг:

Группы доступа к номенклатуре

Группы доступа к номенклатуре создаются в соответствующем справочнике.

Меню: Сервис – Пользователи – Группы доступа к номенклатуре

При создании группы указывается только ее наименование. Создадим группу доступа:

Указание группы доступа производится в форме номенклатуры на закладке «Прочее».

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

Укажем для номенклатуры «Вентилятор BINATONE ALPINE 160вт, напольный » группу «БытоваяТехника»

Группы пользователей

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

Меню: Сервис – Пользователи – Группы пользователей

Добавим группу, укажем ее наименование – «ТорговыйБытовойТехники». В таблице «Виды объектов доступа» поставим флаг «Номенклатура».

Если флаг «Номенклатура» не установлен, то пользователи данной группы будут иметь доступ ко всем номенклатурам, независимо от настроек прав доступа. Если флаг установлен, то по умолчанию пользователи группы вообще не имеют доступа к номенклатуре, все доступные группы номенклатур указываются отдельно.

Далее укажем состав группы – выберем пользователя «Торговый».

Пример заполненной группы пользователей:

Настройка ограничений прав доступа

Теперь нам остался последний шаг – указать, что группа пользователей «ТорговыйБытовойТехники» имеет доступ к группе номенклатур «БытоваяТехника».

Перейти к форме настройки прав доступа можно из формы группы пользователя по кнопке «Перейти» и заполнить регистры сведений «Назначение видов объектов доступа» и «Настройки прав доступа пользователей»:

Регистр сведений «Назначение видов объектов доступа»

Регистр сведений «Настройки прав доступа пользователей»

Флаг «запись» не работает.

Результат настройки ограничения доступа к номенклатуре

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

Настраиваемая проверка наличия дублей перед записью элементов справочников. Возможность поиска по нескольким полям.

Артикул 409 Цена 3000 руб. Последнее обновление 2021-05-03 Изменение конфигурации Не требуется

Бухгалтерия предприятия 3.0
Управление торговлей 11.4
Управление торговлей 3 (KZ) *
Комплексная автоматизация 2.4 (KZ) *
Управление торговлей 3 (BY) **
Комплексная автоматизация 2.4 (BY) **
Управление предприятием ERP 2.4
Комплексная автоматизация 2.4
Розница 2.3
Управление нашей фирмой 1.6
Бухгалтерия для Казахстана 3.0

Разработка позволяет произвольным образом настроить проверку уникальности перед записью новых элементов в ЛЮБОМ справочнике информационной базы. При этом проверка может производиться не только по реквизитам элементов, но и по значениям контактной информации.

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

Откроем форму настроек.

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

Если реквизитов проверки несколько, перечисляем их через запятую.

Если дублями необходимо считать элементы, у которых совпадают значения всех реквизитов проверки, необходимо установить флаг Совместно . В противном случае дублями будут считаться элементы, у которых совпадает значение хотя бы одного реквизита проверки.

Теперь при записи нового (или изменении текущего) партнера программа проверяет его телефон, и если он не уникальный, то запись заканчивается ошибкой.

Сохранить характеристику с неуникальной комбинацией наименования и владельца тоже не получится.

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

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

Для корректной работы расширения необходимо отключить Безопасный режим .

Вас может заинтересовать

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

В данном видеоуроке рассмотрен процесс создания нового профиля группы доступа в 1С:Предприятие 8 (на примере Бухгалтерии предприятия 3.0).

В данном видеоуроке показано, как на практике применить механизм ограничения доступа на уровне записей RLS (record level security) в 1С:Предприятие 8 (на примере Бухгалтерии предприятия 3.0 и Управления торговлей 11).

На большинстве внедрений требуется для разных пользователей установить различные уровни доступа к информации в базе.

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

В конфигурациях за возможные права доступа к данным отвечают специальные объекты метаданных – роли. Каждому пользователю информационной базы назначается одна или несколько ролей. Они определяют, возможны ли операции с конкретными объектами метаданных (чтение, запись, проведение и т.д.).

Часто бывает необходимо не просто открыть/запретить доступ к определенному объекту, а ограничить доступ к части данных в нем.

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) позволяет ограничить доступ к части данных в определенной таблице. Например, видеть не всех контрагентов, а только тех, за которых отвечает конкретный менеджер.

Подскажите, а чтобы обратиться к реквизиту текущего пользователя в рлс напирмер физлицо то для этого отдельно нужно создавать параметр сеанса? ГДЕ ФизЛицо = &ТекущийПользователь (нужно физ лицо которое задано у пользователя

Читайте также: