Настраиваем роли и права пользователей в 1С 8.3

Роли в 1С создаются в конфигураторе — в ветке дерева метаданных Общие → Роли. Роль хранит набор прав: что пользователь может читать, добавлять, изменять, удалять и проводить. Права назначенных пользователю ролей складываются по «ИЛИ»: если хотя бы одна роль даёт право — оно у пользователя есть, «запрещающей» роли в 1С не существует.

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

Что такое роль и как она связана с правами

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

• 📖 Чтение — видеть данные.
• ➕ Добавление и Изменение — создавать и править.
• 🗑️ Удаление — удалять, в том числе интерактивно.
• ✅ Проведение и Отмена проведения — для документов.
• 👁️ Просмотр и Редактирование — интерактивные права, работают только поверх «Чтения» и «Изменения».

Отдельно стоят права на корень конфигурации: запуск тонкого, веб- и толстого клиента, Администрирование, монопольный режим, работа с журналом регистрации. Без права запуска нужного клиента пользователь просто не войдёт в базу.

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

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

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

Главное правило для типовых баз: не правьте роли прямо в конфигураторе типовой конфигурации. Это снимает её с поддержки и ломает автоматическое обновление . Свою роль добавляют в расширении (механизм доступен с платформы 8.3.6) — типовая остаётся нетронутой.

Создание роли в конфигураторе: по шагам

Этот путь нужен для своих конфигураций или для роли внутри расширения. Порядок действий одинаковый.

1. Откройте конфигуратор и саму конфигурацию: Конфигурация → Открыть конфигурацию.
2. В дереве метаданных найдите ветку Общие → Роли, правый клик → Добавить (или клавиша Ins).
3. Задайте Имя роли латиницей (например, МенеджерПродаж) и Синоним — то, что увидят в списке.
4. Откроется редактор роли с двумя закладками: Права и Шаблоны ограничений. На закладке «Права» слева — дерево объектов, справа — флажки прав.
5. Начните с корня конфигурации: отметьте право на запуск нужного клиента (тонкий, веб, толстый). Без него роль бесполезна.
6. Пройдите по справочникам, документам, регистрам и отметьте нужные права. Для документов не забудьте Проведение, если сотрудник должен проводить.
7. Решите, как вести себя флажку «Устанавливать права для новых объектов». Для администраторской роли его включают, для ограниченной — выключают, иначе новые объекты конфигурации автоматически станут доступны.
8. Закройте редактор и выполните Конфигурация → Обновить конфигурацию базы данных (F7).

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

Роли через профили групп доступа в типовых базах

В типовых конфигурациях на библиотеке стандартных подсистем права раздают не ролями, а профилями. Путь: Администрирование → Настройки пользователей и прав → Группы доступа.

Здесь работают три сущности:

• 👤 Профиль групп доступа — именованный набор ролей (например, «Бухгалтер», «Только просмотр»). По сути это обёртка над ролями конфигурации.
• 🧑‍🤝‍🧑 Группа доступа — связка «профиль + конкретные пользователи + разрешённые значения».
• 🔑 Пользователь — попадает в одну или несколько групп и получает сумму их прав.

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

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

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

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

Ограничение доступа по организациям и подразделениям

Разграничение по организации, складу или подразделению — это ограничение на уровне записей (RLS, Row Level Security). Пользователь с правом «Чтение» на документы видит не все документы, а только по разрешённым ему значениям.

В типовых базах это настраивается без кода. Ограничение строится на видах доступа — организации, склады, группы контрагентов, физлица — и на значениях, которые разрешены конкретной группе.

1. В разделе Администрирование → Настройки пользователей и прав включите флажок «Ограничивать доступ на уровне записей».
2. В группе доступа на закладке со значениями доступа укажите, какие организации (склады, подразделения) разрешены её участникам.
3. Сохраните — пользователи группы увидят документы только по этим значениям.

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

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

ГДЕ Организация В (&ДоступныеОрганизации)

Параметр &ДоступныеОрганизации заполняют при старте сеанса в модуле. Шаблоны повторяющихся условий выносят на закладку «Шаблоны ограничений», чтобы не дублировать текст в каждой роли.

Типичные ошибки при настройке ролей

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

• 🔓 Широкая роль перекрывает узкую. Условия RLS из разных ролей объединяются по «ИЛИ». Если у пользователя рядом с ограниченной ролью висит роль без ограничения — он увидит всё. Проверяйте весь набор ролей, а не одну.
• ❌ Пытаются «отнять» право второй ролью. Так не работает : права складываются. Лишнее убирают из набора ролей, а не добавляют «запрещающую».
• 🆕 Забыли про флажок новых объектов. У ограниченной роли включённое «Устанавливать права для новых объектов» со временем откроет доступ к тому, что добавили позже.
• 🖨️ Отключили «Чтение», оставив «Просмотр». Интерактивные права (Просмотр, Редактирование) не работают без базовых (Чтение, Изменение) — пользователь получит отказ.
• 🛠️ Правят типовую роль напрямую. База слетает с поддержки, следующее обновление прилетает с конфликтами. Выход — расширение.

Роли в распределённых базах (РИБ)

В старой 1С 7.7 этот механизм назывался УРБД (управление распределёнными базами данных), иногда его сокращали как УРИБ. В 1С 8.3 это распределённые информационные базы (РИБ), и настраиваются они через планы обмена.

Как ведут себя роли в РИБ:

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

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

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

Контроль и аудит прав пользователей

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

Что помогает контролировать доступ:

• 📋 В типовых базах — отчёт по правам доступа в разделе настроек пользователей и прав: показывает, кто в какой группе и что может.
• 🕵️ Журнал регистрации (Администрирование → Журнал регистрации) фиксирует действия пользователей. Что именно логировать, настраивают в конфигураторе: Администрирование → Настройка журнала регистрации.
• 👁️ Список активных пользователей покажет, кто в базе прямо сейчас.

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