The mass-mailing App suffered from severe issues due to its inability
to detect and handle duplicates "at the email level", and the absence
of any global blacklist system, leading to lack of user trust.
Mailing-lists typically include multiple records with the same email,
and it is critical to avoid sending them the same email several times.
A related problem is the unsubscription of an email that is present
in other records (duplicates). Opting out the first email should
automatically blacklist it for other records as well.
Ideally we should have a global blacklist table in order to
share the unsubscription requests globally across models (Leads,
Partners, Mailing-list contacts). It would also allow importing
it from other blacklist systems. (TODO for master)
This commit introduces a partial solution, made of several
small changes:
- In mail.mail: double-check that an outgoing email has the
correct status (`outgoing`) before sending it. This allows
adding emails in the queue and cancelling them before they
actually get sent.
- In crm.lead: force predictable recipients for mass-mailing,
by always using the email of the lead rather than the email
of the linked partner when there is one. This simplifies the
computation of the blacklist and seen list. Other areas in
the codebase already assume as much.
- In mass.mailing:
+ Before sending out a mailing-list batch, compute the
blacklist (all opted-out emails) and the seen_list
(emails who previously received this mail) to make
sure we only ever target valid recipients.
+ While delivering the mass-mailing, any email targeting
an address that is in the blacklist or "seen list" is
canceled before being sent. The corresponding statistics
entry is considered "not delivered".
Also updates the "seen list" continuously.
+ When a mass-mail belongs to a campaign with the
"unique AB/B testing" flag, the "seen list" is
common to the whole campaign, as an extra safety.
+ Auto-delete mass-mailing test messages sent with the
test wizard, to avoid polluting the mail_mail table
Note: this fix uses a simple regex for efficiently extracting
the blacklist in pure SQL from different models, and doing so,
assumes that each record only holds a single email
(no comma-separated adresses). This should be sufficient for
most cases. The regex:
([^ ,;<@]+@[^> ,;]+)
We generally consider this a low priority issue
as it is social-engineering based and many easier
options exist for targeting gullible users.
Nevertheless, protecting a couple of obvious pages
does not hurt.
Activity types are currently hard to find and define. In this commit we
add a menu under sales configuration to access generic or sales
related activity types (contact, lead, product, sale order).
This commit is an improvement considered as an usability fix, therefore
targeting stable version.
Activity types are currently hard to find and define. In this commit we
add a menu under project configuration to access generic or project
related activity types (task, issue).
This commit is an improvement considered as an usability fix, therefore
targeting stable version.
Currently tweaking or defining new activity types is difficult to achieve
as menu is hidden under technical settings. This commit eases the activity
types configuration by adding a menu allowing to customize them directly
under Emails section of General Settings. By the way it is renamed to
Discuss to better reflect its purpose.
This is an improvement but considered as an usability fix, therefore
targeting a stable version.
The field "# of Digits" is not accessible as soon as a chart of account
has been chosen. This should not be the case since the method
`reflect_code_digits_change` handles it.
opw-724619
Rev acd8c4de18 prevents the creation of default values for fields that
are not defined. This is too restrictive because of the following
points:
- one may want to create default values for fields that are yet to be
defined
- "fake" default fields used in res.config that do not point to real
fields
The initial scenario this revision was trying to fix is the creation of
wrong default values through studio. This scenario is still fixed, as it
concerns the last `except` branch.
The tests have been updated to reflect these changes.
Currently there are several issues with this configuration box
* default_<field> does not generate automatically ir.values anymore.
Defining default_model does not work since it is not linked to an
existing <field> in current model sale.config.settings. Checkbox
value is therefore not saved and lost at reload;
* box label is not clear as user may understand unchecking it drops
all aliases or email support. This is not the case as it is only used
to define an alias creating unassigned leads. This is a rare use case
where leads assignation is done manually;
* checking / unchecking the 'Emails' box does not have any effect on
default info alias. This is counter-intuitive as user asks to remove
the feature but it still works in background;
This commit fixes those issues by
* correctly setting the checkbox value in an ir.config_parameter so that
it is not lost anymore at reload;
* inactivating info alias by default;
* adding onchanges so that values are reset when unchecking checkboxes;
* updating string and displayed label and helps for the 'Emails' section;
* putting that Emails checkbox in advanced mode as it is a rare use case;
Steps to reproduce:
-Go to accounting dashboard
-Click on "More" in vendor bills dashboard
-Click on "bills analysis"
Bug: it opened the account.invoice.report view, which crashed.
Reason: The function get_names in addons/product/models/product.py got an empty record set
product.category(None,) and returned [False] so when joining " \ " with [False], it crashed.
The empty record set was returned when the categ_id of an account.invoice.report() was None.
opw:724783
Commit 906875fc78 (followed by commit
76be5eed44) tried to tweak to copy/paste
functionality of the editor.
Indeed, in PDF file, when copying a paragraph, a line feed is added at
each forced line break (page width end). This forced a line feed and
a new paragraph in the pasted text. The goal was to get rid of those
useless linebreaks when pasting.
The ideal solution would be to detect that the text was copied from
a PDF but it is not possible. However, this commit improves the
heuristic: if this is not plain text, then nothing is done, the content
is pasted normally. If it is plain text (like when copying from pdf),
then each line break which is surrounded by letters or numbers is
considered an useless line break and replaced by a space. This is
obviously not perfect but the previous implementation was really wrong
(it was removing line breaks which were not preceeded by punctuation in
all cases, which was removing lots of useful line breaks).
Note: this commit also fixes a bug -> text was not able to be pasted
with Internet Explorer.
opw-715920
This commit partially reverts 5b4f7c1 where `fields_view.fields`
had been replaced by `fields`, which could have been set to all
fields in the model.
This modification can sometimes lead to a problem, during the
fields value transformation. The ID, which wasn't given previously
is now parsed. When creating a new record, the field ID is not an
integer but a string (representing the virtual ID). If the field
is in the arch, it will be postprocessed
(see https://github.com/odoo/odoo/blob/saas-11/addons/web/static/src/js/framework/data_manager.js#L201)
and its type will become `id`. As this postprocessing is not done
if the field in the view, the parsing was on the original type
(integer) and not the special id type.
- Create an invoice with two products
- Each line has a long description (spread on 2 lines)
- The second line has a negative value
- Print the invoice (PDF)
The amount spreads on two lines, split as:
$ -
1,000.00
This is due to the wkhtmltopdf version with patched QT. Unfortunately,
upgrading to the latest version 0.12.4 doesn't solve the problem.
The solution is to replace the '-' by a non-breakable hyphen.
opw-711002
When using the iframed editor with multilang selector (present if there
is another lang installed than en_US) an "English" language was present
before each translation language.
opw-696891
Fullcalendar expect as `start` and `end` property of an event object:
> When specifying Event Objects for events or eventSources, you may
> specify a string in IETF format (ex: "Wed, 18 Oct 2009 13:00:00 EST"),
> a string in ISO8601 format (ex: "2009-11-05T13:15:30Z") or a UNIX
> timestamp.
(as seen in https://fullcalendar.io/docs1/event_data/Event_Object/)
Before this commit we could for example in arabic provide an invalid
date string "٢٠١٧-٠٣-١٦ ١٦:٠٠:٠٦" instead of "2017-03-16 16:00:06".
This commit solves this by always providing fullcalendar an ISO8601 date
string.
opw-705752
The transcoder (which transforms stylesheet rules to inline style) did
some compression of the padding and margin css properties to not always
have margin-top + margin-right + margin-bottom + margin-left.
This could cause an issue when the value of margin or padding contained
an initial or inherit value because browsers (at least firefox and
google chrome) doesn't allow it. Thus the preview could for example have
bigger veritcal spaces arround `<p />` tag than what was seen when
editing.
With this fix instead of invalid:
margin:initial initial initial initial
we have:
margin:initial
And instead of invalid:
margin:initial 5px 6px 7px
we have:
margin-top: initial; margin-right: 5px; margin-bottom: 6px; margin-left: 7px;
opw-706535
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Test cases contributed by @jir-odoo
- Create a product with price tax included
- Create Repair order
- Add the product in tabs "Operation" or "Invoicing"
The tax is added twice in the total.
opw-709608
- Create a stockable product, create a SO selling 1 unit.
- Confirm the SO, validate the Picking 1 => delivered qty is 1
- Return Picking 1 and validate Picking 2 => delivered qty is 1
- Return Picking 2 and validate Picking 3 => delivered qty is 2
The delivered quantity should remain 1.
opw-715685
We sometimes use in Odoo a One2many field with an inverse Integer
field instead of a usual Many2one.
This allow for example in several instances to have a "Many2one" which
can be reference from several models, eg:
Model Ranking:
name = String field
res_id = Integer field
res_model = String field
Model Toy:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Toy]
Model Tool:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Tool]
This enable us to have a shared feature between otherwise unrelated models.
But there was several issue when searching on these One2many:
1) if the Integer Many2one was not stored (eg. it came from an inherits) on
the searched model, this could lead to an error.
2) when we searched:
- by IDs (rank in ['55']) with at least one id not respecting the domain
- by IDs with a negative operator
- with a negative operator on unfound string (rank != "no rank has this")
- with a false value (rank = False)
we would not apply the One2many domain (eg. res_model == Toy) and thus
possibly getting Toy 3 errenously because a Tool 3 was found without
the domain being applied.
This fix modify the search on One2many and for:
1. if the inverse is an Integer not stored field instead of Many2one
manage it.
2. if the field is an Integer field instead of Many2one and there is a
domain on the One2many: apply the domain on the inverse model found.
So only some search on One2many with a domain whose inverse field is an
Integer could be impacted.
This would also be nice to have for all One2many with a domain but the
probability of it being useful versus risk for performance is not judged
high enough.
opw-710508
Commit 00bd7274c4 introduced speed improvements when
sending emails through batching and reusing an SMTP connection for a
given batch.
However exception management was slightly changed during that patch.
Previously to this patch all errors in the sending process were considered
as MailDeliveryException, except for MemoryError and psycopg errors.
However now mail_mail.send() may raise another kind of exception in the
SMTP connect process. Moreover a raise_exception parameter allows to
choose to either raise an exception, or just set emails in exception
state without raising an error. However since the patch it is not taken
into account correctly.
This leads to several issues, notably
* auth_signup waits for a MailDeliveryException when sending a password
request email. A badly configured SMTP server leads to a connection
error that is not caught. This prevents creating users, which could
be annoying.
* chatter does not handle exceptions as notification emails are sent
using raise_exception being False. Having an issue in the connect
process crashes the chatter.
This commit fixes the exception management so that it behaves like
before the patch.
- Create Product A with a BOM which depends on a product with tracking
"By Unique Serial Number" (Product B).
- Create a MO for Product A
- In the "Register lots" wizard, add two lines for "Product B", with the
same serial number.
Nothing prevents the user to do it, even when the inventory is posted.
opw-709888
The method `write` calls `env['res.lang']._get_installed`, which is ormcached.
After activating a language with `write`, one must invalidate the ormcache.
When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
In stable version, the right fix would be to put an attribute ondelete=cascade
on the field model of ir.model.constraint.
In 10.0, the ir.model.constraint are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
Odoo Translation Bot