Создание роли и прав доступа в Конфигураторе 1С 8.3

Роль в 1С создаётся в Конфигураторе: ветка дерева конфигурации Общие → Роли, правой кнопкой Добавить. В открывшемся редакторе вы отмечаете галочками права на объекты (справочники, документы, отчёты) и при необходимости задаёте условие RLS — ограничение доступа к конкретным записям. Готовую роль потом назначают пользователю в списке Администрирование → Пользователи.

Прежде чем лезть в Конфигуратор, стоит решить, нужна ли вообще новая роль. В типовых конфигурациях на управляемых формах (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) права чаще раздают через профили групп доступа прямо в режиме 1С:Предприятие — без правки конфигурации. Собственная роль в Конфигураторе требуется, когда готовых прав не хватает или вы ведёте самописную конфигурацию. Ниже — оба пути и то, как не ошибиться с выбором.

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

Роль — это объект конфигурации. Она описывает, что пользователь может делать с объектами метаданных: читать справочник, проводить документ, открывать отчёт, выполнять регламентное задание. Роль хранится внутри конфигурации, и чтобы её изменить, нужен Конфигуратор и снятие конфигурации с поддержки или расширение.

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

Простое правило выбора:

Где в Конфигураторе создают роли

Откройте базу в режиме Конфигуратор. Для правки состава ролей Конфигуратору нужен монопольный доступ только в момент обновления структуры базы данных — то есть при сохранении изменений конфигурации. Сам ввод прав можно готовить и без выгона пользователей, но принять изменения (Обновить конфигурацию базы данных, F7) получится, когда база свободна.

Дальше:

1. Откройте дерево конфигурации: Конфигурация → Открыть конфигурацию.
2. Разверните ветку Общие, внутри найдите узел Роли.
3. Правой кнопкой по Роли → Добавить. Появится новая роль и сразу откроется окно редактора прав.
4. В палитре свойств (F4) задайте имя роли латиницей без пробелов, например РасширенныйМенеджер. Синоним (имя, которое увидит пользователь) впишите по-русски — «Расширенный менеджер».

Окно редактора ролей делится на две части. Слева — дерево всех объектов метаданных, от корня конфигурации до каждого справочника и документа. Справа — список прав, которые доступны для выделенного слева объекта. Внизу прячется поле ограничения доступа к данным, о нём речь в разделе про RLS.

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

Как отметить права на объекты метаданных

Набор прав зависит от того, что выделено слева. Для корня конфигурации доступны «глобальные» права — они не относятся к конкретному справочнику:

• 🔧 Администрирование — полный административный доступ;
• 🗂 Администрирование данных — выгрузка/загрузка, тестирование и исправление;
• 🧩 Обновление конфигурации базы данных — право принимать изменения конфигурации;
• 🔒 Монопольный режим — запуск базы монопольно;
• 👤 Активные пользователи, Журнал регистрации и другие сервисные права;
• ▶️ Вывод — разрешение печати, сохранения и копирования данных.

Для справочника, документа или регистра набор другой. Основные права:

Для каждого объекта проще всего встать на него, нажать правой кнопкой Установить все права или снять все, а потом точечно подправить. Отдельно отметьте две галочки под списком прав:

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

Готовые роли и сборка составной роли

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

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

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

Если нужна роль, похожая на существующую, скопируйте её: встаньте на роль в дереве и нажмите Ctrl+C, затем Ctrl+V. Появится копия, которую останется переименовать и подправить.

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

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

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

Права на объект разрешают или запрещают работу со справочником целиком. Чтобы менеджер видел документы только своего склада, а не всей базы, нужен RLS — ограничение доступа на уровне записей (Record Level Security).

RLS задаётся для конкретного права (Чтение, Добавление, Изменение, Удаление) в нижней части окна роли:

1. Выделите слева объект, например документ РеализацияТоваровУслуг.
2. Справа встаньте на право Чтение.
3. Внизу в поле Ограничения доступа к данным нажмите кнопку добавления строки.
4. В поле Поля выберите реквизиты, к которым применяется условие (или Прочие поля).
5. В поле Ограничение доступа откройте конструктор и напишите условие на языке запросов.

Условие — это фрагмент запроса, который должен вернуть истину для доступных записей. Пример для фильтра по складу:

ГДЕ Склад В
    (ВЫБРАТЬ Склад ИЗ РегистрСведений.НастройкиПользователей
     ГДЕ Пользователь = &ТекущийПользователь)

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

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

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

Как назначить роль пользователю базы

Роль без назначения ничего не делает. Привязать её к пользователю можно двумя путями.

Через Конфигуратор (для любых конфигураций):

1. Администрирование → Пользователи.
2. Откройте карточку пользователя или создайте нового кнопкой добавления.
3. На вкладке Прочие в списке Доступные роли отметьте галочками нужные роли.
4. Нажмите OK.

Через режим 1С:Предприятие (в типовых решениях) роли отдельно обычно не раздают — пользователя включают в группу доступа с нужным профилем:

1. Администрирование → Настройки пользователей и прав → Пользователи.
2. Откройте карточку сотрудника, перейдите по ссылке Права доступа.
3. Отметьте профили групп доступа — за ними уже стоят роли из Конфигуратора.

Пользователь с правом Администрирование видит и может всё независимо от других ролей — назначайте его только тем, кому действительно нужен полный доступ.

Как проверить, что права работают

Отмеченные галочки — это ещё не гарантия. Доступ проверяют под реальным пользователем, а не из-под администратора.

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

Что обычно всплывает при проверке:

• 🚫 «Нарушение прав доступа» при открытии формы — не хватает Просмотра или Чтения у объекта либо у его реквизита;
• 🙈 документ или команда вовсе не видны в интерфейсе — нет интерактивного права (Просмотр, Редактирование) или команда скрыта функциональными опциями;
• 📉 видны не все записи — так и задумано, если на объект стоит RLS; проверьте условие и настройки пользователя, от которых оно зависит.

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

Частые вопросы