Как назначать права в 1С

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

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

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

Как устроены права в 1С: роли, профили, группы доступа

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

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

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

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

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

Перейдите в Профили групп доступа. Здесь уже есть поставляемые профили: «Администратор», «Менеджер по продажам», «Бухгалтер» и другие. Рекомендуется не менять типовые профили, а копировать их: создайте копию, дайте понятное имя («Менеджер по продажам — только просмотр цен») и скорректируйте состав ролей на закладке «Роли».

Затем откройте Группы доступа, создайте новую группу, укажите профиль и добавьте пользователей на закладке «Участники». Изменения вступают в силу после перезапуска сеанса пользователя — действующие сеансы права не обновляют автоматически.

1. 1
   Откройте Администрирование → Настройки прав и пользователей → Профили групп доступа
2. 2
   Скопируйте подходящий типовой профиль и переименуйте копию
3. 3
   На закладке «Роли» отметьте нужные роли и снимите лишние
4. 4
   Создайте группу доступа и укажите в ней этот профиль
5. 5
   Добавьте пользователей в участники группы
6. 6
   Попросите пользователя перезайти в базу и проверьте результат под его учётной записью

Назначение ролей напрямую пользователю

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

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

Настройка ролей в конфигураторе

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

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

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

Ограничение доступа на уровне записей (RLS)

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

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

Способы назначения прав

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

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

Роли напрямую пользователю

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

Доработка ролей в конфигураторе

Когда типовых ролей не хватает. Максимальная гибкость, но усложняет обновления и требует тестирования на копии.

RLS

Когда нужно разграничить записи внутри одного объекта: организации, склады, подразделения. Цена — дополнительная нагрузка и сложность диагностики.

Проверка результата и типичные ошибки

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

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

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

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

Видимость объекта

Норма

Документ или отчёт открывается и отображается в интерфейсе

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

Объект не виден в меню или ошибка «Нарушение прав доступа» при открытии

Доступ к записям

Норма

Пользователь видит записи только разрешённых организаций/складов

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

Видны чужие записи или пропали свои — проверьте ограничения в группе доступа

Итоговый состав прав

Норма

Отчёт по правам показывает только запланированные роли

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

Присутствуют лишние роли из другой группы доступа, о которой забыли

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

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

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

Как дать право только на просмотр без изменения?

В профиле оставьте роли чтения и просмотра объекта, снимите роли добавления и изменения. При настройке роли в конфигураторе снимите права «Добавление», «Изменение», «Удаление» и «Проведение», оставив «Чтение» и «Просмотр».

Пользователь состоит в двух группах с разными профилями — какие права у него будут?

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

Можно ли скопировать права одного пользователя другому?

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

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

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

Кто может назначать права в 1С?

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