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