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