Как создать роль администратора в 1С через расширение с ограниченными правами на изменение пользователей и удаление помеченных объектов?

← На главную

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

Наш читатель столкнулся именно с такой задачей в конфигурации "Бухгалтерия ювелирного ломбарда" на управляемых формах. Ему необходимо было создать роль администратора, которая имела бы все функции с полными правами, но не позволяла бы изменять пользователей и их права, а также удалять помеченные объекты. Попытки создать заимствованную роль в расширении и снять эти права не дали желаемого результата, поскольку пользователь все равно мог изменять других пользователей.

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

Ключевая проблема при работе с заимствованными ролями в расширениях

Мы выясним, что не все права можно изменить в заимствованной роли через расширение. Согласно документации 1С (ИТС), в заимствованной роли невозможно изменить права доступа, которые задаются для корневого объекта конфигурации. К таким правам относятся административные права, такие как возможность использования того или иного клиентского приложения, а главное — управление пользователями и их доступом к системе.

Это означает, что если мы заимствуем роль "Полные права" или "АдминистраторСистемы" и попытаемся снять с нее права на изменение пользователей, платформа 1С проигнорирует эти ограничения для административных функций. Данное ограничение обусловлено архитектурой безопасности 1С, где базовые административные функции жестко привязаны к корневым правам конфигурации и не могут быть модифицированы через заимствованные роли расширений. Таким образом, проблема, с которой столкнулся наш читатель, является ожидаемым поведением платформы.

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

Подходы к решению задачи

1. Создание новой роли в расширении и программное назначение

Одним из наиболее гибких и правильных способов, если мы хотим иметь полный контроль над правами, является создание совершенно новой роли непосредственно в расширении. Начиная с версии 8.3.9.1818, платформа 1С предоставляет возможность создавать собственные роли в расширениях. Эти роли могут использоваться для определения наборов прав как на объекты, добавленные самим расширением, так и на объекты основной конфигурации.

Разберем по шагам, как мы можем реализовать этот подход:

Создаем новое расширение или открываем существующее: В конфигураторе открываем наше расширение.
Добавляем новую роль в расширение: Мы создаем новую роль, например, АдминистраторОграниченный. При создании этой роли в расширении у нас будет полный контроль над всеми правами.
Назначаем права новой роли: Для новой роли АдминистраторОграниченный мы устанавливаем необходимые права:
- Мы предоставляем все права, которые нужны администратору, кроме двух исключений.
- Мы НЕ предоставляем права на Справочник.Пользователи: снимаем флажки "Чтение", "Изменение", "Добавление", "Удаление", "Просмотр" и т.д.
- Мы НЕ предоставляем права на Обработка.ПоискИУдалениеПомеченныхОбъектов: снимаем флажок "Использование".
- Для других объектов, где требуется запрет на интерактивное удаление, мы снимаем право "Интерактивное удаление".
Программное назначение новой роли пользователям: Поскольку новая роль создана в расширении, мы не можем просто выбрать ее в стандартном списке ролей для пользователя. Вместо этого, мы должны программно назначить эту роль пользователю. Это можно сделать, например, через общий модуль или с использованием дополнительной обработки/формы, которая будет управлять правами пользователей.

Пример программного назначения роли (это может быть выполнено в специальной обработке или общем модуле с привилегированным режимом):


// В обработке или общем модуле
// Предполагается, что у текущего пользователя есть права на изменение пользователей.
// Это пример, требующий доработки под конкретную ситуацию.

&НаСервере
Процедура НазначитьРольПользователю(ПользовательСсылка, ИмяРолиРасширения)
    // Устанавливаем привилегированный режим для работы с правами
    УстановитьПривилегированныйРежим(Истина);

    ПользовательОбъект = ПользовательСсылка.ПолучитьОбъект();

    // Получаем текущие роли пользователя
    ТекущиеРоли = Новый Массив;
    Для Каждого РольИзТекущих Из ПользовательОбъект.Роли Цикл
        ТекущиеРоли.Добавить(РольИзТекущих.Имя);
    КонецЦикла;

    // Проверяем, есть ли уже нужная роль
    Если ТекущиеРоли.Найти(ИмяРолиРасширения) = Неопределено Тогда
        // Добавляем новую роль
        НоваяРоль = ПользовательОбъект.Роли.Добавить();
        НоваяРоль.Имя = ИмяРолиРасширения;
        ПользовательОбъект.Записать();
        Сообщить("Роль '" + ИмяРолиРасширения + "' успешно назначена пользователю " + ПользовательСсылка.Наименование);
    Иначе
        Сообщить("Роль '" + ИмяРолиРасширения + "' уже назначена пользователю " + ПользовательСсылка.Наименование);
    КонецЕсли;

    УстановитьПривилегированныйРежим(Ложь);
КонецПроцедуры

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

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

2. Заимствование роли "Полные права" и ограничение отдельных прав (с учетом ограничений)

Хотя мы выяснили, что для корневых административных прав заимствование роли и попытка их ограничения может не сработать, для большинства других объектов конфигурации этот подход является вполне рабочим. Мы можем заимствовать роль "Полные права" и снять с нее доступ к конкретным объектам или правам, не связанным с корневыми административными функциями.

Давайте рассмотрим, как мы можем попытаться применить этот подход, помня об ограничениях:

Заимствуем роль "Полные права": В нашем расширении мы заимствуем роль "Полные права" из основной конфигурации. После заимствования у нас появляется возможность модифицировать права этой роли в рамках расширения.
Ограничиваем доступ к "Справочнику.Пользователи" и связанным объектам:
- Мы открываем заимствованную роль и находим объект Справочник.Пользователи.
- Снимаем все права, связанные с изменением, добавлением и удалением: "Изменение", "Добавление", "Удаление". Возможно, придется снять и "Чтение", если мы хотим полностью скрыть информацию о пользователях.
- Мы также должны рассмотреть связанные объекты, такие как Справочник.ГруппыДоступа, Справочник.ПрофилиГруппДоступа, РегистрСведений.ПраваДоступа и другие, отвечающие за систему прав. Для них мы также снимаем или ограничиваем права.
Важное напоминание: Из-за ограничения на изменение корневых административных прав, описанного выше, эта попытка может быть не полностью успешной для самого Справочник.Пользователи, особенно в части создания/изменения прав. Пользователь, имеющий эту заимствованную роль, все еще может обладать частью административных прав.
Ограничиваем доступ к "Обработке.ПоискИУдалениеПомеченныхОбъектов":
- Находим в заимствованной роли объект Обработка.ПоискИУдалениеПомеченныхОбъектов.
- Снимаем право "Использование". Это запретит запуск обработки.
Для интерактивного удаления объектов в целом, мы должны быть более аккуратными.
Ограничиваем право "Интерактивное удаление" для других объектов:
- Платформа 1С рекомендует, чтобы роли "ПолныеПрава" и "АдминистраторСистемы" давали право на удаление ссылочных объектов (например, программное удаление), но ни одна роль, включая их, не должна давать право на интерактивное удаление ссылочных объектов, которые могут нарушить ссылочную целостность.
- Если нам необходимо запретить интерактивное удаление для большинства объектов, мы должны пройтись по нужным объектам в заимствованной роли и снять флажок "Интерактивное удаление".
- Если же нам требуется дать возможность удаления помеченных объектов "неполноправным" пользователям (т.е. тем, кто не является полным администратором), рекомендуется создать отдельную роль, например, УдалениеПомеченныхОбъектов, и назначать ее совместно с другими ролями тем пользователям, которым необходим этот функционал. Эту роль также можно создать в расширении.

Вывод по этому подходу: Несмотря на кажущуюся простоту, этот метод может быть недостаточным для полноценного ограничения административных прав, связанных с управлением пользователями, из-за особенностей платформы 1С. Однако он хорошо подходит для ограничения доступа к обычным объектам метаданных или определенным обработкам.

3. Использование подписки на события или обработчика в модуле объекта

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

Рассмотрим, как мы можем реализовать программный контроль:

Подписка на событие "ПередЗаписью" для справочника "Пользователи":
- Мы создаем новую подписку на событие в расширении.
- Имя события: ПередЗаписью.
- Источник события: Справочник.Пользователи (или другие объекты, связанные с правами).
- Обработчик: указываем функцию в общем модуле, которую также создаем в расширении.
- В этой функции-обработчике мы будем проверять текущего пользователя.

Реализация функции-обработчика:


// В общем модуле расширения (например, "МодульКонтроляПрав")
// Устанавливаем свойство "Вызов сервера" и "Привилегированный"
// для общего модуля, чтобы иметь доступ ко всем данным.

Процедура ПередЗаписьюПользователя(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    // Проверяем, кто пытается записать/изменить пользователя
    Если Не РольДоступна("ПолныеПрава") ИЛИ Не ТекущийПользователь.Имя = "СуперАдмин" Тогда // Пример проверки
        // Здесь мы можем ввести нашу логику.
        // Например, если текущий пользователь имеет роль "АдминистраторОграниченный"
        // и пытается изменить Справочник.Пользователи, то мы запрещаем это.

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

// Функция для проверки доступности роли у текущего пользователя
// Может быть в этом же общем модуле или в другом клиентском/серверном модуле.
Функция РольДоступна(ИмяРоли)
    Возврат ПользователиИнформационнойБазы.ТекущийПользователь().Роли.Найти(ИмяРоли) <> Неопределено;
КонецФункции

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

Для запрета удаления помеченных объектов:
- Мы можем создать подписку на событие ПередУдалением для соответствующих объектов или использовать обработку Обработка.ПоискИУдалениеПомеченныхОбъектов.
- В модуле объекта Обработка.ПоискИУдалениеПомеченныхОбъектов (если он заимствован или если это наша собственная обработка) мы можем добавить проверку прав перед выполнением критичных действий.
- Если мы хотим запретить использование типовой обработки, достаточно снять с нее право "Использование" в соответствующей роли, как мы рассматривали ранее. Если же мы хотим более тонкого контроля, то можем перехватывать ее вызовы или модифицировать ее логику через расширение.

Этот подход требует более глубокого понимания программной логики и может быть сложнее в поддержке, но он дает максимальный контроль над бизнес-логикой и безопасностью.

4. Управление через профили групп доступа (косвенный подход)

Профили групп доступа в 1С служат шаблонами для создания новых групп доступа и упрощают управление наборами ролей. Хотя этот метод не решает проблему изменения самой структуры прав в заимствованной роли, он может помочь в создании и назначении предопределенных наборов прав.

Разберем, как мы можем использовать профили:

Изучаем существующие профили: Мы открываем Справочник.ПрофилиГруппДоступа в режиме "Предприятие" или через конфигуратор. Мы увидим, что профили, такие как "Администратор", уже содержат роль "Полные права" или другие административные роли.
Создаем новый профиль на основе существующего: Мы можем скопировать существующий профиль (например, "Администратор") и назвать его "АдминистраторОграниченный".
Корректируем роли в новом профиле: В новом профиле "АдминистраторОграниченный" мы можем:
- Убрать роль "Полные права" (если она там есть) и добавить нашу новую роль АдминистраторОграниченный, которую мы создали в расширении (см. подход 1).
- Если наша цель - ограничить доступ к "Пользователям" и "Удалению помеченных", а предыдущие подходы с заимствованием не сработали, то добавление сюда нашей специально созданной роли (с ограничениями) является самым надежным путем.
- Мы можем удалить все роли, связанные с управлением пользователями и их правами, и добавить только те роли, которые дают необходимые административные функции, исключая запрещенные.
Назначаем профиль группам доступа: Затем мы создаем новую группу доступа (например, "Администраторы с ограничениями") и назначаем ей наш новый профиль "АдминистраторОграниченный". После этого добавляем пользователей в эту группу доступа.

Замечание: Роль "Полные права" может отсутствовать в списке ролей, предлагаемых пользователям напрямую, но она часто является частью предопределенного профиля "Администратор". Поэтому работа через профили групп доступа, дополненная созданием собственной роли в расширении, является мощным инструментом для управления доступом.

Резюме и рекомендации

Мы выяснили, что прямая попытка ограничить административные права в заимствованной роли через расширение, скорее всего, не принесет успеха из-за архитектурных особенностей платформы 1С. Для решения задачи ограничения прав на изменение пользователей и удаление помеченных объектов, когда конфигурация находится на поддержке, мы рекомендуем следующий подход:

Создайте новую роль в расширении (например, АдминистраторОграниченный). Мы настраиваем эту роль, предоставляя все необходимые административные права, но явно снимаем права на Справочник.Пользователи (все, что связано с записью) и Обработка.ПоискИУдалениеПомеченныхОбъектов (Использование). Также мы внимательно относимся к праву "Интерактивное удаление" для других объектов.
Программно назначаем эту новую роль тем пользователям, которые должны иметь ограниченные административные права. Для этого можно использовать специальную обработку или общий модуль.
Если требуется дополнительная гранулярность или есть сложные условия, мы можем использовать подписки на события (например, ПередЗаписью для Справочник.Пользователи) для программного контроля действий пользователя. Это позволит нам внедрить бизнес-логику для проверки ролей или других условий перед разрешением или запретом операций.
Для удобства управления такими наборами прав, мы можем создать новый профиль групп доступа, который будет включать только нашу специально созданную роль АдминистраторОграниченный.

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