Как запретить изменение реквизитов Наименование и Код для одного пользователя при сохранении права на добавление новой номенклатуры?

В процессе администрирования 1С часто возникает необходимость ограничить редактирование ключевых данных для определенных пользователей. Сегодня мы разберем, как реализовать запрет на изменение Наименование и Код в справочнике Номенклатура для конкретного пользователя, при этом оставив ему возможность создавать новые элементы.

Вариант 1: Управление доступностью элементов на форме

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

Для реализации этого метода мы будем использовать событие ПриОткрытии в модуле формы элемента справочника Номенклатура. Суть метода заключается в проверке того, является ли объект новым, и сравнении текущего пользователя с тем, для кого устанавливаются ограничения.

Разберем реализацию по шагам:

1. Откройте конфигуратор и перейдите в ветку Справочники — Номенклатура — Формы — ФормаЭлемента.
2. В модуле формы найдите процедуру ПриОткрытии (если её нет, создайте её).
3. Добавьте программный код, который проверяет текущего пользователя и состояние объекта.

Если НЕ Объект.Ссылка.Пустая() Тогда
    Если ПараметрыСеанса.ТекущийПользователь = Справочники.Пользователи.НайтиПоНаименованию("ИмяОграниченногоПользователя") Тогда
        Элементы.Наименование.Доступность = Ложь;
        Элементы.Код.Доступность = Ложь;
    КонецЕсли;
КонецЕсли;

Важно понимать: использование свойства Объект.Ссылка.Пустая() или метода ЭтоНовый() позволяет определить, записывается ли уже существующий элемент или создается новый. В данном примере мы блокируем доступ только для уже существующих элементов, позволяя пользователю заполнять поля для новых карточек.

Вариант 2: Использование подписки на событие (Профессиональный подход)

Хотя управление элементами на форме удобно, опытные разработчики знают, что опытный пользователь может обойти интерфейсные ограничения через групповые обработки или консоли кода. Чтобы сделать запрет по-настоящему надежным, мы рекомендуем использовать подписку на событие ПередЗаписью.

Этот метод работает на уровне сервера 1С, поэтому никакие обходные пути не позволят записать измененные данные, если они запрещены политикой безопасности.

Реализуем это решение пошагово:

1. В дереве метаданных найдите ветку Общие — Подписки на события.
2. Создайте новую подписку, укажите источник (например, СправочникОбъект.Номенклатура) и событие ПередЗаписью.
3. Создайте общий модуль (если его еще нет), в котором будет размещена процедура-обработчик.

Процедура ЗапретИзмененияНаименованияПередЗаписью(Источник, Отказ) Экспорт
    Если НЕ Источник.ЭтоНовый() Тогда
        Если ПараметрыСеанса.ТекущийПользователь = Справочники.Пользователи.НайтиПоНаименованию("ИмяОграниченногоПользователя") Тогда
            // Получаем объект из базы для сравнения
            СтарыйОбъект = Источник.Ссылка.ПолучитьОбъект();
            Если Источник.Наименование <> СтарыйОбъект.Наименование ИЛИ Источник.Код <> СтарыйОбъект.Код Тогда
                ВызватьИсключение "У вас нет прав на изменение наименования или кода номенклатуры!";
            КонецЕсли;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Такой подход гарантирует, что система сама прервет процесс записи, если зафиксирует попытку изменения защищенных реквизитов. Важно: в реальных задачах мы рекомендуем проверять не конкретное имя пользователя, а принадлежность к группе доступа, чтобы при смене персонала не приходилось менять код в конфигураторе.

Рекомендации по реализации

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

• Используйте Расширения: Не вносите изменения напрямую в основную конфигурацию. Это позволит обновлять типовую программу без потери ваших доработок. Создайте расширение, добавьте в него нужную форму или подписку на событие.
• Группы доступа: Используйте стандартные механизмы 1С для объединения пользователей в группы. Вместо проверки одного пользователя через НайтиПоНаименованию, используйте проверку ГруппыПользователей.ПринадлежитГруппе. Это делает систему гибкой и масштабируемой.
• Безопасность: Подписка на событие — это «последний рубеж» защиты. В сочетании с интерфейсными ограничениями вы получаете надежное решение, которое и удобно для пользователя (поля просто недоступны для редактирования), и безопасно для базы данных.

Мы проанализировали ситуацию и выяснили, что комбинирование визуальных ограничений (для удобства пользователя) и проверки ПередЗаписью (для надежности данных) является наиболее эффективным методом решения задачи. Успехов в автоматизации!