← На главную

Нередко перед разработчиком или администратором базы данных возникает задача: предоставить конкретному пользователю доступ только к нескольким объектам (например, к документам реализации товаров и счетам-фактурам), ограничив все остальные функции. При этом ключевое требование заказчика или бухгалтерии — не снимать типовую конфигурацию с поддержки, чтобы не нарушить процесс автоматического обновления. Разберем технические нюансы решения этой задачи, выясним ограничения платформы 1С:Предприятие 8.2 и рассмотрим по шагам правильный алгоритм настройки прав.

Технические ограничения платформы 8.2 и возможность создания роли

Проанализируем архитектурную особенность платформы: роль является объектом метаданных. Любые манипуляции со списком ролей (создание, удаление, редактирование прав на уровне объектов) в версиях платформы 8.2 физически невозможно выполнить из пользовательского режима или с помощью внешних обработок. Механизм расширений конфигурации появился только в версии 8.3.6 и стал полноценно поддерживать добавление ролей еще позже. Таким образом, добавить новую роль в конфигурацию без перевода ее в режим редактирования технически нельзя.

Рассмотрим, как изменение режима поддержки влияет на типовое автоматическое обновление в конфигурации «Бухгалтерия предприятия 2.0»:

1. Штатный механизм автоматического обновления в режиме «1С:Предприятие» жестко требует, чтобы конфигурация находилась на полной поддержке («на замке»).
2. Как только в конфигураторе включается режим «Редактируется с сохранением поддержки», типовой мастер автообновления блокирует обновление через пользовательский интерфейс.
3. Добавление новой роли не ломает структуру данных, но обновлять такую информационную базу в дальнейшем придется через Конфигуратор путем сравнения и объединения с файлом обновления (дистрибутивом .cfu или файлом конфигурации .cf).

Альтернативные варианты решения без изменения конфигурации

Если для заказчика сохранение штатного автоматического обновления критично, рассмотрим обходные пути решения задачи на типовом функционале:

1. Создание АРМ во внешней обработке. Мы можем назначить пользователю типовые права, но сделать точкой входа внешнюю обработку (автоматизированное рабочее место). В обработке создаются упрощенные формы журналов документов РеализацияТоваровУслуг и СчетФактураВыданный. Вся оперативная работа ведется через нее.
2. Настройка пользовательского командного интерфейса. В режиме обычного приложения можно тонко настроить видимость интерфейса под конкретного пользователя: скрыть системное меню «Операции», отключить показ ненужных журналов, отчетов и справочников на панели переключения. Данные действия не защищают от прямого программного чтения, но скрывают объекты из поля зрения оператора.
3. Использование типового RLS (ограничение прав на уровне записей). Если стоит цель разграничить видимость данных по организациям или складам, проверяем настройки параметров учета: во многих типовых конфигурациях данный механизм уже встроен и включается обычными флажками в пользовательском режиме.

Создание ограниченной роли в конфигураторе и скрытые зависимости прав

Если принято решение включить возможность редактирования конфигурации, разберем по шагам корректный порядок действий по созданию новой роли:

1. В меню конфигуратора выбираем пункт Конфигурация — Поддержка — Настройка поддержки и включаем возможность изменения с сохранением поддержки.
2. Не создаем роль с нуля. Проще всего скопировать типовую роль, максимально близкую по смыслу (или роль Бухгалтер), переименовать ее (например, в ОграниченныйДоступРеализация) и отключить лишние права.
3. Обращаем внимание на скрытые системные зависимости: если открыть права только на документ, система выдаст ошибку нарушения прав доступа при первой же попытке пользователя провести документ или выбрать контрагента.

Для корректной работы с документами реализации товаров и счетами-фактурами роль обязательно должна содержать право «Чтение» и «Просмотр» на сопутствующие нормативно-справочные объекты и регистры:

1. Справочники: Контрагенты, ДоговорыКонтрагентов, Номенклатура, Склады, Организации, Валюты, КлассификаторЕдиницИзмерения, СтавкиНДС.
2. Регистры сведений: КурсыВалют, ЦеныНоменклатуры, СчетаУчетаНоменклатуры.
3. Планы счетов и регистры бухгалтерии: если документу требуется формировать бухгалтерские проводки, у пользователя должны быть права на запись движений в журнал проводок (план счетов Хозрасчетный).
4. Обязательное назначение роли «Пользователь»: в типовых решениях любому пользователю системы помимо узкопрофильной роли всегда должна быть назначена базовая роль Пользователь. Она отвечает за чтение констант, параметров сеанса и инициализацию рабочего стола при старте 1С:Предприятия.

Почему возникает ошибка «Нет прав на запуск требуемого вида клиента»?

Разберем частую проблему, с которой сталкиваются разработчики в конфигурациях на базе Библиотеки стандартных подсистем (БСП) или конфигурациях с управляемыми формами (например, УНФ, БП 3.0, УТ 11). Ситуация: роль создана, права запуска клиента в ней отмечены, но при назначении роли пользователю через справочник ПрофилиГруппДоступа система выдает отказ в авторизации.

Выясним главные причины такого поведения подсистемы управления доступом:

1. Отсутствие системной базовой роли. Для успешного запуска сеанса одного лишь флажка ТонкийКлиент или ТолстыйКлиент в самописной роли недостаточно. В состав профиля пользователя обязательно должна входить предопределенная системная роль (в БСП это роль БазовыеПраваБСП или БазовыеПраваПользователя). Без нее система не может заполнить параметры сеанса при входе.
2. Не обновлены вспомогательные данные метаданных. При добавлении роли в конфигураторе справочники подсистемы доступа еще не знают о ее появлении. Необходимо обновить справочник ИдентификаторыОбъектовМетаданных, а также запустить процедуру обновления вспомогательных данных (например, запуском системы с параметром командной строки /ЗапуститьОбновлениеИнформационнойБазы).
3. Механизм отложенного обновления прав пользователей. В конфигурациях на БСП назначение ролей пользователям информационной базы выполняется через фоновые задания либо при явной перезаписи элемента справочника Пользователи. В файловых базах регламентные задания могут не выполняться в фоне, из-за чего список ролей пользователя ИБ не синхронизируется с профилями групп доступа. В таком случае необходимо открыть карточку пользователя и пересохранить ее вручную.
4. Проверки в общем модуле УправлениеДоступомПереопределяемый. В некоторых версиях библиотек список доступных для интерактивного назначения ролей жестко переопределяется в процедурах общего модуля. Если новая роль не зарегистрирована разработчиком в теле соответствующей процедуры, алгоритмы подсистемы могут сбрасывать ее при автоматическом пересчете прав.

Таким образом, если необходимо строго разграничить права без вмешательства в конфигуратор, используем организационные методы или внешние интерфейсные обработки. Если же создается отдельная роль в конфигураторе, всегда назначаем ее в связке с базовыми системными ролями и учитываем все сопутствующие метаданные, к которым обращается логика проведения документов.