Email-уведомления о заказе уходят на устаревший email из msCustomer вместо email из формы заказа

[biz87]

Описание

Email-уведомления о заказе (customer-channel) уходят на msCustomer.email, а не на email, указанный пользователем в форме этого конкретного заказа. Это проблема для типового сценария «один браузер, несколько заказов от разных людей».

Воспроизведение

1. Открыть сайт в приватной вкладке
2. Оформить заказ с email = alice@example.com, дождаться email-уведомления — уходит корректно на alice@example.com
3. Не закрывая вкладку (session token тот же) оформить второй заказ, в форме указать email = bob@example.com
4. Ожидание: письмо о втором заказе уходит на bob@example.com
5. Факт: письмо уходит на alice@example.com

Причина

Controllers/Customer/Customer.php::getOrCreate() находит существующего msCustomer по token (сессионный ID) — и не обновляет email/phone из новых данных формы. Это может быть осознанным решением (чтобы не затирать данные клиента), но оно приводит к багу в отправке уведомлений.

Services/Order/OrderStatusService.php::getCustomerRecipient() (строки 204-262) при сборе recipient для notification-канала смотрит в:

1. msCustomer.email / .phone (строки 220-228)
2. modUserProfile как fallback (строки 242-256)

msOrderAddress — самый свежий источник контактов, относящийся к этому заказу — не используется вообще. Email, который пользователь только что ввёл в форму, не попадает в recipient.

Предложение

В OrderStatusService::getCustomerRecipient() поставить msOrderAddress первым источником — как контакты, прикреплённые именно к этому заказу. msCustomer и modUserProfile становятся fallback'ом, когда в адресе пусто (backwards-совместимо для старых заказов, где адрес мог не сохраняться).

Псевдокод:

```php
protected function getCustomerRecipient(msOrder $msOrder): ?array
{
$recipient = ['type' => 'customer', 'email' => null, 'phone' => null, 'telegram_chat_id' => null];
$hasContact = false;

// 1) Order-level address — самые свежие контакты, относящиеся к этому заказу
/** @var msOrderAddress|null \$address */
\$address = \$msOrder->getOne('Address');
if (\$address) {
    if (\$email = \$address->get('email')) { \$recipient['email'] = \$email; \$hasContact = true; }
    if (\$phone = \$address->get('phone')) { \$recipient['phone'] = \$phone; \$hasContact = true; }
}

// 2) msCustomer — fallback, если в адресе пусто. Плюс всегда для telegram_chat_id/customer.*
\$customer = \$msOrder->getOne('Customer');
if (\$customer) {
    \$recipient['customer'] = \$customer->toArray();
    if (empty(\$recipient['email']) && \$customer->get('email'))  { \$recipient['email'] = \$customer->get('email'); \$hasContact = true; }
    if (empty(\$recipient['phone']) && \$customer->get('phone'))  { \$recipient['phone'] = \$customer->get('phone'); \$hasContact = true; }
    \$ext = \$customer->get('extended');
    if (is_array(\$ext) && !empty(\$ext['telegram_chat_id'])) {
        \$recipient['telegram_chat_id'] = \$ext['telegram_chat_id'];
        \$hasContact = true;
    }
}

// 3) modUserProfile — последний fallback для email/phone, без изменений
// ...

return \$hasContact ? \$recipient : null;

}
```

Почему именно такой порядок

• Заказ — это source of truth. Что юзер ввёл на checkout'е — то и контакты уведомления о заказе. Менять email в msCustomer каждый раз опасно (сломает merge клиентов по email и CRM-интеграции).
• Telegram/SMS логика не ломается. telegram_chat_id по-прежнему читается только из customer-extended (в адресе его нет — это отдельный канал доставки).
• Manager-recipient не трогаем. getManagerRecipient() (строки 264+) никак не зависит от заказа, читает системные настройки — остаётся как есть.

Обратная совместимость

• Старые заказы, где в msOrderAddress email пустой, продолжат работать через fallback на msCustomer — поведение не меняется.
• Для заказов, где email в форме совпадает с email в customer'е — поведение не меняется.
• Изменится только тот самый сценарий, который сейчас багован.

Альтернатива на одном плагине (временное решение, пока не смержено)

Перехват через событие msOnBeforeSendNotification с мутацией $recipient['email'] из $notification->getOrder()->getOne('Address')->get('email'). Работает точечно, не требует правки ядра, не меняет поведение если email в адресе отсутствует.

Затронутые файлы

• core/components/minishop3/src/Services/Order/OrderStatusService.php:204-262 (getCustomerRecipient)

Дополнительно

Отдельным вопросом — стоит ли также обновлять msCustomer.email при новой submission (merge стратегия). Но это другой уровень решения и зависит от бизнес-правил (привязка клиента к единственному email vs. история контактов). Пока — ограничиваемся корректировкой resolver'а для уведомлений.

[biz87]

Update: второй корневой баг обнаружен логированием

После добавления диагностического плагина на `msOnBeforeSendNotification` + `msOnAfterSendNotification` видно что плагин в принципе не может подменить recipient — архитектурное ограничение в `NotificationManager::send()`.

Лог реального заказа #71

```
[ms3-diag] ADD order#71 key=email value=savin.nikolay87@gmail.com | trace-src=https://regionkip.ru/cart/
[ms3-diag] BEFORE order#71 type=customer recipient.email=biz87@mail.ru
[ms3-diag] BEFORE order#71 address.email=savin.nikolay87@gmail.com ← правильный
[ms3-diag] BEFORE order#71 customer.id=8 customer.email=biz87@mail.ru ← устаревший
[ms3-diag] BEFORE order#71 MUTATED recipient.email: biz87@mail.ru -> savin.nikolay87@gmail.com
[ms3-diag] AFTER order#71 type=customer final.recipient.email=biz87@mail.ru ← подмена проигнорирована
```

Плагин мутировал `$recipient['email']`, но до канала дошёл оригинал.

Причина

`NotificationManager.php` строки 72-77:

```php
$eventResult = $this->modx->invokeEvent('msOnBeforeSendNotification', [
'notification' => $notification,
'recipient' => &$recipient, // ← бесполезное by-ref
'recipientType' => $recipientType,
'channels' => &$channels,
]);
```

`modX::invokeEvent()` внутри делает `extract($params)` в scope плагина — в плагине появляется новая локальная переменная `$recipient`, не связанная с оригиналом. By-ref в массиве параметров ничего не даёт.

Плюс ниже (строки 81-91) менеджер читает только `$pluginResult === false / 'cancel'` и `$modx->event->output === false`. `$modx->event->returnedValues` не читается — штатного способа вернуть модифицированный recipient нет.

Итог: в текущей архитектуре плагин может только отменить отправку, но не может её изменить — значит workaround через `msOnBeforeSendNotification` невозможен. Остаётся только фикс в ядре.

Предложение — второй патч

К фиксу `getCustomerRecipient` (уже описан выше) добавить в `NotificationManager::send()` чтение `returnedValues` после invokeEvent:

```php
$eventResult = $this->modx->invokeEvent('msOnBeforeSendNotification', [
'notification' => $notification,
'recipient' => $recipient,
'recipientType' => $recipientType,
'channels' => $channels,
]);

// Allow plugins to override recipient / channels via $modx->event->returnedValues
if (isset($this->modx->event->returnedValues) && is_array($this->modx->event->returnedValues)) {
$out = $this->modx->event->returnedValues;
if (isset($out['recipient']) && is_array($out['recipient'])) {
$recipient = array_merge($recipient, $out['recipient']);
}
if (isset($out['channels']) && is_array($out['channels'])) {
$channels = $out['channels'];
}
}
```

Убрать косметическое `&` из параметров (`&$recipient`, `&$channels`) — оно только вводит в заблуждение.

Что даёт

• Основной баг (resolver тянет email из msCustomer) → фикс в `getCustomerRecipient`, делает `msOrderAddress` primary-источником
• Плагинная мутация recipient → фикс в `NotificationManager`, плагин сможет вернуть `['recipient' => [...]]` и это реально долетит до канала

Оба патча независимы и дополняют друг друга: первый решает конкретный кейс «несколько заказов в сессии», второй открывает штатный extensibility point для уведомлений.

Затронутые файлы

• `core/components/minishop3/src/Services/Order/OrderStatusService.php:204-262` — primary fix
• `core/components/minishop3/src/Notifications/NotificationManager.php:70-95` — extensibility fix