В рамках курса Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки рассматриваются принципы корректной доработки типовых конфигураций. Часто слушатели делятся с нами нестандартными приемами доработок из своей практики и просят тренера оценить их решение.
В следующем вопросе слушатель пытается выяснить о потенциальных трудностях, которые могут возникнуть при переносе разработанного функционала для конфигурации предыдущего поколения на современное решение, базирующееся на БСП.
Вопрос
Добрый день! Хотел бы узнать ваше мнение о таком варианте использования подписок на события:
- В конфигураторе созданы общие “запускающие” подписки на события для ДокументОбъект (ПередЗаписью, ОбработкаПроведения, ОбработкаЗаполнения), СправочникОбъект (ПередЗаписью), РегистрСведенийНаборЗаписей (ПередЗаписью).
- Прикладные обработчики вынесены в справочник (Рисунок 1). Справочник иерархический. 1 уровень – тип объекта, 2 уровень – имя объекта, 3 уровень – имя события.
Рисунок 1 – Прикладные обработчики подписок на события
(нажмите, чтобы увеличить картинку)
- Для каждого обработчика можно описать условия запуска в виде отбора по данным объекта либо по пользователю/группе (Рисунок 2, Рисунок 3).
Рисунок 2 – Отбор по данным объекта
Рисунок 3 – Отбор по пользователю или группе пользователей
- Можно описать произвольные параметры и использовать их в коде (Рисунок 4).
Рисунок 4 – Параметры прикладных обработчиков
- Включение/отключение обработчика производится установкой флажка “Активный” (Рисунок 5).
Рисунок 5 – Код функции-обработчика
В настоящий момент в нашей базе 1С УПП настроено 400 таких обработчиков. Страшно подумать, на что похоже было бы дерево метаданных, если бы мы помещали все подписки на события туда.
Интересуют возможные проблемы производительности при использовании подобного подхода в современных конфигурациях на базе БСП.
Ответ тренера
Очень интересный подход! Достаточно универсальное решение. Для конфигураций на базе БСП можно сделать отборы на базе компоновщика настроек системы компоновки данных, чтобы была возможность указать произвольный фильтр.
На мой взгляд, поиск подходящих обработчиков для конкретного типа документа, который в данный момент записывается или проводится, с точки зрения производительности, является самым затратный механизмом. Если делать такой механизм универсальным, с произвольными отборами, то основная часть времени будет уходить на выбор тех обработчиков, которые должны отработать, но это плата за универсальность механизма.
Таким образом, под БСП я бы попробовал переносить существующий механизм, добавив в него возможность использовать компоновку для отборов.
А какой подход используете Вы? Делитесь в комментариях :)
Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки.
Добрый день!
Как методически грамотно в БСП установить ограничения на действия?
Например, запретить некоторым пользователям изменять документ начисления, если есть ведомость.
Добрый день!
Рассмотрите возможность применения подсистемы БСП Запрет редактирования реквизитов объектов для решения Вашей задачи.
Документацию по этой подсистеме можно найти на сайте ИТС: https://its.1c.ru/db/bsp312doc/content/35/1
Например, в типовой УТ 11 при открытии формы учетной политики поля недоступны для редактирования:
Пользователь должен явно разрешить редактирование, чтобы случайное изменение ключевых полей не привело к рассогласованию учетных данных.