Роль в 1С: что это такое и как настроить права доступа

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

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

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

Где хранятся роли и из чего они состоят

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

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

Кроме прав на объекты, роль может включать права на доступ к данным на уровне записей — механизм RLS (Record Level Security). Например, менеджер видит только документы своей организации, хотя формально право чтения документа у него есть. Ограничения RLS задаются текстом запроса на языке ограничений доступа и существенно влияют на производительность, поэтому их используют осознанно.

Типовые роли и как их читать

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

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

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

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

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

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

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

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

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

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

Как проверить, какие права реально есть у пользователя

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

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

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

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

Вход пользователя в базу

Норма

Сеанс запускается, открывается начальная страница без ошибок доступа

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

Ошибка нарушения прав уже при входе — не хватает базовых ролей подсистемы

Рабочий сценарий целиком

Норма

Документ создаётся, проводится, печатается, отчёт строится

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

Ошибка на отдельном шаге — не хватает права на связанный регистр или печатную форму

Доступ к чужим данным

Норма

Пользователь видит только свои разделы и организации

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

Видны лишние документы — назначена избыточная роль или неверно настроен RLS

Отличия ролей от профилей групп доступа

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

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

Роли или профили групп доступа

Прямое назначение ролей

Подходит для простых и самописных конфигураций без БСП. Требует доступа к списку пользователей и понимания состава ролей.

Профили групп доступа

Стандарт для типовых конфигураций на БСП. Администратор управляет правами без конфигуратора, настройки переживают обновления.

Собственная роль в конфигураторе

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

Частые вопросы о ролях в 1С

Можно ли назначить пользователю несколько ролей?

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

Пользователь получает «Нарушение прав доступа», хотя роль назначена. Что проверить?

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

Чем «Полные права» отличаются от «Администратор системы»?

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

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

Роли, созданные вами как отдельные объекты, при обновлении сохраняются. А вот изменения, внесённые внутрь типовых ролей, будут затёрты поставщиком — именно поэтому доработку прав делают через новые роли или через профили групп доступа, а не правкой типовых.

Можно ли ограничить доступ к конкретным документам, а не к виду документов целиком?

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

Как узнать, какая типовая роль даёт нужное право?

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