В практике разработчика 1С часто возникает парадоксальная ситуация: пользователь жалуется, что в отчете, построенном на системе компоновки данных (СКД), не выводится определенная колонка. При этом, если запустить консоль запросов под тем же пользователем, данные в этой колонке прекрасно видны. На первый взгляд это кажется невозможным, так как запрос один и тот же. Однако СКД — это гораздо более сложный механизм, чем просто выполнение SQL-запроса к базе данных. В этой статье мы подробно разберем причины, по которым поля могут «исчезать» из отчетов, и найдем способы решения этой проблемы.
Первое и самое важное, что мы должны проанализировать — это разница между правами доступа на уровне метаданных. В 1С существует два фундаментально разных права для работы с данными: Чтение и Просмотр. Посмотрим, как они влияют на поведение системы.
Право Чтение позволяет платформе и программным механизмам (например, консоли запросов или фоновым заданиям) получать значения из базы данных. Если у пользователя есть право на чтение, он увидит результат выполнения запроса в консоли.
Право Просмотр — это интерактивное право. Оно определяет, может ли пользователь видеть это поле в формах, списках и, что критично для нас, в отчетах на базе СКД. Система компоновки данных автоматически скрывает любые поля, на которые у текущего пользователя отсутствует право Просмотр, даже если данные физически доступны для чтения. Это сделано для того, чтобы разработчик мог гибко настраивать видимость конфиденциальной информации в пользовательском интерфейсе.
Рассмотрим порядок проверки прав по шагам:
ЦенаРеализации).Чтение, и напротив права Просмотр. Если Просмотр снят — это и есть причина проблемы.Если с правами в ролях все в порядке, нам стоит заглянуть «под капот» самой схемы компоновки. СКД позволяет разработчику жестко ограничить использование полей на уровне настроек набора данных. Проанализируем настройки полей в Конфигураторе.
В схеме компоновки данных на закладке «Наборы данных» есть таблица со списком всех доступных полей. Обратим внимание на следующие колонки:
Также проверим колонку «Доступность». Если снять в ней флажок, поле станет невидимым для всех, независимо от их прав доступа в системе. Разработчики иногда используют это для временного скрытия технических полей, забывая вернуть настройки обратно.
Еще одна неочевидная причина — использование функциональных опций (ФО). В системе 1С реквизиты объектов могут быть привязаны к определенным опциям, которые включают или выключают целые блоки функционала (например, «Использовать несколько валют» или «Вести учет по сериям»).
Если поле ЦенаРеализации связано с функциональной опцией, которая в данный момент выключена в константах или настройках программы, платформа 1С автоматически исключит это поле из всех механизмов, включая СКД. Консоль запросов при этом может продолжать показывать данные, так как она работает с «чистым» SQL-запросом, игнорируя логику метаданных платформы. Проверим в свойствах реквизита в Конфигураторе, не входит ли он в состав какой-либо функциональной опции, и включена ли она в пользовательском режиме.
Система ограничения прав на уровне записей (RLS) также может накладывать свой отпечаток. Выясним, как это работает в контексте нашей проблемы. Если в роли пользователя прописано условие RLS, которое ограничивает доступ к определенным записям документа, то при формировании отчета СКД автоматически добавит эти условия в итоговый запрос.
Однако есть нюанс: если условие RLS настроено некорректно или обращается к таблицам, к которым у пользователя вовсе нет доступа, СКД может «тихо» вернуть пустое значение для конкретного поля или вовсе не включить его в выборку для конкретной строки. В консоли запросов условия RLS также применяются, но разработчики часто тестируют запросы в консоли под полными правами, забывая, что под обычным пользователем картина может быть иной.
Иногда корень проблемы лежит не в коде или правах, а в сохраненных настройках самого пользователя. Система компоновки данных сохраняет варианты отчетов и пользовательские настройки в системных хранилищах. Если пользователь когда-то вручную удалил колонку из отчета или изменил его структуру, эти настройки «запоминаются».
Попробуем выполнить следующие действия для диагностики:
ХранилищеОбщихНастроек или ХранилищеВариантовОтчетов.Не забудем проверить модуль объекта отчета или модуль формы. Часто разработчики программно вмешиваются в процесс формирования отчета в событии ПриКомпоновкеРезультата. Посмотрим на пример кода, который может скрывать поля:
Процедура ПриКомпоновкеРезультата(ДанныеРасшифровки, СтандартнаяОбработка)
// Проверяем наличие определенной роли у пользователя
Если Не РольДоступна("ПолныеПрава") Тогда
// Находим поле в доступных полях выбора и удаляем его
ПолеЦены = КомпоновщикНастроек.Настройки.ДоступныеПоляВыбора.Элементы.Найти("ЦенаРеализации");
Если ПолеЦены <> Неопределено Тогда
ПолеЦены.Использование = Ложь;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Такой код может быть написан специально для реализации сложной логики безопасности, которую невозможно описать стандартными ролями. Если вы обнаружите подобную конструкцию, значит, поле скрывается намеренно по заложенному алгоритму.
Если наше поле является вычисляемым в схеме СКД, проанализируем выражение, по которому оно рассчитывается. Если в формуле используются другие поля, на которые у пользователя нет прав, или вызываются функции общих модулей, доступ к которым ограничен (например, отсутствует флаг Вызов сервера или Внешнее соединение), СКД может просто не вывести результат вычисления.
Подведем итог нашего исследования:
Для решения проблемы отсутствующего поля в отчете СКД необходимо последовательно исключить влияние прав доступа (особенно права Просмотр), проверить настройки доступности полей внутри самой схемы, убедиться в активности функциональных опций и отсутствии программных ограничений в коде. Помните, что консоль запросов показывает данные, а СКД показывает представление данных, ограниченное метаданными и настройками интерфейса.