Каждый разработчик 1С, работающий в крупной команде или сопровождающий сложные отраслевые решения, рано или поздно сталкивается с раздражающей проблемой. Вы запускаете глобальный поиск по текстам конфигурации с помощью привычного сочетания клавиш Ctrl + Shift + F, но вместо быстрого получения результатов платформа то и дело прерывает процесс модальным окном с требованием: «Введите пароль». Это происходит потому, что в конфигурации присутствуют закрытые паролем общие модули или модули объектов, исходный код которых защищен правообладателем.
В этой статье мы подробно разберем, почему возникает эта проблема, и проанализируем все возможные способы ее решения — от простых настроек поиска в Конфигураторе до современных стандартов групповой разработки и автоматизированной сборки (CI/CD).
Выясним причину такого поведения платформы. Когда мы запускаем глобальный поиск, Конфигуратор последовательно обходит все текстовые свойства объектов метаданных, включая модули. Как только поисковый движок натыкается на модуль, защищенный паролем, платформа пытается прочесть его содержимое. Поскольку исходный текст зашифрован, 1С приостанавливает поиск и запрашивает у пользователя авторизацию. Если нажать «Отмена», поиск продолжится, но при наличии нескольких запароленных модулей вам придется нажимать эту кнопку многократно, что крайне неэффективно при активной разработке.
Рассмотрим по шагам несколько эффективных методов, которые помогут навсегда избавиться от этого раздражающего окна.
Самое быстрое решение, не требующее изменения кода или структуры базы данных, — это правильная настройка самого инструмента глобального поиска. Разберем, как один раз исключить проблемные модули из области видимости поисковика.
ОбщиеМодули (или ту ветку, где находится ваш запароленный объект).Однако у этого способа есть существенный минус, о котором часто упоминают разработчики в больших командах: если над конфигурацией работает множество людей и новые объекты добавляются ежедневно, дерево метаданных постоянно обновляется. Чтобы не перевыбирать галочки вручную каждый раз, воспользуемся механизмом сохранения областей поиска:
Без_Защищенных_Модулей.Если над проектом трудится большая команда, постоянно сбрасывать настройки поиска неудобно. Рассмотрим отличную альтернативу — использование «заглушек» (stubs) в локальных базах разработчиков.
Суть метода заключается в том, что в рабочей базе разработки (которая развернута у программиста локально или на дев-сервере) запароленный модуль полностью заменяется его открытым аналогом, но без коммерческой логики внутри. Вместо реального сложного алгоритма мы пишем пустые функции с сохранением их сигнатуры (имен и параметров).
Посмотрим на пример того, как может выглядеть оригинальный защищенный модуль и его облегченная копия-заглушка.
Оригинальный код (скрыт паролем):
// В оригинальном модуле содержится сложный защищенный алгоритм
Функция РассчитатьСебестоимостьНоменклатуры(ПараметрыРасчета) Экспорт
// Секретные вычисления, формулы, обращения к СУБД
Возврат РезультатРасчета;
КонецФункции
Заглушка в базе разработчика (без пароля):
// Открытый модуль-заглушка для комфортной работы и поиска
Функция РассчитатьСебестоимостьНоменклатуры(ПараметрыРасчета) Экспорт
// Просто возвращаем пустое или тестовое значение, чтобы система не выдавала ошибок компиляции
Возврат Новый Структура("Статус, Результат", Истина, 0);
КонецФункции
Важное правило: этот модуль-заглушка используется исключительно в вашей локальной базе для разработки. При подготовке конфигурации к заливке в продуктивную базу (продакшн) или при отправке изменений в общий репозиторий этот файл ни в коем случае не должен заменять реальный рабочий код.
Использование паролей на модули в процессе современной групповой разработки считается устаревшей и неэффективной практикой. Сама фирма 1С рекомендует полностью отказаться от паролей в пользу механизма поставки конфигурации без исходных текстов.
Проанализируем, как работает этот механизм и почему он решает проблему глобального поиска раз и навсегда:
.cf или .cfu) платформа физически удаляет исходный текстовый код из этих модулей, оставляя там только скомпилированный байт-код (выполняемый код).В результате в продуктивной базе исходного текста закрытых модулей физически нет. Когда пользователь или разработчик в конечной базе запускает глобальный поиск по текстам, платформа просто пропускает эти объекты, поскольку искать в них нечего, и никогда не выдает окно запроса пароля. При этом логика модулей полностью сохраняет свою работоспособность.
Если ваша команда идет в ногу со временем и планирует или уже осуществляет переход на современную среду разработки 1С:EDT (созданную на базе Eclipse), то проблема модальных окон при поиске решится сама собой.
EDT кардинально отличается от классического Конфигуратора принципом работы с метаданными. В EDT конфигурация представлена в виде набора xml-файлов и обычных текстовых файлов с кодом на языке BSL. Среда разработки строит собственный быстрый индекс по всем файлам проекта.
В командах, где разработка ведется с использованием систем контроля версий (например, Git), программисты практически не используют глобальный поиск внутри Конфигуратора. Вместо этого конфигурацию выгружают в файлы.
Разберем этот процесс по шагам:
Ctrl + Shift + F в VS Code).В выгруженных файлах запароленные модули будут представлены либо в бинарном (зашифрованном) виде, либо вовсе будут отсутствовать. Внешний поисковик мгновенно найдет нужные вхождения во всех открытых модулях и формах, полностью проигнорировав закрытые файлы. Никаких прерываний, зависаний или диалоговых окон при этом не возникнет.
Если вы по каким-то причинам ограничены работой исключительно в рамках классической платформы «1С:Предприятие 8» и не используете внешние текстовые редакторы, можно прибегнуть к помощи внешних обработок. На профильных порталах для разработчиков доступно множество бесплатных инструментов для поиска и автозамены текста в модулях.
Такие обработки используют программный доступ к метаданным конфигурации. Мы можем легко написать простую процедуру обхода метаданных, которая будет анализировать тексты модулей, предварительно проверяя, не защищен ли объект паролем.
Рассмотрим пример программного обхода общих модулей с фильтрацией закрытых объектов:
Для Каждого ОбщийМодуль Из Метаданные.ОбщиеМодули Цикл
// Проверяем, есть ли у нас доступ к исходному тексту модуля
Попытка
ТекстМодуля = ОбщийМодуль.ПолучитьТекст();
// Выполняем поиск нужной подстроки в открытом тексте
Если Найти(ТекстМодуля, ИскомаяСтрока) > 0 Тогда
Сообщить("Найдено в модуле: " + ОбщийМодуль.Имя);
КонецЕсли;
Исключение
// Сюда мы попадем, если модуль запаролен или недоступен для чтения.
// Платформа не выдаст модальное окно, мы просто перейдем к следующему объекту.
ЗаписьЖурналаРегистрации("Поиск", УровеньЖурналаРегистрации.Предупреждение, , ,
"Пропущен защищенный модуль: " + ОбщийМодуль.Имя);
КонецПопытки;
КонецЦикла;
Использование подобных скриптов и обработок полностью избавляет разработчика от необходимости ручного ввода паролей во время массового анализа кода конфигурации.
Подводя итог, можно сделать однозначный вывод: для крупных команд разработчиков (от 5-10 человек и более) практика ручного запароливания модулей в базах разработки является вредной. Она мешает не только глобальному поиску по коду, но и блокирует работу инструментов статического анализа качества кода, таких как SonarQube или BSL Language Server. Роботы-анализаторы физически не смогут проверить ваш код на наличие багов, уязвимостей и критических ошибок, если он скрыт паролем.
Для организации комфортной работы рекомендуем придерживаться следующего подхода: