Как в 1С проверить право пользователя на добавление записей в регистр сведений?

При работе с механизмами управления доступом в системе 1С:Предприятие разработчики часто сталкиваются с тем, что стандартный набор прав для разных объектов метаданных различается. Одной из таких особенностей является работа с регистрами сведений. В отличие от справочников или документов, где мы привыкли видеть право Интерактивное добавление, регистры сведений ведут себя иначе.

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

Особенности архитектуры прав доступа регистров сведений

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

Рассмотрим основные права, которые отвечают за запись данных:

1. Изменение (Update): Это право определяет, может ли пользователь в принципе модифицировать данные регистра программным способом. Сюда входит и добавление новых комбинаций измерений, и изменение ресурсов в уже существующих записях.
2. Редактирование (Edit): Это право надстроечного уровня. Оно определяет, разрешено ли пользователю менять данные через стандартные формы интерфейса (интерактивно).

Важный момент: Если вы хотите запретить пользователю вводить новые записи вручную, но разрешить это делать программно (например, при проведении документа), вам нужно ограничить право Редактирование, оставив право Изменение.

Программная проверка прав через функцию ПравоДоступа

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

Рассмотрим пример кода для проверки права на изменение регистра:

Если ПравоДоступа("Изменение", Метаданные.РегистрыСведений.ИмяВашегоРегистра) Тогда
    // Логика, если право есть
    Сообщить("Пользователь имеет право на запись в регистр");
Иначе
    // Логика, если доступа нет
    Отказ = Истина;
    Сообщить("Недостаточно прав для изменения данных регистра!");
КонецЕсли;

Обратите внимание, что мы проверяем именно право "Изменение". Если ваша задача — проверить, может ли пользователь работать с регистром именно через формы, используйте параметр "Редактирование".

Как отличить "добавление" от "обновления" записи

Так как платформа объединяет создание новой записи и изменение старой в одно право Изменение, иногда возникает бизнес-задача: разрешить менять старые записи, но запретить создавать новые (или наоборот). Разберем, как это реализовать программно.

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

МенеджерЗаписи = РегистрыСведений.ИмяВашегоРегистра.СоздатьМенеджерЗаписи();
// Заполняем измерения, которые хотим проверить
МенеджерЗаписи.Период = ТекущаяДата();
МенеджерЗаписи.Измерение1 = Значение1;

// Пытаемся прочитать запись
МенеджерЗаписи.Прочитать();

Если Не МенеджерЗаписи.Выбран() Тогда
    // Это означает, что записи с такими ключами нет — происходит ДОБАВЛЕНИЕ
    Если Не МояДополнительнаяПроверкаПравНаСоздание() Тогда
        ВызватьИсключение "У вас нет прав на создание новых записей в этом регистре!";
    КонецЕсли;
КонецЕсли;

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

Влияние режима подчинения регистратору

Ситуация существенно меняется, если регистр является подчиненным регистратору. В этом случае возможность записи в регистр жестко связана с правами на документ-регистратор. Проанализируем нюансы:

• Права на запись в такой регистр обычно не настраиваются отдельно (кроме права Чтение).
• Если у пользователя есть право на проведение документа, который является регистратором для данного регистра, то при проведении записи будут добавлены автоматически, даже если на сам регистр прав минимум.
• Проверка ПравоДоступа("Изменение", ...) для таких регистров часто может вводить в заблуждение, так как фактически управление идет через документ.

Использование механизмов RLS и ролей

Если стандартных прав недостаточно, мы можем использовать дополнительные инструменты:

1. RLS (Row Level Security): Позволяет настроить ограничение на уровне конкретных строк. Например, можно разрешить добавлять записи только с определенным значением измерения (например, по "Организации" или "Подразделению").
2. Функция РольДоступна: Иногда проще создать специальную роль (например, "РазрешитьДобавлениеВРегистрЦен") и проверять её наличие у пользователя.

Посмотрим на пример проверки конкретной роли:

Если РольДоступна("ПолныеПрава") Или РольДоступна("СпециальнаяРольНаЗапись") Тогда
    // Выполняем действие
КонецЕсли;

Важность контекста: Привилегированный режим

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

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

Резюме

Подведем итоги нашего анализа. Для проверки возможности добавления записей в регистр сведений следует помнить:

1. Отдельного права Добавление не существует, используйте Изменение.
2. Для разграничения программной и интерактивной записи разделяйте проверку прав Изменение и Редактирование.
3. Если нужно запретить именно создание новых записей (при разрешении менять старые), используйте предварительное чтение записи по ключу для проверки её существования.
4. Всегда учитывайте, не является ли регистр подчиненным регистратору, так как в этом случае "главным" объектом прав становится документ.

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