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