Как посмотреть права на документ в 1С

Права на документ в 1С определяют, кто может создавать, читать, изменять, проводить и удалять документы конкретного вида. Проверять их приходится, когда пользователь жалуется на ошибку «Нарушение прав доступа», когда нужно ограничить доступ к кассовым или складским операциям или когда администратор настраивает новую роль. Способ просмотра зависит от того, работаете ли вы в обычном приложении на базе БСП (Управление торговлей, ERP, Бухгалтерия) или в конфигурации с ролями, заданными напрямую.

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

Где вообще хранятся права на документы

В платформе 1С право — это разрешение на конкретное действие с конкретным объектом метаданных. Для документа существуют отдельные права: чтение, добавление, изменение, удаление, проведение, отмена проведения, интерактивное проведение, интерактивное удаление и другие. Каждое из них включается или выключается независимо.

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

Дополнительно действует механизм RLS — ограничение доступа на уровне записей. Он не запрещает документ целиком, а фильтрует строки: например, менеджер видит только документы по своей организации или своему складу. Если пользователь видит документ в списке, но не может его открыть, или наоборот — список пуст при явно выданных правах, почти всегда виноват именно RLS.

Как посмотреть права через отчёт «Анализ прав доступа»

В типовых конфигурациях на БСП (1С:Бухгалтерия 3.0, Управление торговлей 11, ERP, ЗУП) есть штатный инструмент, который показывает права без входа в конфигуратор. Откройте раздел «Администрирование» → «Пользователи и права» → «Группы доступа». В форме списка или карточки пользователя доступен отчёт «Анализ прав доступа» (в некоторых версиях — «Права доступа» по кнопке «Отчёты»).

В отчёте выберите пользователя и объект — нужный вид документа. На выходе вы увидите, какие права выданы (чтение, добавление, изменение и т.д.), через какой профиль и группу доступа они попали к пользователю. Это самый быстрый способ ответить на вопрос «почему у Иванова есть доступ к этому документу» — отчёт покажет конкретный профиль-источник.

1. 1
   Откройте Администрирование → Пользователи и права → Группы доступа
2. 2
   Запустите отчёт «Анализ прав доступа» (или «Права доступа»)
3. 3
   Укажите пользователя и вид документа
4. 4
   Изучите колонки прав и колонку «Профиль» — откуда пришло разрешение
5. 5
   При необходимости откройте профиль и снимите или добавьте роль

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

Как посмотреть права в конфигураторе

Детальную картину даёт конфигуратор. Откройте его под пользователем с правами администратора и перейдите в ветку «Общие» → «Роли». Двойной клик по роли открывает окно настройки прав: слева — дерево объектов метаданных, справа — список прав с флажками.

Найдите в дереве раздел «Документы» и нужный вид документа, например «РеализацияТоваровУслуг». Справа отобразятся права, которые эта роль даёт на документ: чтение, добавление, изменение, удаление, проведение, отмена проведения, интерактивное проведение, интерактивная отмена проведения, интерактивное удаление, интерактивное пометка удаления и другие. Установленный флажок — право есть, снятый — нет.

Чтобы понять, какие роли назначены конкретному пользователю, откройте «Администрирование» → «Пользователи», выберите пользователя и перейдите на вкладку «Прочие» (или посмотрите список ролей в карточке — зависит от версии платформы). Там виден полный перечень ролей, назначенных напрямую.

Как проверить права через профиль группы доступа

В конфигурациях на БСП администратор обычно не трогает конфигуратор, а работает с профилями. Путь: «Администрирование» → «Пользователи и права» → «Профили групп доступа». Откройте профиль — внутри виден список разрешённых ролей (вкладка «Разрешённые роли») и, если включён соответствующий режим, разрешённые значения доступа (организации, склады, контрагенты).

Чтобы понять, какие права на конкретный документ даёт профиль, посмотрите, какие роли в него входят, а затем сверьте эти роли с правами в конфигураторе. Например, профиль «Менеджер по продажам» включает роль «Добавление изменение документов продажи» — она и определяет, что пользователь может создавать и проводить реализации, но не может их удалять.

Если в профиле заданы разрешённые значения (например, только организация «ООО Ромашка»), это работает как RLS: пользователь увидит документы только по этой организации, даже если роль даёт полное право чтения документа. Проверяйте обе вкладки профиля.

Как проверить фактический доступ у конкретного пользователя

Надёжный практический способ — войти в базу под учётной записью этого пользователя (или попросить его выполнить действие) и попробовать открыть список документов, создать новый, изменить и провести существующий. Платформа выдаст сообщение «Нарушение прав доступа» на том действии, которое запрещено — это точно показывает, какого права не хватает.

Для программной проверки в коде используется функция ПравоДоступа("Чтение", Метаданные.Документы.РеализацияТоваровУслуг) — она возвращает Истина или Ложь для текущего пользователя. Это удобно при отладке и в расширениях, когда нужно скрыть кнопку, недоступную пользователю.

Если ПравоДоступа("Изменение", Метаданные.Документы.РеализацияТоваровУслуг) Тогда
    Сообщить("Есть право изменения");
Иначе
    Сообщить("Права изменения нет");
КонецЕсли;

Ещё один инструмент — журнал регистрации с включённым событием «Доступ. Отказ в доступе». Настройте отбор журнала по этому событию и пользователю: в записях будет видно, к какому объекту и с каким правом был отказ. Это помогает, когда пользователь не может сформулировать, на каком именно документе споткнулся.

Типичные ситуации и их разбор

Ситуация «документа нет в списке, хотя право чтения есть» почти всегда означает RLS: проверьте разрешённые значения в профиле и шаблоны ограничений в ролях. Ситуация «документ открывается, но кнопка «Провести» недоступна» — нет права «Интерактивное проведение»: право «Проведение» разрешает проведение программно, а для кнопки нужно именно интерактивное.

Ситуация «может создать, но не может изменить чужой документ» — в роли есть «Добавление» и «Изменение», но RLS или настройки даты запрета изменения данных блокируют правку. Проверьте также «Дату запрета изменения данных» в разделе администрирования: документы старше даты запрета недоступны для изменения даже при полных правах.

Ограничения и меры предосторожности

Просмотр прав — безопасная операция, но изменение ролей и профилей влияет на работу пользователей сразу. В файловой базе обновление конфигурации требует монопольного режима и выгоняет всех пользователей. В клиент-серверном варианте возможно динамическое обновление, но изменения ролей всё равно лучше применять в нерабочее время.

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

Частые вопросы