← На главную

При работе в типовых конфигурациях на платформе «1С:Предприятие 8.3» (например, «Бухгалтерия государственного учреждения 2.0», «Бухгалтерия предприятия 3.0», «ERP» и других) администраторы и разработчики часто сталкиваются с парадоксальной ситуацией. Пользователю назначается профиль групп доступа с многообещающим названием «Полные права (без административных функций)», однако при попытке изменить или провести некоторые документы (например, специализированные «Чеки ККМ для реестра платежей») система выдает ошибку прав доступа.

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

В чем разница между ролью «Полные права» и профилем «Полные права»?

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

1. Роль в Конфигураторе (Metadata Role): Это конкретный объект метаданных (Роль), созданный разработчиком в ветке конфигурации «Общие -> Роли». Роль ПолныеПрава (в коде часто именуемая как FullAccess) предоставляет полный доступ ко всем прикладным таблицам базы данных (документам, справочникам, регистрам), но не дает административных прав на уровне платформы (таких как обновление конфигурации или создание пользователей).
2. Профиль групп доступа в режиме Предприятия: Это элемент одноименного справочника БСП. Профиль представляет собой набор (коллекцию) множества мелких ролей, скомпонованных для выполнения определенной рабочей функции. Профиль «Полные права (без административных функций)» — это лишь красивое название для очень широкого, но все же ограниченного набора ролей. Настоящей роли ПолныеПрава внутри этого профиля нет.

Рассмотрим структуру типового профиля «Полные права (без административных функций)». Разработчики БСП сознательно исключили из него роль ПолныеПрава, собрав профиль из сотен точечных ролей (таких как «Добавление и изменение документов расчетов», «Чтение базовой нормативно-справочной информации» и т.д.). Сделано это из соображений безопасности и для корректной работы механизмов RLS.

Почему роли «Полные права» нет в списке выбора в режиме «1С:Предприятие»?

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

В подсистеме «Управление доступом» БСП действует жесткое правило: если у пользователя активна роль «Полные права», для него полностью отключаются любые ограничения на уровне записей (RLS). База данных начинает работать быстрее, так как платформе не нужно накладывать дополнительные условия фильтрации к SQL-запросам (например, проверку по организациям или подразделениям).

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

Причина проблемы на примере документа «Чеки ККМ для реестра платежей»

Рассмотрим конкретную ситуацию, описанную пользователем. В конфигурации БГУ 2.0 есть документ «Чек ККМ для реестра платежей». В свойствах этого документа права на «Изменение» и «Интерактивное добавление» назначены только одной роли — ПолныеПрава.

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

1. Разработчики конфигурации допустили неточность: Создав новый прикладной документ, они забыли включить права на него в другие поставляемые роли (например, в роли для кассиров или бухгалтеров по учету денежных средств). В итоге документ остался доступен для изменения только «чистым» Администраторам.
2. Документ является системным или техническим: Возможно, этот объект вообще не предназначен для ручного изменения пользователями, и его создание/редактирование должно происходить исключительно программно под привилегированным режимом выполнения кода.

Как решить проблему с правами доступа? Разбираем варианты по шагам

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

Способ 1. Создание и назначение точечной роли (Рекомендуемый)

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

Выполним следующие шаги в Конфигураторе:

1. Добавим новую роль в дереве метаданных. Назовем ее, например, ДобавлениеИзменениеЧековККМРеестра.
2. В окне настройки прав для этой роли найдем документ ЧекККМДляРеестраПлатежей и установим галочки на права: «Чтение», «Просмотр», «Ввод новых», «Добавление», «Редактирование», «Изменение».
3. Если конфигурация использует БСП (что является стандартом для БГУ 2.0), нам необходимо зарегистрировать новую роль в справочнике идентификаторов объектов метаданных. Для этого запустим базу в режиме «1С:Предприятие» под пользователем с административными правами с параметром запуска: /С ЗапуститьОбновлениеИнформационнойБазы
4. Перейдем в раздел «Администрирование -> Настройки пользователей и прав -> Профили групп доступа». Создадим новый профиль (или отредактируем существующий пользовательский) и включим в него нашу новую роль ДобавлениеИзменениеЧековККМРеестра.
5. Назначим данный профиль целевому пользователю.

Способ 2. Использование расширения конфигурации

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

Посмотрим на пример реализации через расширение:

1. Создадим новое расширение конфигурации.
2. Добавим в расширение документ ЧекККМДляРеестраПлатежей.
3. Создадим в расширении роль (например, Расш_ДоступКЧекамККМ) и предоставим ей права на чтение и изменение этого документа.
4. Назначим созданную роль пользователю. Обратите внимание: роли из расширений также требуют корректной инициализации в подсистеме управления доступом БСП. Для этого может потребоваться запустить обработку «Обновление вспомогательных данных» или дождаться автоматического обновления прав при перезапуске системы.

Важное предупреждение о ручном назначении ролей в Конфигураторе

Некоторые администраторы пытаются решить проблему «быстрым» путем: открывают Конфигуратор, заходят в свойства конкретного пользователя на вкладку «Прочие» и вручную ставят галочку напротив роли «Полные права».

Делать так категорически не рекомендуется! Современные конфигурации на базе БСП при каждом входе пользователя в систему или при выполнении регламентных заданий производят синхронизацию ролей в Конфигураторе с группами доступа, назначенными в режиме «1С:Предприятие». Программа обнаружит «лишнюю» роль, установленную в обход интерфейса Предприятия, и автоматически снимет ее при первом же обновлении прав или запуске сеанса. Решайте вопросы прав исключительно через справочники профилей и групп доступа.