Уважаемые коллеги, мы сталкиваемся с частой задачей: необходимо ограничить доступ или полностью скрыть поле «Комментарий» во всех документах конфигурации 1С:Бухгалтерия Предприятия 3.0 КОРП, например, для целей аудита или упрощения интерфейса. Давайте вместе разберем, как мы можем решить эту проблему наиболее эффективными и поддерживаемыми способами.
Задача кажется простой, но требует внимательного подхода, чтобы решение было надежным, легко обновляемым и не создавало дополнительных проблем. Мы проанализируем различные подходы и выберем оптимальные.
Мы выяснили, что механизм функциональных опций в платформе 1С:Предприятие является наиболее предпочтительным и элегантным способом управления видимостью элементов формы, включая наше поле «Комментарий». Этот подход позволяет нам гибко настраивать доступность функционала в зависимости от данных в информационной базе, например, от значения константы или параметра функциональной опции. Рассмотрим подробнее, как мы можем это реализовать.
Создание функциональной опции. Для начала нам потребуется создать новую функциональную опцию в конфигурации или расширении. Допустим, назовем ее ИспользоватьКомментарииВДокументах. Эта опция будет определять, отображаются ли комментарии в документах.
Для создания функциональной опции в расширении, нам нужно:
Открыть расширение в конфигураторе.
В дереве объектов конфигурации расширения найти ветку «Функциональные опции».
Добавить новую функциональную опцию, например, ИспользоватьКомментарииВДокументах.
В свойстве «Привилегированный режим» для нашей опции установим значение «Истина», если мы хотим, чтобы значение опции определялось независимо от прав текущего пользователя.
Привязка реквизита «Комментарий» к опции. Далее нам нужно привязать свойство Видимость поля «Комментарий» в каждой форме документа к нашей новой функциональной опции. Это можно сделать в режиме конфигуратора для каждого элемента формы «Комментарий»:
В расширении найдите форму документа, которую мы хотим изменить (например, Документ.РеализацияТоваровУслуг.Форма.ФормаДокумента).
Добавьте эту форму в расширение (если она еще не добавлена).
Откройте форму и найдите элемент формы, соответствующий полю «Комментарий» (обычно это элемент с именем Комментарий).
В свойствах этого элемента формы найдите пункт «Функциональная опция» и укажите там нашу опцию ИспользоватьКомментарииВДокументах.
Повторите этот шаг для всех необходимых форм документов.
Управление функциональной опцией. Теперь мы можем управлять видимостью поля централизованно. Как правило, функциональные опции управляются через:
Константу: Мы можем создать константу, например, ИспользоватьКомментарии (тип Булево), которая будет хранить значение нашей функциональной опции. Эту константу можно добавить в расширение. Затем в свойствах функциональной опции ИспользоватьКомментарииВДокументах в поле «Параметр» мы указываем нашу константу Константы.ИспользоватьКомментарии. Для аудиторов или тех, кому комментарии не нужны, мы просто устанавливаем значение константы в «Ложь».
Пример кода для программного управления константой:
// Установка значения константы для отключения комментариев
Константы.ИспользоватьКомментарии.Установить(Ложь);
// Установка значения константы для включения комментариев
Константы.ИспользоватьКомментарии.Установить(Истина);
Роль: Мы можем создать новую роль, например, «Аудитор без комментариев», и в ее правах доступа указать, что для этой роли функциональная опция ИспользоватьКомментарииВДокументах отключена. Пользователям, которым нужно скрыть комментарии, мы просто назначаем эту роль. Для этого в свойствах функциональной опции ИспользоватьКомментарииВДокументах в поле «Роли» мы указываем, какие роли имеют право на использование этой опции.
Централизованное управление: Мы управляем видимостью поля из одного места (константа или роль), что значительно упрощает поддержку.
Гибкость: Мы можем быстро включать/отключать комментарии для разных групп пользователей или в зависимости от настроек.
Сохранение поддержки: Все изменения вносятся через расширение, что позволяет нам легко обновлять типовую конфигурацию без снятия с поддержки.
«Вырезание» функционала: Функциональные опции позволяют нам «вырезать» ненужный функционал из интерфейса, делая его более простым и понятным для пользователя.
Функциональные опции не влияют на состав базы данных; все таблицы и поля остаются в базе независимо от состояния опций. Это означает, что данные в поле «Комментарий» по-прежнему будут храниться, просто поле не будет отображаться в форме.
Это подход, который был предложен автором изначально. Он также реализуется через расширение, что позволяет сохранить типовую конфигурацию на поддержке. Мы можем программно управлять свойством Видимость элемента формы «Комментарий».
Мы добавляем в расширение обработчик события, который выполняется при открытии формы документа. В этом обработчике мы получаем доступ к элементу формы «Комментарий» и устанавливаем его свойство Видимость в значение Ложь.
Добавление формы в расширение. В расширение нам нужно добавить все формы документов, в которых мы хотим скрыть поле «Комментарий». Например, для документа «Реализация товаров и услуг» это будет форма Документ.РеализацияТоваровУслуг.Форма.ФормаДокумента.
Создание обработчика события. Для каждой добавленной формы мы можем создать обработчик события ПриОткрытии (или ПриСозданииНаСервере, если нам нужно выполнить действие на сервере до отображения формы).
Изменение свойства видимости. В созданном обработчике мы получаем доступ к элементу формы «Комментарий» и устанавливаем его свойство Видимость.
Посмотрим на пример кода, который можно разместить в модуле формы расширения:
// В модуле формы расширения (например, Документ.РеализацияТоваровУслуг.Форма.ФормаДокумента.Расширение)
// Подключаемся к событию формы "ПриСозданииНаСервере"
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Вызываем оригинальный обработчик
ЭтаФорма.ПриСозданииНаСервере(Отказ, СтандартнаяОбработка);
// Получаем элемент формы "Комментарий"
ЭлементКомментарий = ЭтаФорма.Элементы.Найти("Комментарий");
// Проверяем, что элемент существует, и скрываем его
Если ЭлементКомментарий <> Неопределено Тогда
ЭлементКомментарий.Видимость = Ложь;
КонецЕсли;
КонецПроцедуры
Или, как было предложено в исходной теме, мы можем использовать общие модули расширения для централизованного вызова:
// В модуле расширения, который вызывается после инициализации формы
// Например, в расширении для формы ПроверкаКонтрагентовКлиент.ПриОткрытииДокумент(Форма)
// (если это возможно в вашей версии платформы и конфигурации)
// или в отдельном общем модуле, который подписывается на событие форм.
// Предположим, у нас есть процедура в общем модуле расширения,
// которая вызывается после открытия формы и передает ей объект Форма.
Процедура СкрытьКомментарийВФорме(Форма) Экспорт
Если Форма.Элементы.Найти("Комментарий") <> Неопределено Тогда
Форма.Элементы.Комментарий.Видимость = Ложь;
КонецЕсли;
КонецПроцедуры
Для того чтобы этот код выполнялся для всех документов, нам потребуется либо вручную добавить подписки на события для каждой формы в расширении, либо найти точку входа, где мы можем централизованно обрабатывать открытие всех форм документов (например, через подписку на событие ПриОткрытии для всех форм, если такая возможность предоставляется платформой и конфигурацией). В типовых конфигурациях часто используются общие модули для инициализации форм, и мы можем расширить их функционал.
Прямолинейность: Это прямой и понятный способ скрытия элемента.
Сохранение поддержки: Изменения вносятся через расширение, что позволяет обновлять типовую конфигурацию.
Возможность обхода: Как справедливо отмечали коллеги на форуме, программное скрытие поля в форме может быть обойдено пользователем. Например, пользователь может самостоятельно добавить поле «Комментарий» в форму через команду «Изменить форму…» (Форма.НастроитьСписок();) или вывести его в отчете. Это не обеспечивает полной защиты от просмотра.
Множественные изменения: Если нам нужно скрыть поле во множестве форм, нам придется добавлять каждую форму в расширение и писать код для каждой из них, что может быть трудоемко.
Мы также рассмотрим другие варианты, которые обсуждались, чтобы понять, почему они менее применимы или не решают нашу задачу.
Механизм RLS (Row-Level Security) позволяет нам ограничивать доступ к данным на уровне записей. Однако его применение для скрытия *реквизитов формы* является гораздо более сложной задачей, и, как правило, RLS не предназначен для этого.
Назначение RLS: RLS в основном используется для ограничения чтения, изменения, добавления и удаления *записей* (строк данных), а не отдельных полей (реквизитов) в форме.
Сложности настройки: Если мы попытаемся ограничить чтение определенного реквизита через RLS, это может привести к тому, что сам объект (документ) не будет отображаться в списках или не будет открываться, что не соответствует задаче простого скрытия поля. Настройка RLS для реквизитов крайне трудоемка и требует детального анализа всех ролей и их прав на объекты и подчиненные реквизиты, что может быть «дико геморройно», как выразились на форуме.
Неэффективность: Платформа по умолчанию предоставляет права на просмотр реквизитов во всех ролях, и нам пришлось бы снимать эти отметки во всех без исключения ролях, что практически нереализуемо в крупных конфигурациях.
На форуме также прозвучала идея «очистить программно везде комментарий». Важно понимать, что это не является решением нашей задачи по *скрытию* поля. Это действие по *удалению* содержимого поля «Комментарий» во всех документах. Если наша цель — чтобы поле было пустым, это может быть вариант, но если мы хотим просто не показывать его пользователю, сохраняя при этом данные, то этот подход не подходит.
Вывод: Наиболее «элегантным» и поддерживаемым способом для закрытия поля «Комментарий» во всех документах, с учетом гибкости и минимизации изменений типовой конфигурации, является использование функциональных опций через расширение. Этот подход позволяет нам управлять видимостью поля централизованно, основываясь на ролях или других параметрах, и при этом сохранять возможность обновления конфигурации.
← К списку