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