Как повесить onBeforeAdd на DataManager в 1С-Битрикс и отменить add через addError?

OrderLogTable уже есть, add() отработал - а CREATED_AT пустой, PRICE с нулём проходит, на форуме советуют "зарегистрируй в init.php". Для onBeforeAdd внутри *Table регистрация не нужна: ядро вызовет метод само. Ниже - 9 событий D7 ORM, EventResult с modifyFields и addError, отличие от AddEventHandler. Вы повесите onBeforeAdd, отмените невалидную запись и подпишетесь на сущность снаружи.

События DataManager - это хуки внутри жизненного цикла add/update/delete. onBeforeAdd и onBeforeUpdate принимают Entity\Event и возвращают EventResult: modifyFields нормализует поля, addError останавливает операцию. Метод onBeforeAdd пишется прямо в *Table, имя строго onBeforeAdd, не onBeforeItemAdd. Для DateTimeField нужен объект Bitrix\Main\Type\DateTime, не строка date(). Внешняя подписка - через ORM\EventManager на класс сущности, это не то же самое, что AddEventHandler для iblock или sale.

Материал про коробочную CMS "1С-Битрикс: Управление сайтом", не про облачный Bitrix24. ORM (Object-Relational Mapping) - слой D7, где PHP-класс *Table связан с таблицей MySQL. Если таблицы ещё нет - сначала создайте *Table и getMap, затем возвращайтесь сюда за событиями.

Выберите, когда нужны события D7 ORM, а когда хватит CRUD или AddEventHandler

Бизнес-правила можно размазать по контроллерам, админке и компонентам - но тогда каждый новый вход в данные обходит проверку. События *Table возвращают контроль туда, где живут поля.

Модульные обработчики в init.php разобраны в гайде по AddEventHandler. Highload-справочники с похожим API событий - в материале про HL CRUD. Каркас модуля, куда вешать внешнюю подписку в include.php, - в инструкции по своему модулю.

Делайте: держите проверки данных в onBefore*, побочные эффекты (почта, кеш) в onAfter*. Не делайте: не путайте OnBeforeAdd ORM с AddEventHandler('iblock', ...) - разные менеджеры и разные параметры события.

Разберите карту 9 событий DataManager: onBefore, on, onAfter

У каждой операции add, update и delete - три фазы. Ядро документирует их в операциях с сущностями ORM.

Схема add():
OnBeforeAdd (modifyFields, addError, unsetFields) → OnAdd → OnAfterAdd (уведомления, кеш, лог без тяжёлого SQL)

EventResult::modifyFields и unsetFields работают только в onBefore-фазе. addError на onBefore прерывает add() или update(): Result::isSuccess() вернёт false, INSERT не выполнится.

Делайте: тяжёлую выборку связанных строк выносите из onAfterAdd в отдельный сервис или агент. Не делайте: не кладите в onAfterAdd цикл с getList по каждой связанной таблице - получите N+1 и тормоза на массовом импорте.

Настройте onBeforeAdd и onBeforeUpdate в классе *Table

Типичная ошибка с форума dev.1c-bitrix.ru: метод назван onBeforeItemAdd или modifyFields передали как ['fields' => ['CREATED_AT' => ...]]. mergeObjectFields ждёт плоский массив полей сущности, без вложенного ключа fields.

1. Откройте OrderLogTable.php в lib/ модуля (после создания *Table).
2. Добавьте статический метод onBeforeAdd с сигнатурой public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event).
3. Создайте $result = new \Bitrix\Main\Entity\EventResult() и прочитайте $fields = $event->getParameter('fields').
4. Проверьте PRICE: при значении <= 0 вызовите $result->addError(new EntityError('...')) и return $result.
5. Нормализуйте CREATED_AT через $result->modifyFields(['CREATED_AT' => new \Bitrix\Main\Type\DateTime()]).
6. Протестируйте OrderLogTable::add(['PRICE' => 0]) - isSuccess() false, текст ошибки из addError.

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event)
{
    $result = new \Bitrix\Main\Entity\EventResult();
    $fields = $event->getParameter('fields');

    if (isset($fields['PRICE']) && (float)$fields['PRICE'] <= 0) {
        $result->addError(
            new \Bitrix\Main\Entity\EntityError('PRICE должен быть больше нуля')
        );
        return $result;
    }

    $result->modifyFields([
        'CREATED_AT' => new \Bitrix\Main\Type\DateTime(),
    ]);

    return $result;
}

Для onBeforeUpdate тот же шаблон: unsetFields запрещает менять поле (например ISBN после публикации), FieldError привязывает ошибку к конкретному полю. В старом API правили $arFields по ссылке; в D7 ORM меняют только через EventResult.

Делайте: возвращайте EventResult из каждого onBefore-метода. Не делайте: не передавайте в modifyFields строку date('Y-m-d H:i:s') для DatetimeField - ядро ожидает Type\DateTime.

Сравните validators в getMap и бизнес-правила в onBefore

Встроенные валидаторы (Length, RegExp, Range, Unique) в getMap срабатывают при checkFields до записи - удобно для статичных ограничений. Правило "PRICE не ниже закупки из связанной таблицы" или "запрет смены статуса без роли" - в onBeforeUpdate, иначе дублируете closure в add и update.

• getMap + validators: формат email, длина артикула, уникальность кода в таблице.
• onBeforeAdd/onBeforeUpdate: контекст пользователя, связанные сущности, автозаполнение служебных полей.
• onAfter*: побочные эффекты после успешной записи, не валидация.

Делайте: одно бизнес-правило - одно место в onBefore*. Не делайте: не копируйте одну и ту же проверку в компонент, REST и *Table - пропустите путь, данные протекут.

Подпишитесь на событие снаружи через ORM\EventManager

Когда правку *Table в чужом модуле делать нельзя, подписка в include.php своего модуля:

use Bitrix\Main\ORM\EventManager;
use Bitrix\Main\ORM\Data\DataManager;
use Mycompany\Custommodule\OrderLogTable;

EventManager::getInstance()->addEventHandler(
    OrderLogTable::class,
    DataManager::EVENT_ON_BEFORE_ADD,
    ['\\Mycompany\\Custommodule\\Handler', 'onBeforeOrderLogAdd']
);

Имя события - константа EVENT_ON_BEFORE_ADD, класс - OrderLogTable::class, без суффикса Table в строке события. Обработчик получает тот же Entity\Event и возвращает EventResult с modifyFields или addError.

Делайте: в uninstall или при отключении модуля вызывайте removeEventHandler. Не делайте: не регистрируйте один и тот же обработчик при каждом хите init.php без проверки - дубли сработают.

Пройдите чек-лист перед выкладкой на prod

1. Проверьте имя метода: onBeforeAdd, onBeforeUpdate, onAfterAdd - регистр и префикс on.
2. Убедитесь, что add() вызывается на том же *Table, где лежит обработчик.
3. Прогоните add/update/delete на staging: isSuccess(), тексты ошибок, автозаполнение полей.
4. Сделайте onAfter-обработчики идемпотентными: ядро может отправить событие дважды (legacy Entity\Event и ORM\Event).
5. Оставьте одну ответственность на событие - валидация в onBefore, уведомление в onAfter.

Нужна помощь с внедрением событий в боевой модуль - обсудим задачу. Похожие кейсы по Bitrix - в портфолио.

Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: документация ORM entity-operations, API DataManager, урок 2244, форум topic120789.

Частые вопросы