Пользователю не выдали право на одно поле - СКД молча выкинула его из отчёта, и отчёт вышел пустым. Без единой ошибки

Пользователь пишет: отчёт не работает. Открываю у себя, под полными правами, всё считается. Захожу под ним: отчёт формируется, закрывается, ноль строк. Ошибки нет.

У того же файла есть и вторая манера поведения. Под другим пользователем он падает с сообщением про ненайденное поле. Один отчёт, две разные жалобы.

Первая версия, которую называют все, почти всегда неверна. Снимается она одним запросом.

Дальше механизм, три его разновидности и способ узнать длину пути до того, как по нему пошли.

Первая версия и почему она отпала

Пустой отчёт под ограниченным пользователем, и все идут смотреть ограничение доступа на уровне записей (RLS, record level security). Логика безупречна: раз данных не видно, значит их отфильтровали по правам.

Проверяется это дёшево. Заходим под целевым пользователем и считаем строки в источниках отчёта напрямую, запросом, без всякой компоновки.

Результат: тысячи сотрудников, десятки тысяч начислений. Данные на месте, все источники видны.

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

Настоящая причина: право на просмотр поля

Записи в порядке. Ломаются поля.

Система компоновки данных (СКД) при сборке макета молча выбрасывает поля, на которые у пользователя нет права просмотра. Ни сообщения, ни строчки в журнале. Поле исчезает из схемы, сборка продолжается с тем, что осталось.

Дальше всё решает то, где именно в структуре стояло выброшенное поле. Отсюда два непохожих симптома у одного дефекта.

Почему СКД про это молчит, в документации я не нашёл. Дальше моё объяснение, документального подтверждения у него нет. Сообщение вида «поле такое-то от вас скрыто» само по себе утечка: оно рассказывает пользователю состав схемы, до которого его не допустили. Механизм выбран в пользу безопасности и против диагностируемости. Жить с этим придётся, но знать причину полезно, чтобы не искать несуществующую настройку «включить подробные сообщения».

Разновидность первая: пусто и без ошибки

Если недоступное поле стояло в строках или колонках таблицы, компоновка выбрасывает его, и вместе с ним схлопывается вся структура. Наборов данных остаётся ноль.

Отчёт формируется. Успешно. Пустой.

Компоновка не отфильтровала строки, она удалила структуру. Поэтому диагностика «почему нет данных» уводит совсем не туда: вы начинаете проверять периоды, отборы, движения регистров, а ломается всё этажом выше.

Разновидность вторая: жёсткая ошибка при выводе

Если недоступным оказалось ссылочное поле в выводе, компоновка генерирует обращение к представлению ссылки. Права просмотра на тип нет, обращение не компилируется, приходит ошибка про ненайденное поле.

Здесь же спрятана ловушка, на которой теряют больше всего времени. При составном типе право нужно на все типы сразу. У поля два возможных типа, просмотр есть на один: падает так же, как если бы не было ни одного. При этом в сообщении вы увидите имя поля. Имя недостающего типа там не появится, искать его придётся самому, перебирая состав типа.

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

Разновидность третья: не то право

Третий вариант проще и коварнее.

«Чтение» и «Просмотр» это разные права. Первое определяет, может ли объект вообще участвовать в запросе. Второе определяет, может ли поле быть выведено.

Нет чтения на объект, и его реквизиты невидимы языку запросов, ошибка приходит на этапе разбора текста запроса. Нет просмотра на поле, и объект в запросе есть, а поле молча выпадает.

Симптомы разные, лечение разное, а звучат оба одинаково: «нет прав».

Настройка роли, которая меняет всё

Одна галочка, про которую стоит знать до того, как начнёте перечислять поля руками.

У роли есть признак «права для новых реквизитов по умолчанию». Когда он включён, право просмотра, выданное на объект, автоматически распространяется на все его поля, включая те, что появятся в будущих обновлениях.

С этим признаком поля перечислять не нужно вовсе. Без него нужно каждое, и каждый новый реквизит после обновления конфигурации становится новой невидимой миной.

Это самая дешёвая проверка из всей статьи: посмотреть состояние признака у ролей, с которыми вы работаете. Она заодно объясняет, почему у одних ролей поля «сами появляются», а у других нет, хотя настраивали их одни и те же руки.

У признака есть обратная сторона, и о ней стоит думать до того, как включать. Он выдаёт право вперёд, на реквизиты, которых ещё не существует. После очередного обновления конфигурации пользователь получит просмотр на всё новое автоматически, включая поля, которые вы бы ему сознательно не дали. Для ролей, где ограничение носит организационный характер, это неприемлемо. Для технических ролей это снимает целый класс регулярной работы после каждого обновления.

Как воспроизвести это у себя

Если механизм не укладывается в голове, соберите его руками на тестовой базе, это быстрее любого чтения.

1. Заведите роль с чтением на один справочник и снимите просмотр с одного его реквизита.
2. Постройте отчёт, где этот реквизит стоит в строках таблицы. Запустите под тестовым пользователем: отчёт отработает и будет пустым.
3. Переставьте тот же реквизит из строк в вывод детальных записей. Запустите ещё раз: вы получите ошибку про ненайденное поле.

Ничего не поменялось, кроме позиции одного поля в структуре. Симптом поменялся полностью.

Почему это выматывает

Ошибки вылезают по одной. Запустил, поймал сообщение про поле, выдал право, запустил снова, поймал следующее. И так столько раз, сколько недоступных полей в отчёте.

Каждая итерация это не только время выполнения, но и переключение контекста: зайти в роль, найти объект, найти поле, поставить галочку, выйти, перезайти пользователем. Раздражает это сильнее, чем длится, потому что конца не видно.

Правильный ход это выяснить полный список недоступных полей за один проход, до того как начинать раздавать права. Технически делается разбором доступных полей компоновки под целевым пользователем и сравнением с тем, что реально использует схема отчёта. Смысл в том, что вы получаете длину пути до того, как по нему пошли.

Что именно сравнивать

Список полей схемы обычно берут из наборов данных и на этом останавливаются, а зря. Смотреть надо шире:

• поля наборов данных, включая те, что участвуют только в связях;
• поля, которые встречаются в вычисляемых полях и в выражениях ресурсов;
• поля, зашитые в отборы и параметры настроек по умолчанию;
• поля структуры вариантов отчёта, то есть строки, колонки и группировки.

Последний пункт самый важный, потому что именно он даёт молчаливый симптом.

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

И ещё одно наблюдение, которое экономит время на повторных случаях. Недоступные поля почти никогда не разбросаны случайно, они группируются вокруг одного объекта или одного смыслового блока: суммы, персональные данные. Нашли одно, сразу смотрите его соседей по тому же объекту, ещё до следующего запуска отчёта.

Четыре вещи, которые мешают диагностике

Прямая выдача роли пользователю не держится. Механизм управления доступом синхронизирует роли по профилям групп и снимает выданную напрямую. Выглядит это так: первый запуск после выдачи работает, второй снова падает, и вы начинаете сомневаться в собственной памяти. Класть роль надо в профиль группы доступа.

Нельзя штатно выяснить, какая именно роль даёт право. Функция проверки суммирует все роли пользователя и роль параметром не принимает. Ответ на вопрос «откуда у него это право» ищется только поиском по выгрузке прав конфигурации. Для пользователя, у которого профилей несколько, это отдельная работа, и закладывать её надо заранее.

Выгрузку прав по ролям мы вынесли в отдельную обработку: Матрица прав доступа 1С для нейросети.

Отчёт формируется в фоновом задании. Точка останова в отладчике не сработает, пока явно не включена отладка фоновых заданий, и это первое, обо что спотыкаются при попытке посмотреть изнутри.

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

Когда пустой отчёт это работающее правило

Без этого раздела статья была бы вредной.

Роли вида «чтение без просмотра» существуют намеренно. Они дают чтение для расчётов и запрещают вывод сумм: расчётчик может считать, но не может увидеть чужую зарплату в отчёте.

То есть «отчёт не работает» в такой конфигурации это не поломка, а работающее ограничение. Выдать право просмотра на суммы технически делается одной галочкой, и это будет раскрытие данных, решение о котором принимает не разработчик.

Правильный порядок здесь такой. Сначала выясняем, недоступность поля это упущение при настройке роли или сознательное правило. Если правило, то дальше разговор идёт про вариант отчёта без этой колонки, и права тут обсуждать бесполезно.

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

Скажу честно: в разобранном случае чем всё закончилось по существу, не зафиксировано. Дали права на суммы или сделали урезанный вариант отчёта, я не знаю, это решение оставалось за бизнесом. Материал доводит до развилки и на ней обрывается.
 

Другие наши инструменты по правам и метаданным:

• Матрица прав доступа 1С для нейросети - выгружает права ролей по объектам и реквизитам, тот самый список, который в этой статье собирается руками.
• Выгрузка структуры метаданных 1С для нейросети - показывает состав реквизитов и типы, включая составные: по ней видно, на сколько типов придётся выдавать просмотр.

Как я перестал разбирать права руками, разобрано отдельно: статья про матрицу прав.

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