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