Администрирование · 12 мин
Группы доступа в 1С: что это такое и как их настроить
Что такое группы доступа в 1С, чем отличаются профили и группы доступа, как настроить права пользователей и ограничение доступа на уровне записей.
Группы доступа в 1С — это механизм разграничения прав пользователей, который определяет, какие объекты информационной базы (документы, справочники, отчёты) конкретный сотрудник может видеть, создавать, изменять или удалять. Механизм работает поверх стандартных ролей и позволяет гибко управлять доступом без доработки конфигурации: например, менеджер по продажам видит только своих контрагентов, а кладовщик — только свой склад.
Термин «группы доступа» используется в двух связанных смыслах. Во-первых, это профили групп доступа — наборы разрешённых ролей и действий, назначаемые пользователям. Во-вторых, это группы доступа объектов — способ ограничить видимость конкретных записей (контрагентов, складов, организаций) через механизм RLS — ограничение доступа на уровне записей. В типовых конфигурациях на платформе 1С:Предприятие 8.3 оба механизма работают совместно.
Настройка выполняется в разделе «Администрирование» → «Настройки прав и пользователей». Для корректной работы нужно понимать иерархию: роль задаёт базовые возможности, профиль объединяет роли в осмысленный набор, а группа доступа привязывает профиль к конкретному пользователю и при необходимости ограничивает состав видимых данных. Ниже разобраны все уровни и практические сценарии настройки.
Из чего состоит система прав в 1С
Модель доступа в типовых конфигурациях 1С (Бухгалтерия предприятия, Управление торговлей, Зарплата и управление персоналом, ERP) строится на трёх уровнях. Первый уровень — роли. Роль определяет права на объекты метаданных: чтение, добавление, изменение, удаление конкретного вида документов или справочников. Роли назначаются пользователю в конфигураторе или через профили в режиме предприятия.
Второй уровень — профили групп доступа. Это типовые или самостоятельно созданные наборы ролей, оформленные как элемент справочника. Например, профиль «Менеджер по продажам» включает роли для работы с заказами, счетами и отчётами по продажам, но не даёт доступа к кассовым документам и регламентированной отчётности.
Третий уровень — группы доступа как связка «пользователь + профиль + разрешённые значения». Именно здесь задаётся, к каким организациям, складам, подразделениям или контрагентам допущен сотрудник. Один пользователь может входить в несколько групп доступа — тогда действует объединение разрешений.
Чем профиль отличается от группы доступа
Путаница между профилем и группой доступа — самая частая причина ошибок в настройке. Профиль отвечает на вопрос «что можно делать», группа доступа — «кому и к каким данным это применяется». Профиль одинаков для всех менеджеров, а групп доступа может быть несколько: «Менеджеры — розница», «Менеджеры — опт», и у каждой свой список разрешённых складов и контрагентов.
На практике это выглядит так: создаётся один профиль «Менеджер по продажам», затем две группы доступа с этим профилем. В первой группе в разрешённые значения добавлен склад «Розничный», во второй — склады «Оптовый» и «Резерв». Сотрудники розницы физически не увидят документы оптового склада в списках и отчётах, даже если попытаются открыть их по ссылке.
Сравнение вариантов
Низкоуровневые права на объекты метаданных. Назначается в конфигураторе или через профиль. Самостоятельно не ограничивает видимость записей.
Именованный набор ролей для типовой должности. Удобен для массового назначения, но без групп доступа не ограничивает конкретные данные.
Связывает пользователей с профилем и задаёт разрешённые значения (организации, склады, контрагенты). Основной инструмент тонкой настройки.
Как включить и настроить группы доступа
Перед началом работы убедитесь, что в программе включён сам механизм. Откройте «Администрирование» → «Настройки прав и пользователей» и установите флажок «Группы доступа» (в ряде конфигураций также есть отдельный флажок «Ограничивать доступ на уровне записей»). Без включённого ограничения на уровне записей разрешённые значения в группах работать не будут — пользователи увидят все данные.
Далее создайте профиль: перейдите в «Профили групп доступа», добавьте новый элемент, укажите наименование и отметьте разрешённые роли. В типовых конфигурациях есть готовые поставляемые профили — их можно копировать и корректировать под свои задачи, не собирая набор ролей с нуля.
После этого создайте группу доступа, выберите в ней профиль, добавьте пользователей и заполните таблицу разрешённых значений: организации, склады, подразделения, группы контрагентов. Состав доступных видов ограничений зависит от конфигурации и настроек функциональных опций.
- 1Включите флажки «Группы доступа» и «Ограничивать доступ на уровне записей» в настройках прав
- 2Создайте или скопируйте профиль и отметьте нужные роли
- 3Создайте группу доступа, укажите профиль и добавьте пользователей
- 4Заполните разрешённые значения: организации, склады, подразделения
- 5Зайдите под тестовым пользователем и проверьте видимость данных
Ограничение доступа на уровне записей (RLS)
RLS — ключевая часть механизма групп доступа. Когда пользователь открывает список документов или формирует отчёт, платформа автоматически добавляет к запросу условие: показывать только записи, где значение реквизита (организация, склад, контрагент) входит в разрешённый список. Пользователь не видит лишнего ни в списках, ни в отчётах, ни при подборе в документы.
Важно понимать ограничения. RLS работает только для видов объектов, для которых в конфигурации предусмотрены шаблоны ограничений. Если в конфигурации нет ограничения по какому-то реквизиту (например, по статьям расходов), разрешённые значения этого вида в группе доступа не появятся. Кроме того, RLS заметно усложняет запросы: на больших базах с десятками групп доступа возможно замедление открытия списков и построения отчётов.
Ещё один нюанс — значение «все разрешены». Если для пользователя по конкретному виду доступа не задано ни одной группы с ограничением, поведение зависит от настройки: либо доступ разрешён ко всем значениям, либо запрещён полностью. Проверяйте этот момент на тестовом пользователе, особенно после добавления новых видов доступа.
Типичные сценарии настройки
Разделение по организациям
В многофирменной базе каждой бухгалтерской команде назначается своя группа доступа с разрешённой организацией. Главный бухгалтер включается во все группы либо получает профиль без ограничений. В результате оборотно-сальдовая ведомость у рядового бухгалтера строится только по его организации без ручных отборов.
Разделение по складам
Кладовщикам назначаются группы доступа с конкретными складами. Они оформляют приходные и расходные ордера только по своему складу, а попытка провести документ по чужому складу завершится ошибкой проверки прав. Менеджеру по закупкам при этом можно дать профиль с просмотром остатков по всем складам без права изменения.
Разделение по контрагентам
В торговых конфигурациях менеджеру можно ограничить список видимых контрагентов через группы контрагентов или индивидуальный список. Это защищает клиентскую базу: уволившийся менеджер не выгрузит полный список клиентов, если доступ был корректно ограничен заранее.
Как выбрать действие
Проверка результата и типичные ошибки
После настройки обязательно проверьте права от имени реального пользователя: заведите тестовую учётную запись, включите её в нужную группу и войдите в базу. Откройте списки документов, сформируйте ключевой отчёт, попробуйте создать документ по запрещённому складу или организации — система должна либо скрыть данные, либо выдать сообщение о нарушении прав.
Для диагностики используйте отчёт «Анализ прав доступа» (в типовых конфигурациях доступен в разделе администрирования): он показывает, какие роли и ограничения фактически действуют для выбранного пользователя и откуда они взялись. Это самый быстрый способ найти лишнюю группу доступа, которая открывает лишние данные.
Как проверить результат
Видны только документы разрешённых организаций и складов
Отображаются документы чужих подразделений
Данные отфильтрованы по разрешённым значениям автоматически
Отчёт показывает всю базу без отборов
Система выдаёт сообщение о нарушении прав
Документ проводится без предупреждений
Состав ролей и ограничений соответствует задуманному
Есть лишние группы или роли, источник которых непонятен
Производительность и обслуживание
Каждое ограничение RLS добавляет условия в запросы платформы. На небольших базах это незаметно, но при сотнях пользователей и десятках групп доступа с множеством разрешённых значений списки документов могут открываться медленнее. Симптом — рост времени выполнения запросов к таблицам документов и регистров именно у пользователей с ограниченными правами, тогда как у полноправных всё работает быстро.
Снизить нагрузку помогают простые меры: не создавайте отдельную группу доступа на каждого сотрудника, объединяйте пользователей с одинаковыми правами; следите за количеством разрешённых значений в одной группе; регулярно удаляйте группы уволенных сотрудников и неиспользуемые профили. Раз в квартал полезно проводить ревизию прав: выгрузить список пользователей с их группами и сверить с актуальным штатным расписанием.
Удобный приём — называть группы доступа по шаблону «Должность — участок», например «Менеджер — опт» или «Бухгалтер — ИП Сидоров». Через полгода такой подход избавит от вопроса, зачем нужна та или иная группа, и упростит ревизию прав.
Часто задаваемые вопросы
Чем группы доступа отличаются от ролей в конфигураторе?
Роли задаются разработчиком в конфигураторе и определяют права на объекты метаданных. Группы доступа настраиваются администратором в режиме «Предприятие» без изменения конфигурации и позволяют дополнительно ограничить видимость конкретных записей — организаций, складов, контрагентов.
Почему пользователь видит все данные, хотя группа доступа настроена?
Чаще всего не включён флажок «Ограничивать доступ на уровне записей» в настройках прав, либо пользователь состоит ещё в одной группе без ограничений — разрешения от разных групп суммируются. Проверить фактический состав прав помогает отчёт «Анализ прав доступа».
Можно ли ограничить доступ к отдельным документам, а не к целому виду?
Стандартный механизм групп доступа ограничивает записи по значениям реквизитов (организация, склад, контрагент), а не отдельные документы. Для точечных запретов потребуется доработка конфигурации или использование дат запрета изменения данных.
Что произойдёт, если удалить группу доступа, в которой есть пользователи?
Пользователи потеряют права, которые давала эта группа. Если других групп у них нет, они могут полностью лишиться доступа к нужным разделам программы. Перед удалением проверьте состав участников и при необходимости переведите их в другую группу.
Работают ли группы доступа во внешних отчётах и обработках?
RLS применяется на уровне запросов платформы, поэтому внешние отчёты, построенные запросами к базе, обычно подчиняются ограничениям. Однако обработки, читающие данные напрямую с обходом стандартных механизмов, могут игнорировать ограничения — такие разработки нужно проверять отдельно.
Нужно ли перезапускать сеанс пользователя после изменения группы доступа?
Изменения в группах доступа обычно применяются без перезапуска, но уже открытые формы могут работать со старыми отборами. Надёжнее попросить пользователя закрыть и заново открыть списки, а при смене профиля — перезайти в программу.
Что важно запомнить
Группы доступа связывают пользователей, профили (наборы ролей) и разрешённые значения данных. Работают вместе с RLS, который фильтрует записи на уровне запросов. Настройку всегда проверяйте под тестовой учётной записью и помните: разрешения от нескольких групп суммируются.