← На главную

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

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

Основные причины проблемы

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

1. Безопасный режим расширения (на уровне базы данных).
2. Профили безопасности кластера (на уровне сервера 1С).
3. Способ назначения ролей (объединение или новые объекты).
4. Ограничения интерфейса (особенно для обычных форм).

Рассмотрим каждый из этих пунктов детально и определим порядок действий для устранения неисправности.

Безопасный режим расширения

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

В безопасном режиме расширению запрещено:

• Выполнять серверный код, который может быть небезопасным.
• Расширять права доступа (изменять роли).

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

Как это исправить:

Нам необходимо отключить этот режим в настройках расширения внутри режима «1С:Предприятие». Пройдем по шагам:

1. Заходим в базу под пользователем с полными (административными) правами.
2. Открываем Функции для технического специалиста (ранее «Все функции»). Если этот пункт недоступен, его нужно включить в меню «Настройки — Параметры».
3. В дереве функций находим пункт Стандартные — Управление расширениями конфигурации.
4. В открывшемся списке находим наше расширение.
5. Снимаем галочку Безопасный режим.
6. Перезапускаем сеанс пользователя, для которого настраивали права.

После снятия этой настройки платформа разрешит расширению влиять на модель прав доступа текущей конфигурации.

Профили безопасности кластера (Клиент-сервер)

Если ваша база работает в файловом варианте, то предыдущего пункта (снятия безопасного режима) обычно достаточно. Однако, если мы работаем в клиент-серверном варианте (SQL), в дело вступают настройки кластера серверов 1С.

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

Давайте проанализируем логику работы прав в зависимости от наличия профиля безопасности:

Вариант А: Информационная база работает БЕЗ назначенного профиля безопасности.
В старых версиях платформы расширение ролей в таком режиме вообще не допускалось. В современных версиях это поведение может варьироваться, но часто система блокирует попытки расширения прав, считая их потенциальной угрозой, если администратор явно не разрешил это через профиль.

Вариант Б: Информационная база работает С использованием профиля безопасности.
В этом случае возможности расширения полностью зависят от галочек внутри самого профиля в консоли администрирования серверов.

Для того чтобы права заработали, системный администратор должен:

1. Зайти в Консоль администрирования серверов 1С.
2. Открыть свойства Профиля безопасности, назначенного данной базе.
3. Убедиться, что установлена опция, разрешающая расширение прав доступа для расширений конфигурации.

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

Особенности Обычных форм (Толстый клиент)

В обсуждаемой теме автор упомянул, что конфигурация работает на обычных формах. Это вносит существенные коррективы в диагностику проблемы.

Механизм расширений изначально проектировался и оптимизировался под управляемое приложение (Такси). В обычном приложении (толстом клиенте) поддержка функционала ограничена. Для корректной настройки прав в таких системах, как УТ 10.3 или УПП 1.3, может потребоваться специализированный анализ прав и ролей для поиска подходящего профиля. Давайте разберем, что работает, а что нет.

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

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

Если вы дали право на удаление, но кнопка в журнале документов остается серой (неактивной), возможны следующие причины:

• Интерфейс обычного приложения закэшировал старые права. Требуется перезаход в систему.
• В свойствах формы или командной панели стоит явная привязка к старой роли или проверка прав в коде формы (например, ПриОткрытии), которая не учитывает вашу новую роль из расширения.
• Платформа в толстом клиенте некорректно отображает доступность стандартной кнопки удаления при расширении прав.

Правильное назначение ролей: Заимствование vs Новая роль

Еще один важный момент — как именно вы добавили права. В системе есть два подхода:

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

Подход 2: Создание новой роли в расширении.
Вы создаете в дереве метаданных расширения абсолютно новую роль, например Расширение_ПравоУдаления. При использовании БСП 3 иногда требуется дополнительная защита ролей расширений, добавленных администраторам, чтобы права не сбрасывались при обновлении кэша прав.
Результат: Само наличие этой роли ничего не дает. Эту новую роль нужно явно назначить пользователю.

Сделать это можно двумя способами:

1. В Конфигураторе: Меню «Администрирование — Пользователи». Открываем пользователя, идем на вкладку «Прочее» и ставим галочку напротив новой роли.
2. В Предприятии: В справочнике «Пользователи» (если используется БСП) может потребоваться создать новый Профиль групп доступа, включить в него эту роль и назначить профиль пользователю. В некоторых случаях, если права не обновились, стоит выполнить точечный пересчет прав доступа для пользователя.

Интерактивное удаление против Программного

Автор вопроса упомянул, что поставил «все галочки». Давайте уточним, какие именно права нужны для удаления.

В дереве прав для каждого объекта (документа, справочника) есть две группы прав на удаление:

1. Удаление — это право на программное удаление объекта и на удаление помеченных объектов.
2. Интерактивное удаление — это право пользователя нажать кнопку и удалить объект (минуя пометку удаления).

Если пользователь все равно получает отказ системы, воспользуйтесь инструментом помощник определения нарушений прав доступа, который поможет точно локализовать объект и право, вызывающее ошибку.

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

Алгоритм решения проблемы

Подводя итог, если вы столкнулись с подобной ситуацией, выполните следующие действия:

1. Проверка Безопасного режима. Зайдите в «Управление расширениями конфигурации» и снимите флаг «Безопасный режим» у вашего расширения.
2. Проверка назначения роли. Убедитесь, что роль назначена пользователю, и при необходимости выполните пересчет прав — это удобнее через универсальную настройку и аудит прав пользователей.
3. Проверка прав в метаданных. Используйте обработку для быстрой проверки прав доступа, чтобы убедиться, что права на Удаление и ИнтерактивноеУдаление активны — в этом поможет анализ и сравнение ролей с учетом RLS.
4. Анализ профиля безопасности (для клиент-сервера). Если база SQL, проверьте настройки профиля кластера.
5. Тест RLS. Проверьте, не действуют ли на пользователя ограничения по датам запрета или организациям.

При работе с обычными формами будьте готовы к тому, что стандартные кнопки могут не отреагировать на изменение прав мгновенно, и потребуется проверка фактического выполнения действия.