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