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