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