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