Роль как объект конфигурации: что отражают роли в 1С и как их настраивать

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

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

Понимание того, что именно отражает роль как объект конфигурации, критично при доработке типовых решений и при расследовании ошибок вида «Нарушение прав доступа». Ниже разберём состав прав, связь с пользователями, ограничения RLS, типичные ошибки и способы проверки результата.

Что именно отражает роль как объект конфигурации

Роль хранится в конфигурации в ветке «Общие → Роли» и не содержит данных — только описание прав. Для каждого объекта метаданных (справочника, документа, регистра, отчёта, обработки, плана обмена и т.д.) в роли проставляются флажки прав: чтение, добавление, изменение, удаление, просмотр, интерактивное добавление, использование и другие, в зависимости от типа объекта.

Различие между «Изменение» и «Просмотр» важно: право «Просмотр» разрешает открывать формы объекта, а «Изменение» — сохранять изменения. Если дать «Изменение» без «Просмотр», пользователь сможет записывать объект программно, но не увидит его форму. Аналогично «Чтение» без «Просмотра» позволит получать данные запросами, но не открывать списки.

Кроме прав на объекты роль отражает права на корневые элементы конфигурации: доступ к административным функциям, толстого/тонкого клиента, веб-клиента, вывод, сохранение файла конфигурации и другие системные права. Они задаются на уровне корня дерева метаданных в окне редактирования роли.

Как роли связаны с пользователями информационной базы

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

В типовых решениях (1С:ERP, Бухгалтерия, ЗУП) прямое назначение ролей в конфигураторе не рекомендуется: там работает механизм профилей групп доступа. Профиль — это набор ролей, собранный в режиме предприятия без изменения конфигурации. Пользователь включается в группу доступа, и роли назначаются ему автоматически.

Ключевое правило: права суммируются по принципу «разрешающего объединения». Если хотя бы одна роль даёт право, оно есть у пользователя. Запретить действие, разрешённое другой ролью, нельзя — только снять лишнюю роль. Исключение — ограничения RLS, которые дополнительно фильтруют данные даже при наличии права чтения.

Состав прав: что можно разрешить и запретить

Набор доступных прав зависит от типа объекта. Для справочников и документов это чтение, добавление, изменение, удаление и их интерактивные аналоги. Для регистров — чтение, изменение, просмотр, итоги (для регистров накопления и бухгалтерии). Для отчётов и обработок — использование и просмотр. Для планов обмена — чтение, изменение, использование.

Интерактивные и неинтерактивные права

Пары «Добавление» / «Интерактивное добавление» разделяют программный и пользовательский сценарии. Если оставить только неинтерактивное право, объект можно создавать из кода (например, обработкой загрузки), но кнопка «Создать» в интерфейсе будет недоступна. Это удобно, когда документы должны формироваться только автоматически.

Права на корень конфигурации

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

Ограничение доступа к данным (RLS) в ролях

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

RLS настраивается в редакторе роли на закладке «Шаблоны ограничений» и в поле «Ограничение доступа» для конкретного права. Условие может ссылаться на параметры сеанса (текущий пользователь, его подразделение) и на значения дополнительных свойств объектов. В типовых конфигурациях механизм RLS тесно связан с группами доступа контрагентов, номенклатуры и организаций.

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

Как создать и настроить собственную роль

Новая роль создаётся в конфигураторе: в дереве конфигурации откройте «Общие → Роли», добавьте новый объект и задайте имя и синоним. Затем в редакторе роли пройдите по дереву метаданных и отметьте нужные права. Для ускорения используйте кнопки установки прав по подсистемам или скопируйте права из существующей роли через «Установить по роли».

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

1. 1
   Создайте копию рабочей базы или используйте тестовую
2. 2
   В конфигураторе добавьте роль: Общие → Роли → Добавить
3. 3
   Отметьте права на нужные объекты, при необходимости задайте RLS
4. 4
   Обновите конфигурацию базы данных (F7)
5. 5
   Назначьте роль тестовому пользователю или добавьте в профиль доступа
6. 6
   Войдите под тестовым пользователем и проверьте доступные операции
7. 7
   Проверьте, что запрещённые действия действительно недоступны
8. 8
   Перенесите изменения в рабочую базу в нерабочее время

Типовые и собственные роли: что выбрать

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

Практичный подход: не изменять типовые роли, а создавать дополняющие. Нужно расширить права — добавьте свою роль с недостающими правами. Нужно сузить — соберите профиль из более «мелких» типовых ролей, исключив лишние. Прямое редактирование типовой роли оправдано только при полном снятии конфигурации с поддержки, что само по себе требует взвешенного решения.

Сравнение вариантов

Изменение типовой роли

Быстро, но правки могут быть потеряны при обновлении; подходит только для снятых с поддержки конфигураций

Собственная дополняющая роль

Безопасно при обновлениях; требует ручного добавления прав на новые объекты

Профили групп доступа (БСП)

Настройка без конфигуратора, гибкое сочетание ролей; работает только в конфигурациях на БСП

Расширение конфигурации

Роли добавляются без изменения основной конфигурации; удобно для обновляемых типовых решений

Типичные ошибки и проверка результата

Самая частая жалоба — «Нарушение прав доступа» при проведении документа. Причина почти всегда в том, что документ при проведении пишет данные в регистры, а роль даёт права только на сам документ. Нужно выдать права на все регистры, по которым документ делает движения, и на связанные объекты (например, последовательности, задачи).

Вторая группа ошибок — избыточные права. Выдача роли «Полные права» пользователю «на время» часто становится постоянной и приводит к случайному удалению данных, изменению настроек учёта и невозможности установить автора ошибки. Минимально необходимый набор ролей — базовый принцип безопасной модели доступа.

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

Контрольные точки

Как проверить результат

Вход под пользователем

Норма

База открывается, нужные разделы видны

Тревожный признак

Пустой интерфейс или ошибка прав при входе

Создание и проведение документа

Норма

Документ записывается и проводится без сообщений

Тревожный признак

«Нарушение прав доступа» с указанием регистра

Построение отчёта

Норма

Отчёт формируется и показывает только разрешённые данные

Тревожный признак

Пустой отчёт или данные чужих подразделений

Запрещённые операции

Норма

Кнопки недоступны, попытка действия блокируется

Тревожный признак

Пользователь удаляет или изменяет то, что не должен

При расследовании ошибки «Нарушение прав доступа» смотрите на объект, указанный в сообщении, а не на тот, с которым работает пользователь. Чаще всего не хватает прав не на документ, а на регистр, справочник валют или константу, к которым обращается код проведения.

FAQ

Чем роль отличается от профиля группы доступа?

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

Почему пользователь с двумя ролями не видит объект, хотя в одной роли право есть?

Права объединяются по принципу «разрешено, если разрешено хотя бы одной ролью», поэтому причина обычно не в конфликте ролей, а в нехватке связанного права: например, есть «Чтение», но нет «Просмотра», либо срабатывает ограничение RLS, скрывающее конкретные записи.

Можно ли запретить действие, разрешённое другой ролью?

Нет, механизма запрещающих прав в платформе нет. Единственный способ сузить доступ — снять лишнюю роль или пересобрать профиль доступа из более мелких ролей. Дополнительно ограничить видимость записей можно через RLS.

Что будет с правами при обновлении типовой конфигурации?

Типовые роли будут приведены к виду поставщика — ваши правки в них могут быть потеряны или потребуют ручного объединения. Собственные роли при обновлении не изменяются, но новые объекты конфигурации получат права только если вы добавите их в свои роли вручную.

Как быстро узнать, какие роли дают право на конкретный объект?

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

Опасно ли давать право «Администрирование» обычному пользователю?

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