Базовые права в 1С 8.3: что это и как с ними работать

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

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

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

Что такое роли и как из них складываются права

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

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

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

Из чего состоит минимальный набор прав для входа в систему

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

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

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

Где назначаются права: карточка пользователя и группы доступа

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

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

Порядок действий при подключении нового сотрудника выглядит так:

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

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

Как проверить, что права настроены правильно

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

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

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

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

Вход в систему

Норма

Пользователь входит без ошибок, видит рабочий стол

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

Сообщение о невозможности запуска клиента или пустой интерфейс

Работа с документами

Норма

Нужные документы создаются, проводятся, отчёты открываются

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

Ошибка «нарушение прав доступа» при типовых операциях

Избыточный доступ

Норма

Непрофильные разделы скрыты или доступны только на чтение

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

Пользователь может изменять данные, не относящиеся к его обязанностям

Типичные ошибки при работе с базовыми правами

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

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

Ограничения и особенности механизма

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

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

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

Чем базовые права отличаются от полных прав?

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

Почему новый пользователь не может войти в базу?

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

Нужно ли перезапускать сеанс после изменения ролей?

Да. Права применяются при входе пользователя в систему. Если сеанс был открыт до изменения ролей, старые права продолжают действовать, пока пользователь не выйдет и не войдёт снова.

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

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

Где посмотреть, какие права реально действуют у пользователя?

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

Что делать, если типовых профилей не хватает?

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