В современных конфигурациях на базе 1С:Предприятие 8.3 (таких как ERP Управление предприятием 2, Комплексная автоматизация 2 и Управление торговлей 11) разработчики часто сталкиваются с ситуацией: у пользователя есть полные права на чтение и редактирование конкретного документа, но в общем журнале документов (например, в журнале производства или авансовых отчетов) эти документы не отображаются. При этом, если открыть список документов напрямую через «Все функции» (или «Функции для технического специалиста»), документы видны.
Проанализируем эту ситуацию и разберем по шагам, почему так происходит и как восстановить работоспособность журналов. Рассмотрим внутренние механизмы платформы и программного кода, которые задействованы в формировании этих списков.
Для начала выясним причину, почему документы вообще могут пропадать из журналов при наличии прав на сами объекты. В последних версиях типовых решений динамические списки многих журналов строятся не напрямую по таблицам документов (например, Документ.ПроизводствоБезЗаказа), а по специальному вспомогательному регистру сведений — РеестрДокументов.
Этот регистр аккумулирует в себе ключевые поля всех документов системы: дату, номер, сумму, контрагента, ответственного и, самое главное, ссылку на сам документ. Это сделано для существенного повышения производительности: системе проще прочитать одну плоскую таблицу регистра, чем выполнять сложное объединение (UNION) множества таблиц различных видов документов при открытии общего журнала. Если записи о документе нет в этом регистре или к этой записи ограничен доступ на уровне RLS (Record Level Security), документ в журнале отображаться не будет.
Как показывает практика и обсуждение специалистов, наиболее частой «быстрой» причиной проблемы является отсутствие в профиле пользователя роли БазовыеПраваУТ (или аналогичной базовой роли в вашей конфигурации). Разберем, почему это критично.
В типовых шаблонах RLS для регистра РегистрСведений.РеестрДокументов прописано условие, которое проверяет права доступа не только к самой записи регистра, но и право чтения по идентификатору метаданных. Роль БазовыеПраваУТ содержит в себе необходимые минимальные права на доступ к служебным справочникам и регистрам, которые участвуют в механизме проверки доступа.
Решение: Добавьте роль БазовыеПраваУТ непосредственно в тот профиль доступа, который назначен пользователю. Даже если эта роль уже входит в другие профили пользователя, её явное добавление в проблемный профиль часто исправляет ситуацию с кэшированием прав.
Если добавление базовой роли не помогло, проанализируем ситуацию глубже. В системе используется шаблон RLS под названием ПравоЧтенияПоИдентификатору. Посмотрим на пример логики, которая отрабатывает внутри этого шаблона:
#ИначеЕсли "#Параметр(27)" = "ПравоЧтенияПоИдентификатору" Или "#Параметр(27)" = "ПравоИзмененияПоИдентификатору"
#Тогда
ИСТИНА В (
ВЫБРАТЬ ПЕРВЫЕ 1 ИСТИНА
ИЗ РегистрСведений.ТаблицыГруппДоступа КАК ТаблицыГруппДоступаПроверкаПрава
ГДЕ ТаблицыГруппДоступаПроверкаПрава.ГруппаДоступа = ГруппыДоступа.Ссылка
И ТаблицыГруппДоступаПроверкаПрава.Таблица = #Параметр(28)
#Если Не "#Параметр(27)" = "ПравоЧтенияПоИдентификатору" #Тогда
И ТаблицыГруппДоступаПроверкаПрава.Изменение
#КонецЕсли
)
В данном случае #Параметр(28) — это ссылка на элемент справочника ИдентификаторыОбъектовМетаданных. RLS запрашивает данные из регистра РегистрСведений.ТаблицыГруппДоступа. Если в этом регистре отсутствует запись о том, что конкретной группе доступа разрешено чтение таблицы данного типа документа, то RLS «отсечет» эти строки из запроса к реестру документов.
Выясним причину, почему данных в ТаблицыГруппДоступа может не быть:
Решение: Необходимо запустить процедуру обновления вспомогательных данных. Это можно сделать через раздел «Обслуживание» — «Управление доступом» — «Обновить таблицы групп доступа». Также можно воспользоваться консолью кода и вызвать метод БСП:
Справочники.ИдентификаторыОбъектовМетаданных.ВыполнитьОбновлениеДанных();
УправлениеДоступомСлужебный.ОбновитьТаблицыГруппДоступа();
Иногда корень проблемы кроется в справочнике ИдентификаторыОбъектовМетаданных. Рассмотрим ситуацию: при некорректном обновлении или переносе данных в справочнике может появиться два элемента для одного и того же документа (например, два элемента «Документ.ПроизводствоБезЗаказа»).
Проанализируем последствия: записи в РеестрДокументов могут быть привязаны к одному ID, а настройки в ТаблицыГруппДоступа — к другому. В результате RLS видит, что на «официальный» ID права есть, но в самом реестре ссылки ведут на «битый» или дублирующий ID. В этом случае документы исчезают из списка.
Решение: Проверьте справочник идентификаторов на наличие дублей. Используйте типовую обработку «Поиск и замена дублей». Если дубли обнаружены, объедините их, сделав правильным тот элемент, который имеет актуальное описание метаданных.
Поскольку журнал строится по регистру, данные в нем должны быть актуальными. За заполнение этого регистра отвечает регламентное задание Обслуживание реестра документов. Если это задание отключено или выполняется с ошибками, новые документы просто не попадут в реестр и не будут видны в журналах.
Разберем, как проверить и исправить данные в реестре:
РегистрСведений.РеестрДокументов по нужному ТипСсылки и запустить задание заново.РеестрДокументов.ОбновитьДанныеДокумента(Ссылка) для конкретного объекта.Помимо вышеперечисленного, стоит обратить внимание на следующие технические нюансы:
ТаблицыГруппДоступа.Подводя итог, можно сказать, что решение большинства проблем с отображением документов в журналах 1С:ERP сводится к обеспечению связки: Правильные идентификаторы метаданных -> Актуальные записи в Таблицах групп доступа -> Наличие базовых ролей в профиле -> Актуальные записи в Реестре документов. Последовательная проверка этих четырех звеньев позволит вам быстро найти и устранить причину неисправности.