При работе в 1С:Предприятие 8 программисты часто сталкиваются с ситуацией, когда система выдает лаконичное сообщение «Нарушение прав доступа!», но при этом в Журнале регистрации (ЖР) не появляется событие «Доступ. Отказ в доступе». Особенно часто это происходит при проведении или отмене проведения документов в старых конфигурациях, таких как «Бухгалтерия предприятия 2.0», или на платформе 8.2. В такой ситуации стандартный отладчик не всегда помогает, так как ошибка может возникать на уровне ядра платформы или при выполнении внутренних SQL-запросов.
Разберем подробно, почему так происходит, и какими методами можно выявить «скрытый» объект, на который пользователю не хватает прав.
Проанализируем одну из самых коварных особенностей платформы 1С. Ошибка «Нарушение прав доступа!» без записи в ЖР часто возникает в тот момент, когда программный код (или сам механизм платформы) выполняет запрос к таблице, на которую у пользователя есть право Чтение, но отсутствует право Просмотр.
В этом случае платформа считает, что данные читать можно (например, для программных вычислений), но отображать их пользователю или использовать в интерактивных операциях нельзя. Если такой запрос выполняется внутри транзакции записи документа, система прерывает операцию с системной ошибкой. При этом Журнал регистрации игнорирует это событие, так как формально «отказа в чтении» не было — произошел конфликт прав на уровне интерфейсного представления.
Что нужно сделать:
ПередЗаписью и ПриЗаписи.Чтение, и Просмотр.Рассмотрим ситуацию, когда ошибка возникает в процедурах удаления движений, например, в методе УдалитьДвиженияРегистратора(). Часто программисты проверяют права только на те регистры, по которым документ делает движения «в данный момент». Однако платформа может проверять права на все регистры, в которых данный документ указан как возможный регистратор.
Выясним причину глубже: при выполнении метода ДокументОбъект.Записать(РежимЗаписиДокумента.Запись) система может инициировать проверку метаданных всех связанных наборов записей. Если в конфигурацию был добавлен новый регистр (возможно, нетиповой) и этот документ был назначен его регистратором, но права пользователю на этот регистр не дали — вы получите отказ в доступе.
Рекомендация: откройте документ в конфигураторе, перейдите на закладку «Движения» и проверьте права пользователя на каждый отмеченный в списке регистр (как накопления, так и бухгалтерии или сведений).
Если обычные методы не помогают, воспользуемся самым мощным инструментом диагностики — Технологическим журналом. ТЖ фиксирует события на уровне взаимодействия платформы с СУБД и операционной системой, что позволяет увидеть ошибку до того, как она будет «проглочена» или преобразована платформой.
Для поиска ошибки прав доступа нам необходимо настроить сбор событий SDBL (запросы к базе данных) и EXCP (исключительные ситуации). Создадим файл logcfg.xml в каталоге установки 1С (для сервера или локального клиента) со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\ACCESS_ERROR" history="2">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
</event>
<property name="all"/>
</log>
После воспроизведения ошибки проанализируем лог-файлы. Ищите события EXCP, в описании которых фигурирует текст «Access violation» или «Нарушение прав». Рядом в логе будут находиться события SDBL, указывающие на конкретную таблицу SQL (например, _InfoReg123). По имени таблицы в консоли запросов или через поиск в конфигурации можно легко определить проблемный объект метаданных.
Посмотрим на проблему со стороны механизма RLS (Row Level Security). В сильно перепиленных конфигурациях БП 2.0 часто внедряются части БСП (Библиотеки стандартных подсистем) или самописные ограничения. Если RLS настроен на проверку прав через дополнительные справочники (например, «Группы доступа физических лиц» или «Подразделения»), ошибка может возникать из-за отсутствия прав на сам служебный объект, к которому обращается запрос RLS.
Также возможна ситуация, когда в кэше метаданных или в служебных параметрах сеанса хранятся устаревшие данные.
Как решить:
Разберем еще один сценарий, специфичный для регистров бухгалтерии. При записи документа система проверяет права на значения Субконто. Если в качестве субконто выступает объект ПВХ (План видов характеристик), а в нем выбрано значение справочника, на который у пользователя нет прав даже на Чтение, платформа выдаст ошибку доступа при попытке прочитать движения.
Аналогично проверьте права на стандартные реквизиты. Бывают случаи, когда у пользователя есть права на документ, но ограничены права на реквизиты Проведен, ПометкаУдаления или Дата через механизм RLS. Попытка изменить состояние этих полей при записи приведет к «тихому» отказу.
Если вы столкнулись с ошибкой прав без записи в ЖР, действуйте по шагам:
Просмотр на все объекты, участвующие в транзакции.Попытка...Исключение и выведите ОписаниеОшибки(), хотя это помогает не всегда.ВПривилегированномРежиме(Истина) в подписках на события. Если ошибка исчезнет — значит, проблема точно в правах на данные, а не в логике кода.