Automation email needs to be active in order to be sent.
If we allow resending to inactive emails, we would need to activate them first,
but this could be an unexpected side effect. And activating may cause sending other paused tasks as a side effect.
I expect the email to be active in the majority of cases, so users should not meet this notice very often.
[MAILPOET-6241]
We removed the return value to prevent us from using it to check if there were recipients.
It is not 100% reliable for that purpose because it returns 0 for a repeated call.
[MAILPOET-6346]
When reactivating a newsletter with many queues (e.g., a welcome email with a long history)
NewsletterEntity::getQueues may fail because it attempts to fetch all queues and instantiate
many entity objects.
In this commit, I optimize this by looking only into unfinished queues.
getUnfinishedQueues look for where countToProcess is higher than 0.
We set the count for welcome emails when we create a new queue
see f1ffc77bf3/mailpoet/lib/Newsletter/Scheduler/WelcomeScheduler.php (L140)
[MAILPOET-6310]
This updates some of the segment listing messages to include the name of
the segment to avoid confusion, and allows for the possibility that
bulk actions will work for some segments but not all, in which case we
need to show both success and error messages.
MAILPOET-5395
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]
This is only tangentially related to this ticket. I noticed during
testing that the filter segment tag was not showing up in listings for
standard newsletters that were drafts or scheduled. This is because
options weren't included in the response for standard newsletters.
MAILPOET-5512
