Часто в процессе эксплуатации 1С:ERP возникает задача по ограничению доступа к определенным разделам системы для пользователей, обладающих расширенными полномочиями. Одной из наиболее частых проблем является необходимость скрытия подраздела НСИ и администрирование для персонала, которому по ошибке или производственной необходимости были назначены Полные права. Давайте разберем, почему это вызывает технические сложности и какие методы решения существуют.
Прежде чем приступать к настройке, важно уяснить фундаментальный принцип работы платформы 1С:Предприятие. Роль Полные права (или Администратор системы) является привилегированной по своей природе. Система проектировалась так, чтобы администратор всегда имел безусловный доступ ко всем объектам метаданных, настройкам Функциональных опций и элементам командного интерфейса.
Важно: Программное задание Видимость = Ложь для разделов навигации будет проигнорировано платформой, если у пользователя есть полные права. Более того, даже если бы удалось скрыть элемент через расширение, пользователь с правами администратора всегда сможет вернуть видимость через штатную настройку панели разделов в интерфейсе программы.
Поскольку прямое скрытие интерфейсных элементов для «администраторов» не дает результата, рассмотрим альтернативные подходы, которые позволяют обеспечить безопасность данных, не вступая в конфликт с архитектурой системы.
Вместо того чтобы скрывать кнопку, мы можем ограничить доступ к данным, которые за ней стоят. Если пользователь видит раздел, но не имеет прав на чтение или изменение соответствующих справочников и регистров, работа в этом разделе будет для него бессмысленной. Рассмотрим пошаговый план:
БСП (Библиотеки стандартных подсистем), создав профиль с ограниченным набором ролей.RLS (ограничение доступа на уровне записей).Если вы хотите ограничить действия пользователя программно, используйте расширения конфигурации. Вместо скрытия интерфейса, вы можете блокировать выполнение операций при попытке внесения изменений. Разберем пример логики для расширения:
Для предотвращения несанкционированного изменения настроек используйте событие ПередЗаписью в модуле объекта:
&ПередЗаписью("ПередЗаписью")
Процедура Расширение_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если Не РольДоступна("АдминистраторНастроек") Тогда
ВызватьИсключение "У вас нет прав на изменение данных настроек НСИ!";
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
RLS (Row Level Security) позволяет наложить условие на чтение и запись данных. Даже если пользователь видит форму, при попытке записи система выполнит проверку. Настройте шаблон ограничений так, чтобы при выполнении условий (например, отсутствии роли) пользователю было отказано в доступе к данным:
Пример условия RLS для справочника:
ТекущаяТаблица
ГДЕ ИСТИНА
И (ДОБАВИТЬ_УСЛОВИЕ_ОГРАНИЧЕНИЯ_ПО_РОЛИ)
Разберем, почему раздача Полных прав всем пользователям является рискованной стратегией:
В завершение, проанализируем текущую ситуацию: попытка «костыльного» скрытия интерфейса не решает проблему безопасности. Мы рекомендуем сфокусироваться на настройке профилей БСП и внедрении ограничений на уровне RLS. Это позволит сохранить рабочее пространство для пользователей, при этом надежно защитив систему от случайных или преднамеренных действий, нарушающих учет.