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