В процессе сопровождения крупных корпоративных систем на базе 1С:ERP Управление предприятием администраторы и разработчики часто сталкиваются с жесткими требованиями бизнеса. Типичная ситуация: у пользователя есть обширный набор прав (например, около шести различных ролей для выполнения смежных задач), в которых разрешено редактирование справочника Номенклатура. Бизнес требует оперативно запретить этому конкретному сотруднику изменять карточки товаров, но при этом настоятельно просит «не трогать» сами роли, не заниматься программированием и не привлекать внешних разработчиков.
В этой статье мы подробно разберем, как устроена система прав в платформе «1С:Предприятие 8.3», почему стандартные попытки решить задачу «в лоб» не работают и как решить эту проблему исключительно типовыми средствами конфигурации.
Для начала проанализируем техническую архитектуру платформы «1С:Предприятие». Очень часто от руководителей подразделений или заказчиков можно услышать фразу: «Просто создайте роль "Запрет редактирования номенклатуры" и добавьте её этому пользователю». С точки зрения логики платформы 1С это невозможно.
Права доступа в системе 1С работают по принципу кумулятивности (сложения). Это логическое «ИЛИ»:
Номенклатура), то это действие будет разрешено пользователю в целом.Таким образом, простое добавление новой роли не решит задачу, если у пользователя остаются старые роли с правом на изменение. Нам необходимо искать другие пути решения.
Рассмотрим подробнее три основных типовых метода решения этой задачи без изменения конфигурации и программирования.
---
Это самый правильный, надежный и полностью типовой способ решения задачи. В 1С:ERP встроен мощный механизм разграничения прав доступа на уровне записей — RLS (Record Level Security). Он позволяет накладывать ограничения на конкретные элементы справочников в зависимости от их реквизитов.
Разберем по шагам, как настроить этот механизм:
Шаг 1. Включение функциональных опций
Перейдем в раздел НСИ и администрирование – Настройки пользователей и прав – Группы доступа. Здесь нам необходимо установить два важных флажка:
Ограничивать доступ на уровне записей — включает сам механизм RLS в системе.Группы доступа номенклатуры — активирует разрез ограничения прав именно для справочника товаров и услуг.Шаг 2. Создание групп доступа номенклатуры
После включения опций в системе активируется справочник Группы доступа номенклатуры (его можно найти через функции для технического специалиста или в разделе настроек классификаторов номенклатуры). Нам необходимо создать как минимум одну группу, например: «Основная номенклатура» или «Запрещенные к изменению».
Шаг 3. Классификация элементов справочника
В карточках номенклатуры (в группе реквизитов, отвечающих за администрирование) появится новое поле — Группа доступа. Для всех элементов, которые мы хотим защитить от редактирования, необходимо указать созданную группу доступа. Сделать это можно массово с помощью типовой обработки Групповое изменение реквизитов.
Шаг 4. Настройка ограничений в Профилях групп доступа
Теперь вернемся к нашему пользователю. У него есть несколько профилей групп доступа (те самые 6 профилей из описания проблемы). Нам необходимо открыть каждый из этих профилей и перейти на вкладку Ограничения доступа:
Важный нюанс: Механизм RLS для групп доступа номенклатуры в 1С:ERP спроектирован очень гибко. Он ограничивает только запись (изменение и создание) объектов, но оставляет доступным их чтение. Это означает, что пользователь по-прежнему сможет видеть всю номенклатуру в списках, выбирать ее в документы продаж или закупок, но при попытке перезаписать карточку товара система выдаст сообщение об ошибке доступа. Однако помните: чтобы ограничение сработало, его нужно настроить во всех шести профилях пользователя, иначе сработает правило кумулятивности прав.
---
Если настройка RLS кажется вам слишком трудоемкой или вы опасаетесь снижения производительности базы данных (что иногда происходит при неоптимальной настройке RLS на больших объемах данных), проанализируем альтернативный встроенный инструмент БСП — Запрет редактирования ключевых реквизитов.
Этот механизм работает следующим образом:
Редактирование реквизитов объектов (или аналогичной в зависимости от версии БСП).Если у нашего «проблемного» пользователя нет этой специальной роли в его профилях, он физически не сможет отредактировать ключевые поля уже созданной номенклатуры. При этом он сможет создавать новые карточки, но изменять старые — нет.
Минус метода: это ограничение является общим для всех рядовых пользователей системы, у которых нет административных прав или специализированной роли разблокировки реквизитов. Настроить его индивидуально для одного человека (оставив лазейку для других без изменения профилей) данным способом не получится. Для индивидуального управления полями карточек подойдет расширение для настройки доступа и видимости реквизитов справочников по пользователям.
---
Выясним причину, почему компания так боится несанкционированного изменения номенклатуры. Чаще всего это связано со страхом перед хаосом в учете (кто-то изменил наименование, единицу измерения или ставку НДС, из-за чего «поплыли» отчеты и закрытие месяца). Если технически ограничить права сложно или долго, отличной альтернативой становится жесткий административный контроль.
Мы можем настроить Версионирование объектов (историю изменений):
Хранить историю изменений.Номенклатура и установим для него режим версионирования (например, «Версионировать при записи»).Теперь при каждом изменении карточки товара система будет сохранять предыдущую версию объекта, фиксируя:
Наличие такого контроля дисциплинирует пользователей лучше любых программных запретов. Администратор системы может раз в неделю выгружать отчет по измененным карточкам номенклатуры и передавать его руководству для принятия дисциплинарных мер к нарушителям регламента.
---
Если на совещании с клиентом вам категорически запретили менять типовую конфигурацию, но при этом RLS включать отказываются из-за нагрузки на сервер, а административный контроль не устраивает руководство, остается единственный технический путь — использование расширения конфигурации. Этот метод считается «честным», так как основная конфигурация остается на поддержке и не снимается с нее.
Реализовать это можно двумя путями:
Путь А. Создание переопределяющей роли в расширении
Мы можем создать расширение, добавить в него роль ПолныеПрава (или те роли, которые назначены пользователю), и программно переопределить поведение интерфейса для конкретного пользователя. Но более изящным решением будет создание подписки на событие.
Путь Б. Подписка на событие ПередЗаписью в расширении
Мы создаем расширение конфигурации и добавляем в него подписку на событие ПередЗаписью для справочника Номенклатура. Код обработчика будет выглядеть следующим образом:
Процедура ПередЗаписьюНоменклатурыПередЗаписью(Источник, Отказ, Замещение) Экспорт
// Проверяем, является ли пользователь тем самым сотрудником, которому нельзя редактировать
ТекущийПользовательИнформационнойБазы = ПользователиИнформационнойБазы.ТекущийПользователь();
Если ТекущийПользовательИнформационнойБазы.Имя = "ИмяПроблемногоПользователя" Тогда
// Разрешаем записывать только новые элементы (при необходимости)
Если НЕ Источник.ЭтоНовый() Тогда
ВызватьИсключение "У вас нет прав на редактирование существующей номенклатуры. Обратитесь к администратору!";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Этот код надежно заблокирует любую попытку записи существующего элемента номенклатуры под конкретной учетной записью, независимо от того, сколько разрешающих ролей ей назначено. При этом типовая конфигурация останется абсолютно нетронутой, а само расширение можно будет легко отключить в любой момент. Для автоматизации такого контроля можно использовать готовое расширение для блокировки изменений документов и справочников.
Для эффективного решения задачи ограничения прав без изменения ролей рекомендуем придерживаться следующего алгоритма:
ПередЗаписью. Это быстро, надежно и не мешает последующим обновлениям системы 1С:ERP.