В процессе разработки на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда новый реквизит, добавленный в динамический список, прекрасно отображается под полными правами, но бесследно исчезает у пользователей с ограниченным доступом. Эта проблема становится особенно актуальной, когда используются расширения конфигурации и данные извлекаются через связи с другими объектами. Давайте подробно разберем, почему это происходит и как пошагово восстановить видимость данных.
Проанализируем наиболее вероятную причину: если объект (например, регистратор или связанный документ) добавлен или изменен в расширении, стандартных прав основной конфигурации может быть недостаточно. Выясним, установлены ли права на конкретные поля. Даже если у роли есть доступ к самому документу, права на его стандартные реквизиты (такие как Дата, Номер, Проведен) могут отсутствовать в расширении.
Разберем, на что нужно обратить внимание в конфигураторе:
Регистратор.Дата), убедимся, что права установлены именно на тип данных ДокументСсылка..., который является регистратором.Рассмотрим ситуацию, когда права настроены верно, но система их «не видит». Если в конфигурации используется Библиотека стандартных подсистем (БСП), она хранит информацию о правах и доступе в специальных служебных регистрах (кеше). При изменении состава ролей или прав в расширении эти данные требуют принудительного обновления.
Для решения этой задачи выполним следующие действия:
/С ЗапуститьОбновлениеИнформационнойБазы.ОбновлениеВспомогательныхДанных.epf, которая обычно входит в состав дистрибутива БСП. Она позволяет пересчитать параметры доступа и обновить кэш метаданных.Посмотрим на настройки самого динамического списка в конфигураторе. Платформа 1С оптимизирует запросы и может исключать поля, которые, по ее мнению, не требуются для отображения. Проанализируем свойство «Использовать всегда».
Если реквизит получается в запросе, но не выведен на форму напрямую как элемент (колонку), или его видимость управляется программно, установим флажок в колонке «Использовать всегда» в списке полей динамического списка. Это гарантирует, что платформа включит данное поле в SELECT запрос вне зависимости от визуальных настроек формы.
Также проверим настройку «Автозаполнение доступных полей». Если она выключена, каждое новое поле, добавленное в текст запроса, должно быть вручную прописано в схеме компоновки данных (СКД) динамического списка, иначе оно будет недоступно пользователю.
Выясним, не скрыто ли поле механизмом функциональных опций. Если реквизит или объект, к которому мы обращаемся, привязан к функциональной опции, которая отключена для данного пользователя или организации, платформа автоматически скроет колонку. Это происходит незаметно для разработчика, так как под полными правами опции часто включены по умолчанию.
Проанализируем также настройки RLS (Record Level Security). Если на таблицу (например, таблицу регистраторов) наложены ограничения на уровне записей, то при выполнении запроса динамического списка поля этой таблицы могут возвращать NULL. В интерфейсе это выглядит как пустая колонка или ее полное отсутствие, если платформа определяет, что данных нет.
Иногда причина кроется в коде самой формы. Рассмотрим процедуры ПриСозданииНаСервере или ПриОткрытии. Проверим, нет ли там условий, ограничивающих видимость элементов:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверим, не скрывается ли колонка программно для определенных ролей
Если НЕ РольДоступна("ПолныеПрава") Тогда
Элементы.СписокРегистраторДата.Видимость = Ложь;
КонецЕсли;
// Также проверим, не модифицируется ли текст запроса динамического списка
// В зависимости от прав пользователя текст запроса может меняться динамически
Если НЕ РольДоступна("ПросмотрДополнительныхДанных") Тогда
ТекстЗапроса = Список.ТекстЗапроса;
// Здесь может быть логика удаления полей из текста запроса
КонецЕсли;
КонецПроцедуры
Если все вышеперечисленные методы не помогли, разберем самый простой, но действенный способ — сброс настроек формы. Пользователь мог случайно скрыть колонку, или настройки «закешировались» в старом виде до того, как вы добавили реквизит.
Попросим пользователя выполнить следующие шаги:
Если после этого реквизит не появился в списке доступных полей в левой части окна «Настройка формы», значит, проблема определенно в правах доступа (View) или в функциональных опциях.
Когда мы пишем запрос для динамического списка, мы часто используем конструкцию типа Регистратор.Номер. Важно понимать, что для платформы это означает неявное левое соединение (LEFT JOIN). Если у пользователя нет прав на чтение объекта Регистратор, то результатом соединения будет пустое значение. Проверим, есть ли у ограниченной роли право на чтение и просмотр самого объекта, реквизиты которого мы пытаемся вывести.
Рассмотрим пример правильного построения запроса в динамическом списке для обеспечения максимальной совместимости:
ВЫБРАТЬ
ДокументРеестр.Ссылка КАК Ссылка,
ДокументРеестр.Дата КАК Дата,
ДокументРеестр.Номер КАК Номер,
// Используем явное обращение, если права позволяют
ДокументРеестр.Регистратор.Дата КАК ДатаРегистратора,
ДокументРеестр.Регистратор.Номер КАК НомерРегистратора
ИЗ
Документ.Реестр КАК ДокументРеестр
Подведем итог: решение проблемы невидимости реквизита всегда лежит в плоскости проверки прав «Просмотр» в расширении, обновления служебных данных БСП и анализа свойств поля в настройках динамического списка (Использовать всегда). Последовательное выполнение этих шагов позволяет гарантированно вернуть данные на форму для всех категорий пользователей.