ну вот же в первом ответе

I'd replicate the model without the media, then loop over all the media and use the new instance's addMedia method to make sure the files are added correctly.

$product->media->each(function (Media $media) {
   $newProduct->addMedia($media->getPath())
       ->preservingOriginal()
       ->withProperties($media->toArray())
       ->toCollection($media->collection_name);
});

только надо проверить с дебаггером, правильно все работает

ну и глянуть методы spatie

возможно в той же теме

v7 will have dedicated copy and move methods for this.

спасибо!

спасибо 👍

создавать отложенную джобу, внутри которой будут отправляться все недавние уведомления
+глянь либу https://github.com/coderello/laravel-relevance-ensurer

это на случай, если к моменту отправки джобы уведомлений уже не останется

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

Всем привет.
Есть такая структура:
- апишка (со своими юнит тестами)
- сдк для работы с апишкой (со своими юнит тестами)
- сам проект, который юзает сдк (он оперирует созданными из другого места апишными сущностями, из самого проекта их создать нельзя)

Собственно, вопрос, как писать аццептанс тесты на проекте? Вижу 2 варианта
1) Замокать гейтвей из сдкшки и написать много красивых положительных и отрицательных тест-кейсов.
2) Создать на апишке тестовый роут для создания сущности. Ничего не мокать, работать, как будто это обычная реальная сущность. Тесты будут проходить медленнее и будут менее гибкими (чем моки), но это будет проверка того, что все куски работают вместе.
Как кто поступает в подобных ситуациях?

Как по мне лучше мокать, тестовый роут как и другие переписовання кода под тесты это имхо плохо

Понял, спасибо! То есть, это вполне ок, что нет ни одного теста, который бы тестил именно интеграцию всех 3х кусков вместе? Теоретически, конечно, не будет ситуаций, при которых кто-то сломает стейбл версию апишки. А новую версию можно тестить в ручном режиме. Но все равно как-то непривычно 🙂

я бы 2 наверное сделал, только вметого тестового роута подключил бы тестовую бд  к апи с известными данными. Не думал о таком варианте?

Думал.. О сидере на апишке, который бы сеттил тестовые известные данные. Тот же вариант, так как на ci у нас все происходит на чистой базе. Но я хз, насколько такой подход удобней роута. С роутом вроде как чуть наглядней выглядит тест:
- создали чет (юзая роут)
- выполнили действия
- проверили результат
А если делать без роута, то первый этап как бы неяно подразумевается. Еще поинт в том, что в подходе с роутом я в каждом тесте буду работать с новой сущностью, а в подходе с базой - с одной. И если я с ней что-то сделаю в одном тесте - в другом ее не будет.

еще актуально?

Yep