- When checking if a recipient has already received a mass mailing, the
record model for the recipient was not checked.
Which leads to false positives.
The default value for failure_type was the 'NONE', instead of being
simply False/NULL. This represents a significant waste of tablespace
with no added value.
Switching to true NULL value for representing the absence of error
also save some precious time during database upgrades on databases with
large numbers of emails.
While fixing the values for failure_type, also fixed a few typos and
untranslated strings.
See original feature at 133eeb1bbf
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
A mass mailing can be considered both as bounced and opened. This can
occur with some email providers, such as Gmail. Indeed, Gmail sends
out-of-office replies to the `Return-Path` address, which is also used
for bounced emails. Therefore, it is not possible to determine
accurately if a message sent to to the `Return-Path` is a genuine
bounced email, or an out-of-office reply.
However, if the recipient opens the email, it is possible to determine
that the bounce was counted incorrectly. In this case, we empty the
`bounced` field. Similarly, we only write on the `bounced` filed if the
`opened` field is empty. This could occur if the recipient opens the
email before the out-of-office reply is received.
As a bonus, we also make sure to avoid updating the status if no route
was found. No route means that the email was bounced, so no reason to
set it as opened.
opw-1869957
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
These two columns are used to compute the mailing statistics, to be
displayed in the kanban dashboards. Adding them makes the dashboards
a lot faster on large databases (e.g. a few milliseconds instead of
several seconds)
The kanban view displays mailing statistics for all mailings that are
sending or done. To compute these statistics, it uses the `total` as the
expected number of emails to send. This `total` used to be computed as
the number of records matching the mailing filter.
This is both slow (filters are seldom written in an optimized way), and
incorrect because the recipients were frozen when the email was sent.
The number of matching records may have changed since then.
To fix both problems, introduce a new `expected` computed field that
simply returns the number of emails that were put in queue at the time
of sending, and thus represent the real number of expected emails.
This field is computed along with the rest of the statistics.
The framework supports a special `group_expand` attribute on fields,
to provide a helper method that expands the list of columns in a
read_group (typically meant to display empty columns in kanban views)
See rev. 580e78ad37
More efficient, and less code.
Christophe Simonis