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