Исправление warning и дополнение ошибки не загрузившимися пользователями

[webrobot1]

Проблема была описана тут #229 и тут #228

Что же касательно ошибки - при обновлении из источника в CRM очень долго получать всю базу клиентов из API для понимания какой уже был загружен а какой нужно обновлять.

Вести отдельную базу уже загруженных в CRM отказ неустойчиво. В связи с этим разработчику - интегратору проще попытаться добавить новых пользователей пакетом с обновлениями по существующим, а в случае ошибки - распарить текст (он вида Customer with externalId=([^ ]+) already exists) в массиве ошибок, взять externalId не добавленных и обновить.

Однако при добавлении клиентов при указании адреса с externalId происходит проверка на существование адреса до существования пользователя и ошибки что пользователь существует нет, но есть ошибка что адрес существует без указания для какого пользователя

Добавления в ErrorResponse.php блока кода делает вывод ошибки таким

Тем не менее я надеюсь в RetailCRM исправят тот факт что существование адреса проверяется ДО существования пользователя выводя текст ошибки что адрес есть у другого пользователя, хотя он есть у того которого пытаемся добавить (даже если разработчик ведет учет добавленных в CRM пользователь в случае сбоя записи он не поймет что пользователь был уже добавлен по ошибке адреса)

[webrobot1]

Речь идет про массовую загрузку корпоративных клиентом методом this->client->customersCorporate->upload

[uryvskiy-dima]

Спасибо за PR и подробное описание.

Закрываем PR, так как предложенные изменения сейчас не нужны.

Поле failedCustomers уже добавлено в master отдельным коммитом и с более точной типизацией: array<RetailCrm\Api\Model\Entity\EntityWithExternalId>.

Изменения типов для Order::$contact и Order::$company принимать не будем. Модель Order используется не только для формирования запросов, но и для десериализации ответов API. В ответах по заказам contact и company могут приходить как полноценные сущности Customer и Company, поэтому замена их на более узкие input/relation DTO может сломать существующие сценарии чтения заказов.

Для создания/редактирования заказа нужно использовать текущие модели:

• RetailCrm\Api\Model\Entity\Customers\Customer для contact
• RetailCrm\Api\Model\Entity\CustomersCorporate\Company для company

При этом достаточно заполнить только идентификатор, например id или externalId.

Если потребуется улучшить этот сценарий, это лучше делать через разделение request/response DTO для заказов, но сейчас это не требуется. Простая замена JMS-типа в общей модели Order не подходит.

Issue также закрываем, так как в текущей архитектуре библиотеки это не считается багом.