Флажок «Независимые права подчиненных объектов» в роли: что он меняет на самом деле
Содержание
Флажок «Независимые права подчиненных объектов» стоит в нижней части окна редактора роли в конфигураторе. Если он снят, права реквизитов и табличных частей связаны с правами объекта-владельца: сняли право у справочника — оно снимется и у его реквизитов. Если установлен, права подчиненных объектов настраиваются отдельно, и редактор их не трогает.
Типичная ситуация: администратор готовит роль «Кладовщик», хочет скрыть закупочную цену в карточке номенклатуры, снимает «Просмотр» у одного реквизита, а потом, перенастраивая права справочника, теряет всю ручную работу. Или наоборот: включает независимый режим в надежде открыть доступ к реквизиту без прав на сам справочник — и получает Нарушение прав доступа!. Оба сценария упираются в одно и то же: как платформа связывает права родителя и подчиненных объектов.
Как права наследуются от объекта к его частям
У каждого объекта метаданных в роли есть свой набор прав. У справочника это «Чтение», «Добавление», «Изменение», «Удаление», «Просмотр», «Редактирование» и другие. У его частей набор короче.
📌 Что считается подчиненным объектом:
- 🔹 реквизиты объекта, включая стандартные (код, наименование, пометка удаления);
- 🔹 табличные части и реквизиты табличных частей;
- 🔹 команды объекта;
- 🔹 вложенные подсистемы — по отношению к родительской подсистеме.
У реквизита и табличной части в роли обычно два права: «Просмотр» и «Редактирование». У команды — «Просмотр». Это интерактивные права: они управляют тем, что пользователь видит и меняет в формах.
Связь «родитель — часть» работает на двух уровнях, и их полезно разделять:
| Уровень | Что происходит |
|---|---|
| Редактор роли (конфигуратор) | Флажок определяет, будут ли права частей автоматически следовать за правами владельца при настройке |
| Работа пользователя (1С:Предприятие) | Доступ к данным всегда начинается с права на объект. Право на реквизит может только сузить доступ, но не расширить его |
Второй уровень от флажка не зависит. Без права «Чтение» на справочник пользователь не прочитает ни один его реквизит, как бы ни были настроены права реквизитов.
Что меняет флажок независимых прав в редакторе роли
В нижней части окна роли три флажка:
- «Устанавливать права для новых объектов».
- «Устанавливать права для реквизитов и табличных частей по умолчанию».
- «Независимые права подчиненных объектов».
Третий и есть предмет статьи. Его поведение удобно описать двумя состояниями.
Флажок снят (зависимый режим, по умолчанию):
- ✅ установили право у реквизита — редактор сам установит соответствующее право у объекта-владельца;
- ❌ сняли право у объекта — редактор снимет это право у всех его реквизитов и табличных частей;
- 🔁 права частей «тянутся» за родителем, роль сложно привести в противоречивое состояние.
Флажок установлен (независимый режим):
- 🔓 права реквизитов и табличных частей хранятся отдельно;
- ✋ снятие права у справочника не стирает ручные настройки его реквизитов;
- ⚠️ можно получить роль, где у реквизита право есть, а у объекта нет. Такое право на практике не сработает.
Флажок «Устанавливать права для реквизитов и табличных частей по умолчанию» — соседний, но другой. Он отвечает за то, какие права получит реквизит, для которого их явно не задавали. Например, новый реквизит, добавленный при обновлении. Независимый режим отвечает за каскад при изменении прав владельца.
Зачем вообще нужен независимый режим, если он позволяет ошибиться? Он защищает тонкую настройку. Когда в роли десятки скрытых реквизитов, а права самого объекта время от времени перенастраивают, каскадное снятие в зависимом режиме сотрёт эту работу за один клик.
Включение режима: пошагово в конфигураторе
Перед правкой роли сделайте копию конфигурации или выгрузку базы в .dt. Изменение ролей требует обновления конфигурации базы данных, а оно идёт в монопольном режиме — пользователей придётся попросить выйти.
Если конфигурация типовая и стоит на поддержке, не меняйте типовые роли напрямую. Правка снимет роль с поддержки, и при каждом обновлении придётся сравнивать её вручную. Создайте свою роль в конфигурации или в расширении и настраивайте её.
Шаг 1. Откройте роль
- Запустите конфигуратор, откройте конфигурацию:
Конфигурация → Открыть конфигурацию. - В дереве метаданных разверните
Общие → Роли. - Двойным щелчком откройте нужную роль.
Шаг 2. Включите флажок
- Внизу окна редактора роли найдите флажок «Независимые права подчиненных объектов».
- Установите его.
- Проверьте соседний флажок «Устанавливать права для реквизитов и табличных частей по умолчанию». Чаще всего его оставляют включённым, чтобы новые реквизиты не оказались скрытыми без вашего ведома.
Шаг 3. Настройте права частей
- В левой части редактора найдите объект, например справочник «Номенклатура».
- Разверните его: появятся реквизиты, табличные части, команды.
- Выделите реквизит и снимите у него «Просмотр» или «Редактирование» в правой части окна.
- Убедитесь, что у самого справочника нужные права («Чтение», «Просмотр») остались.
Шаг 4. Сохраните и обновите базу
- Сохраните конфигурацию.
- Выполните
Конфигурация → Обновить конфигурацию базы данных(клавишаF7). - Попросите пользователей перезапустить сеанс: изменения ролей уже открытый сеанс не подхватывает.
Сравнить права одного объекта во всех ролях сразу удобно через команду «Все роли» в контекстном меню ветки Роли. Откроется таблица «объекты × роли».
Справочники, документы и формы после включения независимых прав
Флажок сам по себе ничего не меняет для пользователя. Меняется то, какие права окажутся в роли после ваших действий. А уже права реквизитов видны в формах.
📋 Как платформа отрабатывает права реквизита в форме:
- 👁 нет права «Просмотр» — значение реквизита пользователю не показывается;
- ✏️ есть «Просмотр», нет «Редактирование» — поле видно, но изменить его нельзя;
- 📄 нет права на табличную часть — она недоступна целиком, вместе со строками.
Справочники
Классический пример — скрыть закупочную цену или контактные данные. Права справочника «Чтение» и «Просмотр» оставляют, у конкретного реквизита снимают «Просмотр». Карточка открывается, список работает, нужное поле скрыто.
Документы
Для документов сценарий обычно другой: запретить менять часть полей. Например, менеджер видит документ реализации, но не может править цену в табличной части. Оставляют «Изменение» на документ, снимают «Редактирование» у реквизита табличной части.
⚠️ Тонкое место документов — проведение. Если пользователь может провести документ , а реквизит закрыт для редактирования, движения сформируются по тому значению, которое уже стоит в документе. Права на реквизит не проверяются при программной записи из модуля, выполняемого в привилегированном режиме.
Отчёты и запросы
Права «Просмотр» и «Редактирование» реквизита интерактивные. Они управляют формами, но не запретом на чтение поля в запросе. Если поле нужно скрыть и в отчётах, одной настройки реквизита недостаточно — нужен механизм ограничения на уровне записей и полей, о нём ниже.
Проверка прав из кода
В собственных формах и обработках право на реквизит можно проверить функцией ПравоДоступа:
Если Не ПравоДоступа("Просмотр", Метаданные.Справочники.Номенклатура.Реквизиты.ЗакупочнаяЦена) Тогда
Элементы.ЗакупочнаяЦена.Видимость = Ложь;
КонецЕсли;
Так поступают, когда реквизит выводится не напрямую, а через реквизит формы или вычисляемое поле: платформа не знает, что это «та же» цена, и сама его не скроет.
Ролевая модель и RLS для подчиненных объектов
Права в ролях суммируются. Если у пользователя две роли и хотя бы одна даёт «Просмотр» реквизита, реквизит будет виден. Отсюда главное правило: чтобы скрыть поле, его должны закрывать все роли пользователя, а не одна.
Где в типовых конфигурациях назначаются роли
В конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) роли пользователю напрямую не назначают. Их собирают в профили групп доступа. В Бухгалтерии путь такой: Администрирование → Настройки пользователей и прав → Профили групп доступа.
Порядок работы:
- В конфигураторе (или расширении) создайте свою роль с нужными ограничениями реквизитов.
- Обновите конфигурацию базы данных.
- В режиме 1С:Предприятие создайте профиль — например, скопируйте типовой — и добавьте или замените в нём роль.
- Включите профиль в группу доступа пользователя.
RLS: ограничение на уровне полей
Ограничение доступа к данным (RLS) задаётся в роли для прав «Чтение», «Добавление», «Изменение», «Удаление» у объекта. В таблице условий есть колонка «Поля». По умолчанию там стоит <Прочие поля>, но можно добавить строку с конкретными полями и задать для них своё условие.
Это и есть способ скрыть данные реквизита не только в форме, но и в запросах: для отдельного поля задают условие, которое для этой роли не выполняется. Пользователь получит записи, но значение закрытого поля не увидит.
| Задача | Чем решать |
|---|---|
| Скрыть поле в карточке | Право «Просмотр» реквизита |
| Запретить менять поле | Право «Редактирование» реквизита |
| Скрыть значение поля и в отчётах | RLS с отдельной строкой для полей |
| Показать только «свои» записи | RLS на объект, в БСП — через группы доступа |
| Сохранить ручную настройку реквизитов при перенастройке объекта | Флажок «Независимые права подчиненных объектов» |
RLS заметно влияет на скорость запросов. Условия с полями усложняют их ещё больше. Проверяйте отчёты под реальным пользователем на рабочем объёме данных, а не под администратором.
Как проверить результат
Под администратором с ролью «Полные права» вы увидите всё — проверка ничего не скажет. Создайте тестового пользователя с тем же профилем и зайдите под ним. В конфигурациях на БСП в карточке пользователя есть отчёт по правам доступа: он показывает, какие роли и ограничения реально действуют.
Ошибки при работе с независимыми правами
Если не помогло
Когда права выглядят верными, а поведение странное, проверьте три вещи:
- 🔍 не выводится ли поле через реквизит формы или вычисляемое выражение — тогда его надо скрывать кодом через
ПравоДоступа; - 🔍 нет ли в расширениях конфигурации своих ролей, которые добавляют права;
- 🔍 не включён ли у пользователя профиль с ролью «Полные права» или аналогом.