Коробочный модуль после обновления: что проверить

Задача

Чек-лист проверки коробочного модуля после обновления портала: автозагрузка, права, события, кеш, агенты и миграции.

Сценарий обычно появляется в коробочной доработке, когда нужно быстро решить практическую задачу, но при этом не сломать обновления, права и штатную логику портала.

Ключевые вещи в этой теме: автозагрузка, права, события. Именно их стоит проверить первыми, прежде чем менять код.

Как это устроено

В коробке важно отделять штатный API, контекст запуска и прямую правку файлов.

Если код выполняется внутри портала, у него есть контекст Битрикса: подключённые модули, текущий пользователь, права, кеш и события. В CLI, cron или внешнем скрипте часть этого контекста нужно создать вручную.

Для CRM, Диска, календаря, пользовательских полей и модулей лучше начинать со штатных API. Прямые SQL-запросы и правка файлов ядра подходят только как крайняя диагностика, а не как основной способ доработки.

Если поведение отличается под администратором и обычным сотрудником, почти всегда нужно отдельно проверить права, категорию сущности, владельца записи и пользователя, от имени которого выполняется код.

Рабочий подход

Сначала зафиксируйте контекст, потом проверяйте API и только после этого меняйте данные.

Проверьте, где выполняется код: веб, CLI, cron, агент, обработчик события или iframe приложения.
Подключите нужные модули явно и обработайте ситуацию, когда модуль недоступен.
Сначала выведите тестовые данные или SQL, затем выполняйте изменение.
Для боевого портала добавьте логирование результата и ошибок.

Частые ошибки

Большинство проблем появляется из-за неверного контекста или обхода штатной логики.

Код проверяют только под администратором, а потом он не работает у сотрудников.
Доработку кладут в /bitrix или в перегруженный init.php вместо /local или модуля.
Ошибки не логируются, поэтому после cron, агента или события непонятно, запускался ли код вообще.
Данные меняют напрямую, минуя операции, события, права, индексы и кеш.

Минимальный пример

Пример показывает базовую форму. ID, пути, названия модулей и поля нужно заменить под свой портал.

Чек-лист:
[ ] Модуль есть в списке установленных.
[ ] include.php не падает с fatal error.
[ ] Классы из lib автозагружаются.
[ ] Обработчики событий зарегистрированы.
[ ] Агенты есть в списке и выполняются.
[ ] Таблицы и поля модуля на месте.
[ ] Права доступа работают для обычного сотрудника.
[ ] Настройки модуля сохранились.
[ ] Кеш очищен только после фиксации проблемы.
[ ] Основной бизнес-сценарий прошёл полностью.