В системе 1С:Документооборот государственного учреждения (ДГУ) настройка прав доступа является одной из самых сложных и многогранных задач. Нередко возникает ситуация, когда пользователь включен во все необходимые группы (например, «Делопроизводители», «Работа с входящими документами»), но при попытке сохранить входящий документ система выдает ошибку: «Нарушение прав доступа». Рассмотрим подробно, почему это происходит и как пошагово диагностировать проблему.
Одной из скрытых причин отказа в доступе может быть отсутствие прав не на сам документ, а на связанные с ним объекты. Разберем ситуацию из практики: программист добавляет в систему новую Константу или Справочник, которые считываются в коде при записи документа. Если у пользователя в его ролях нет права на чтение этой константы, платформа заблокирует транзакцию записи всего документа.
Проанализируем пример кода, который может вызывать ошибку, если он выполняется в модуле объекта перед записью:
// Ошибка может возникнуть здесь, если у пользователя нет прав на чтение константы
Префикс = Константы.ИспользоватьДополнительныйПрефиксДГУ.Получить();
Если ЗначениеЗаполнено(Префикс) Тогда
// Логика обработки
КонецЕсли;
Чтобы исключить этот фактор, необходимо запустить сеанс под проблемным пользователем и воспользоваться отладчиком, установив остановку по ошибке. Если отладка подтверждает нехватку прав на конкретный метаданное, нужно добавить право «Чтение» в соответствующую роль.
В 1С:ДГУ существует мощный инструмент для визуализации того, как именно система посчитала права для конкретного объекта. Выясним причину отказа, выполнив следующие действия:
После обновления мы увидим список пользователей и ролей, а также колонки «Чтение», «Добавление», «Изменение». Нажав на конкретную ячейку, мы увидим расшифровку: на основании какой политики доступа или какой рабочей группы пользователю даны (или не даны) права. Это позволяет быстро понять, блокирует ли доступ общая политика или локальное ограничение.
Разберем критически важное правило системы 1С:Документооборот: если в документе заполнена «Рабочая группа», то общие политики доступа перестают действовать.
Посмотрим на ситуацию: в политиках доступа указано, что «Все пользователи» могут редактировать документы подразделения «Канцелярия». Однако в самом документе на закладке «Безопасность» указана рабочая группа, состоящая из трех человек. Если нашего пользователя нет в этой группе, он не сможет записать документ, даже если он является сотрудником Канцелярии. Проанализируем настройки автоматического формирования рабочих групп — часто они наследуются из настроек вида документа или заполняются программно.
Иногда права на объект у пользователя есть, но возможность редактирования блокируется механизмом состояний. В 1С:ДГУ предусмотрена матрица «Настройки доступности по состоянию». Проверим следующий путь:
Настройки почты и документов — Настройки доступности по состоянию.
Выясним, в каком статусе находится документ (например, «Зарегистрирован» или «На согласовании»). Если для этого состояния в матрице для роли пользователя (или для всех) не установлена галочка «Редактирование», кнопка «Записать» может выдавать ошибку доступа на уровне платформы. Это особенно актуально для входящих документов, которые проходят строгий жизненный цикл.
В версиях КОРП и ДГУ расчет прав выполняется через дескрипторы доступа. Это вспомогательные записи, которые ускоряют работу системы. Если в базе включено «Отложенное обновление прав», изменения в правах (например, добавление пользователя в группу) вступают в силу не мгновенно.
Рассмотрим порядок проверки очереди обновления:
ОбновлениеПравДоступа или запустить его принудительно.Если во входящих документах используются дополнительные реквизиты, пользователь обязан иметь права на их чтение и изменение. В 1С:ДГУ права на доп. сведения иногда требуют отдельной настройки в ролях. Если пользователь пытается изменить значение доп. реквизита, а у него нет права Изменение на справочник ЗначенияДополнительныхРеквизитовИСведений, система выдаст ошибку при попытке сохранить документ целиком.
Часто администраторы жалуются, что в Журнале регистрации нет записи об отказе в доступе. Проанализируем ситуацию: это происходит, когда проверка прав срабатывает на уровне RLS (Row Level Security) — платформенного механизма ограничения записей. Платформа просто «не видит» объект или запрещает его изменение без записи события в журнал, если не включен специальный уровень логирования.
Для детальной диагностики рекомендуем включить в конфигураторе сбор дампа или использовать замер производительности под проблемным пользователем. При попытке записи замер покажет, на какой процедуре (например, ПередЗаписью или ПриЗаписи) происходит прерывание из-за нехватки прав.
Важное резюме: для решения проблемы нарушения прав доступа во входящих документах 1С:ДГУ всегда начинайте с проверки вкладки «Права доступа» в карточке документа под администратором. В 90% случаев именно там кроется ответ: либо пользователь не попал в автоматическую рабочую группу, либо политики доступа настроены слишком узко для текущего подразделения или вида документа.