Как предоставить пользователю доступ только к дополнительным реквизитам в ЗУП 3.1 без прав на изменение объекта?

← На главную

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

Однако при попытке реализации администраторы сталкиваются с проблемой: платформа не дает записать изменения дополнительных реквизитов, если у пользователя нет прав на изменение самого справочника «Сотрудники». В этой статье мы подробно разберем, почему так происходит, и рассмотрим рабочие способы решения этой задачи, включая использование расширений и привилегированного режима.

Суть проблемы: архитектура дополнительных реквизитов

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

Как справедливо заметили участники обсуждения, с точки зрения платформы 1С:Предприятие, дополнительные реквизиты (хранящиеся в плане видов характеристик ДополнительныеРеквизитыИСведения) фактически являются частью самого объекта. Значения этих реквизитов записываются в специальную табличную часть справочника или документа.

Следовательно, работает следующее правило:

Доступ к изменению дополнительных реквизитов равносилен доступу на изменение элемента справочника.
Если у пользователя роль «Только просмотр», он не сможет сохранить изменения в табличной части доп. реквизитов, так как это вызывает метод записи всего объекта.

Вариант 1: Использование Дополнительных сведений (Рекомендуемый)

Самый простой и «чистый» способ решения задачи без программирования — понять разницу между двумя похожими механизмами.

Дополнительные реквизиты — хранятся в самом объекте (требуют прав на объект).
Дополнительные сведения — хранятся в независимом регистре сведений.

Давайте проанализируем этот вариант. Если перенести необходимые данные из разряда «реквизитов» в разряд «сведений», мы развязываем руки системе прав доступа. Регистр сведений — это отдельная сущность базы данных.

Как это настроить:

Мы можем создать роль (или профиль групп доступа), которая:

Имеет право «Чтение» для справочника Сотрудники.
Имеет право «Изменение» для регистра сведений, где хранятся значения дополнительных сведений.

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

Вариант 2: Программная реализация через Расширение и Привилегированный режим

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

Рассмотрим пошагово, как реализовать безопасное редактирование через Расширение конфигурации.

Шаг 1. Подготовка формы

Пользователю назначаются права только на просмотр справочника. Далее, в расширении мы заимствуем форму элемента справочника Сотрудники. В процедуре ПриСозданииНаСервере нам нужно принудительно включить доступность нужных элементов формы, даже если сама форма открыта в режиме «ТолькоПросмотр».

Однако, стандартная кнопка «Записать» работать не будет, так как у пользователя нет прав на уровне СУБД (RLS или Роли). Нам нужно скрыть стандартные кнопки и добавить свою команду.

Шаг 2. Создание команды сохранения

Добавим на форму кнопку «Сохранить доп. данные». Эта кнопка будет вызывать серверную процедуру.

Шаг 3. Использование привилегированного режима

Это ключевой момент решения. Привилегированный режим позволяет выполнять операции с данными, игнорируя проверку прав доступа текущего пользователя. Это безопасно, так как мы программно контролируем, что именно меняется (только доп. реквизиты), не давая изменить оклад или ФИО.

Рассмотрим пример кода, который должен содержаться в модуле формы (или вызываемом общем модуле) расширения:


&НаСервере
Процедура СохранитьДопРеквизитыНаСервере(СсылкаНаОбъект, ЗначенияРеквизитов)
    
    // Включаем режим, где права не проверяются
    УстановитьПривилегированныйРежим(Истина);
    
    // Получаем объект для записи. 
    // Даже если у пользователя нет прав, в прив. режиме это сработает.
    ОбъектСотрудник = СсылкаНаОбъект.ПолучитьОбъект();
    
    // Заполняем табличную часть "ДополнительныеРеквизиты"
    // Здесь должен быть код поиска нужной строки в ТЧ и изменения её значения
    // на основе переданных данных с формы
    
    Попытка
        // Записываем объект.
        // Важно: При записи могут сработать проверки заполнения других полей.
        // Если объект старый и в нем есть незаполненные обязательные поля,
        // запись может не пройти.
        ОбъектСотрудник.Записать();
    Исключение
        // Обработка ошибок блокировок или проверок
        Сообщить("Не удалось записать данные: " + ОписаниеОшибки());
    КонецПопытки;
    
    УстановитьПривилегированныйРежим(Ложь);

КонецПроцедуры

Важные нюансы реализации:

Передавайте с клиента на сервер только измененные значения доп. реквизитов.
Не используйте РеквизитФормыВЗначение для основного реквизита формы, если форма в режиме только чтения — это может работать некорректно. Лучше получить объект по ссылке из базы данных (Ссылка.ПолучитьОбъект()).
Будьте осторожны с механизмом Версионирования. Если он включен, запись объекта от имени пользователя создаст запись в истории версий, даже если он "не имеет прав". В истории автором изменений будет числиться этот пользователь.

Почему не стоит использовать RLS (Ограничение доступа на уровне записей)?

Часто возникает идея настроить RLS (Record Level Security). Давайте выясним, почему в данном случае это плохой путь.

Стандартный RLS в 1С фильтрует данные горизонтально (какие строки/объекты видит пользователь: например, "Сотрудники только моего подразделения"). Настройка RLS для фильтрации вертикально (запрет редактирования отдельных колонок/реквизитов при разрешении редактирования других) — задача крайне ресурсоемкая.

В типовых конфигурациях, таких как ЗУП, шаблоны RLS очень сложны. Попытка внедрить туда логику "можно писать, но только поле ДопРеквизит" приведет к:

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

Резюме

Для решения задачи доступа только к дополнительным полям:

Если есть возможность — используйте Дополнительные сведения (регистр сведений). Это штатный механизм, легко настраиваемый через профили доступа.
Если нужны именно Дополнительные реквизиты — создавайте расширение с собственной кнопкой сохранения, которая выполняет запись объекта в коде, обернутом в УстановитьПривилегированныйРежим(Истина).