Как поймать событие изменения реквизита CRM

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

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

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

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

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

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

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

<?php

use Bitrix\Main\EventManager;

EventManager::getInstance()->addEventHandler(
    'crm',
    'OnAfterCrmRequisiteUpdate',
    static function ($id, $fields) {
        file_put_contents(
            $_SERVER['DOCUMENT_ROOT'] . '/local/logs/requisite.log',
            print_r(['ID' => $id, 'FIELDS' => $fields], true),
            FILE_APPEND
        );
    }
);