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