Based on a suggestion during the review of the PR, it was decided that
it makes more sense for the code that was created as
SendingQueueEntity::toArray() tp be moved to
SendingQueuesResponseBuilder::build(). It is used only to build the
format that is send in the API response.
[MAILPOET-4368]
Since SendingQueue::add() still uses Paris, it was running into some
problems caught by our integration tests since some Sending methods
where refactored to Doctrine. The issue was that we started loading some
Doctrine entities earlier, then Paris code inside SendingQueue::add()
would change the same rows, causing the Doctrine entities to contain
stale data. To workaround this problem, in this commit, we are making
sure that the Doctrine entities are refreshed after they are changed by
Paris.
I considered refactoring SendingQueue::add() to use Doctrine but I
wasn't sure what to do with SendingTask::create() and
SendingTask::createFromQueue() so I decided to take a different
approach.
[MAILPOET-4368]
This was the easiest way to fix failing integration tests related to
updating some Sending methods to use Doctrine instead of Paris. Using
Paris in SendingQueue to update the database was creating a state where
Doctrine had stale data and this was causing the tests to fail.
[MAILPOET-4368]
When users click send email in UI, they need to wait a minute or more to
see some emails started going out.
This commit adds additional trigger into sending queue API.
If emails is set to send it triggers Action Scheduler immediately.
Users will get immediate feedback that emails are sending.
[MAILPOET-4274]
- Rename validator to newsletterValidator for clarity
- Add validation for ALC content
- Refactor tests to use data factory for consistency and to avoid
validation issues
- Add separate tests for NewsletterValidator service
- Add test helper for retrieving service with private properties
overridden by name
[MAILPOET-4236]
