Почему слетают роли пользователей в 1С:Управление торговлей 11 и как это исправить?

← На главную

Приветствуем вас, уважаемые коллеги! Сегодня мы детально разберем одну из самых распространенных и при этом неочевидных проблем, с которой сталкиваются разработчики при доработке прав доступа в типовых конфигурациях 1С, построенных на базе Библиотеки стандартных подсистем (БСП). Речь идет о ситуации, когда новые, добавленные вручную роли пользователей постоянно «слетают» (с них автоматически снимаются галочки в Конфигураторе) с завидной регулярностью.

Казалось бы, вы все сделали правильно: добавили роль в Конфигураторе, создали соответствующий профиль групп доступа в режиме «1С:Предприятие», включили туда пользователя. Но проходит немного времени (или запускается очередное регламентное обновление ИБ), и галочки напротив вашей новой роли в Конфигураторе у определенных пользователей снова исчезают. Давайте разберемся, почему так происходит, и рассмотрим по шагам, как решить эту проблему раз и навсегда.

Выясняем причину: глубинная логика работы БСП

Прежде чем приступать к исправлению, проанализируем архитектуру управления правами в БСП. В современных конфигурациях, таких как Управление торговлей 11, правами пользователей полностью управляет специализированная программная подсистема. В ней заложен жесткий методологический стандарт: если пользователю назначена роль «Полные права» или «Администратор системы», то никакие другие роли ему физически не нужны. Полные права по умолчанию дают неограниченный доступ ко всем существующим объектам метаданных.

В БСП встроен механизм автоматической синхронизации ролей. При записи пользователя в режиме «1С:Предприятие», при работе фоновых заданий, а также при запуске базы с ключом обновления запускается процедура автоматической очистки лишних ролей. За этот процесс отвечает общий модуль УправлениеДоступомСлужебный, а именно процедура ОбновитьРолиПользователей.

Алгоритм работает следующим образом: система анализирует список прав пользователя. Если у него обнаружены роли администратора, БСП принудительно очищает все остальные роли из списка в Конфигураторе, оставляя только предопределенный административный минимум. Это приводит к тому, что стандартная платформенная функция РольДоступна() для вашей самописной роли начинает возвращать Ложь, так как физически в Конфигураторе флаг с роли у пользователя снят.

Ниже мы подробно разберем несколько практических способов, которые помогут нам обойти это ограничение.

Решение 1. Изменение логики проверки прав в коде (Рекомендуемый стандарт «1С»)

Методически самым правильным решением является отказ от использования платформенного метода РольДоступна() в коде ваших доработок. Если вы проверяете доступность роли у пользователя, у которого потенциально могут быть полные права, используйте встроенные механизмы БСП.

Вместо классической проверки:


Если РольДоступна("Логист") Тогда
    // Выполняем действия, доступные логисту
    // Внимание: данный код не сработает для Администратора, если роль "Логист" у него слетела!
КонецЕсли;

Мы рекомендуем использовать безопасный вызов функции БСП из общего модуля Пользователи. Эта функция устроена таким образом, что она проверяет не только наличие конкретной роли, но и наличие полных прав у текущего пользователя. Если у пользователя есть полные права, функция автоматически вернет Истина, даже если сама роль «Логист» у него снята в Конфигураторе:


Если Пользователи.РолиДоступны("Логист") Тогда
    // Код отработает корректно и для обычного логиста, и для администратора системы
КонецЕсли;

Если по каким-то причинам вы не хотите использовать функции БСП (например, работаете в старой или сильно измененной конфигурации), обязательно дополняйте платформенную проверку явным условием на полные права:


Если РольДоступна("Логист") Или РольДоступна("ПолныеПрава") Или РольДоступна("АдминистраторСистемы") Тогда
    // Ручная проверка на полные права спасает от затирания роли
КонецЕсли;

Решение 2. Регистрация роли в процедуре БСП через расширение конфигурации

Если вам критически важно, чтобы роль физически оставалась назначенной пользователю в Конфигураторе (например, на эту роль завязаны новые объекты конфигурации, которые не видны пользователю без прямой роли, или сложные RLS-ограничения), нам придется научить БСП не удалять нашу роль при очистке.

Для этого мы можем доработать общий модуль УправлениеДоступомСлужебный. Разберем по шагам, как это сделать наиболее безопасно с помощью механизма расширений:

Создайте новое расширение конфигурации или откройте уже существующее.
Добавьте в расширение общий модуль УправлениеДоступомСлужебный.
Найдите в модуле процедуру ОбновитьРолиПользователей. В зависимости от версии БСП имя процедуры или состав ее параметров может незначительно отличаться, но логика остается прежней.
Внедрите в процедуру код, регистрирующий вашу роль как «разрешенную» дополнительную роль администратора. По умолчанию БСП разрешает администраторам иметь дополнительную роль ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок. Мы добавим нашу роль по аналогии.

Пример кода, который необходимо добавить в процедуру общего модуля через расширение:


&После("ОбновитьРолиПользователей")
Процедура ИмяПрефикса_ОбновитьРолиПользователей(Пользователь, НовыеРоли, Результат)
    // Добавляем нашу роль в список исключений, которые БСП не должна очищать у администраторов
    ДополнительныеРолиАдминистратора = Новый Соответствие;
    ДополнительныеРолиАдминистратора.Вставить("Логист", Истина);
КонецПроцедуры

После внедрения этой небольшой доработки БСП начнет воспринимать роль Логист как доверенную административную роль и перестанет снимать с нее флаг в Конфигураторе при очередном обновлении прав.

Решение 3. Использование недокументированного лайфхака с суффиксами (для БСП 3.1 и выше)

Если вы работаете на современных версиях БСП (начиная с версии 3.1.7), разработчики фирмы «1С» добавили интересное системное правило, которое можно использовать без изменения программного кода конфигурации и написания расширений.

При обновлении прав система анализирует имена всех ролей (включая роли, добавленные через расширения). Роли, имена которых заканчиваются на определенные ключевые суффиксы, автоматически классифицируются системой как роли администратора и не подлежат очистке. К таким суффиксам относятся:

АдминистраторСистемы
ПолныеПрава
ОбщиеПрава

Таким образом, если вы переименуете свою роль из простого названия Логист в название ЛогистПолныеПрава или Логист_ОбщиеПрава, алгоритмы БСП будут автоматически игнорировать эту роль при очистке прав администраторов. Это чрезвычайно простой и красивый способ решения проблемы, не требующий программирования.

Решение 4. Универсальный обход по префиксам для большого количества ролей

Рассмотрим ситуацию, когда новых нетиповых ролей в вашей конфигурации очень много, и прописывать каждую индивидуально в коде неудобно. В таком случае мы можем применить универсальный подход с использованием префиксов.

Давайте договоримся, что все наши новые роли будут начинаться с определенного префикса, например, ДОП_ (ДОП_Логист, ДОП_Закупки, ДОП_Продажи). Теперь мы можем модифицировать процедуру ОбновитьРолиПользователей так, чтобы она автоматически сохраняла и возвращала обратно любые роли с нашим префиксом:


// Перед тем как БСП произведет очистку ролей администратора, 
// соберем все наши роли с префиксом "ДОП_" в отдельный массив:
ВыбранныеДополнительныеРоли = Новый Массив;
Для Каждого Стр Из ТекущиеНовыеРоли Цикл
    Если ВРег(Лев(Стр.Role, 4)) = "ДОП_" Тогда 
        ВыбранныеДополнительныеРоли.Добавить(Стр.Роль);
    КонецЕсли;
КонецЦикла;

// ... далее отрабатывает стандартный алгоритм БСП ...

// После завершения очистки возвращаем наши роли обратно в список:
Для Каждого Стр Из ВыбранныеДополнительныеРоли Цикл
    НовыеРоли.Добавить().Роль = Стр;
КонецЦикла;

Этот метод гарантирует полную автоматизацию процесса. Вы сможете добавлять сколько угодно новых ролей в Конфигуратор, и до тех пор, пока они соответствуют правилу наименования с префиксом ДОП_, система безопасности БСП не будет их затирать у пользователей с полными правами.