Как редактировать роли в 1С

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

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

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

Где именно редактируются роли: конфигуратор или режим предприятия

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

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

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

Редактирование роли в конфигураторе: базовая последовательность

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

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

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

После правки обязательно выполните обновление конфигурации базы данных (клавиша F7 или «Конфигурация → Обновить конфигурацию базы данных»). Без этого изменения останутся только в конфигурации разработчика и на работающих пользователей не повлияют. В клиент-серверном режиме пользователям потребуется перезайти в сеанс.

Настройка прав на уровне записей (RLS)

RLS (Record Level Security) ограничивает не сами объекты, а конкретные записи: например, менеджер видит только документы своей организации. В редакторе роли для нужного права (обычно «Чтение») в поле «Ограничение доступа» задаётся запрос на встроенном языке, который фильтрует данные.

Типовой приём — использовать шаблоны ограничений (ветка «Общие → Шаблоны ограничений»). В шаблоне описывается условие с параметрами, например #Параметр(1), а в роли этот шаблон подставляется с конкретным значением — ссылкой на организацию, склад или контрагента из параметров сеанса. Это позволяет использовать один шаблон в десятках ролей и править логику в одном месте.

Пример простого ограничения по организации в запросе RLS:

Документ.РеализацияТоваровУслуг ГДЕ РеализацияТоваровУслуг.Организация = &ТекущаяОрганизация

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

Редактирование прав через профили групп доступа

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

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

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

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

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

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

Типичные ошибки и ограничения

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

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

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

Когда редактирование ролей лучше доверить специалисту

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

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