When using the "Send & Print" functionality, if the user adds an attachment, the latter won't be linked to the record. To reproduce the error: 1. Open a posted invoice 2. Send & Print 3. Attach a file > Select a file on your device 4. Send the email Error: The invoice's PDF is added to record's attachments, but not the other file (from step 3). When the module selects the attachments that need to be linked to the invoice, it only keeps the ones currently linked to `mail.compose.message`: https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725 This is correct when the user creates a message directly in the chatter. However, when the mail is created thanks to `Send & Print` functionality, the attachment is linked to `account.invoice.send`. Another flow have a similar issue: from invoices list, select few ones, Action > Send & Print: the generated PDF won't be attached to their invoice. In such a situation, here is the source of the problem: https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367 There isn't any information about the invoice, therefore it is not possible to linked the attachment to it. OPW-2438457 closes odoo/odoo#71425 X-original-commit: e87f599d4eb22250b628d650b9f59b54db8d043c Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The optimization 2ccf0bd0dc does not take into account that to
"unblacklist" a user, you have the archive the mail.blacklist record so
only mail.blacklist active records need to be taken into account.
Added test without the fix fails with:
AssertionError: False is not true : MailTrace: email
test.record.02@test.example.com (recipient res.partner(), state:
sent, record: mailing.test.blacklist(166,)): found 0 records (1 expected)
opw-2536304
closes odoo/odoo#71239
X-original-commit: 8ffd82249728b79959cfa61490730991a2b339d6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit: When someone sends mail with help of mail_composer(mail.compose.message) without having a mail template set, mail is not deleted after being sent (and causes unwanted/unexpected burden on DB). This bug was introduced with commit[1], where auto deletion was disabled if template is not set on the composer. After this commit: If there is no mail template set on the composer, or if the template is set and 'auto_delete' is enabled on that template, the mail sent from composer will be deleted after being sent successfully. A context key is added to allow controlling this behavior. It is notably use to check query counters differences. commit[1] - https://github.com/odoo/odoo/commit/8a026e26c6ae25e3fdb5369a7fa3343d70fab782#diff-898a3d5c08a567c1a7b82c026a213d796e850e376cbdb1c9e7936409f440d37aR257 Task id: 2484915 PR odoo/odoo#68870 Original Pr #68403 X-original-commit: 05ad6c477f7da2a495e5baf5b4629323b9d11fa0 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Connect with Admin - Go to Contacts, edit himself by adding a Private Address - Create an Internal User without "Access to Private Addresses" right (i.e. User X) - Go to any app implementing chatter (i.e. Sales) - Create a SO - Add the created Private Address as follower - Make sure User X can access the record (i.e. Sales: Administrator) - Connect with User X and open the SO An Access Error is raised while trying to fetch data about the followers. This commit prevents to: - add a private address as follower of a record - add a private address as Recipient in full composer - propose private addresses when adding a mention to a partner opw-2428936 closes odoo/odoo#65933 Task-id: 2463622 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The `{'infos': 'mail_sent'}` property returned by `action_send_mail()`
was apparently unused, and orginally intended for debugging, according
to its author.
Since previous commit adds a warning for such unknown properties,
removing it entirely keeps the testsuite green. And it's cleaner
than explicitly allowing that extra key, since it's unused.
closes odoo/odoo#62581
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Courtesy of Transifex's translators for reporting bad/unclear sentences. closes odoo/odoo#62539 Related: odoo/enterprise#15032 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
As default is called numerous times with sometimes all fields, sometimes
only one field we have to ensure we avoid computing and setting unnecessary
or wrong values. We suspect this comes from default_get being called more
often at creation time since Odoo v14.
Default values for some fields in mail composer are dependent on each other.
Especially composition mode and model / res_id(s) are important for some
fields as behavior is not the same in comment or mass mail mode (subject
set / not set, template values rendered / displayed raw, ...).
Especially subject is wrongly computed in mass mail mode. For example use a
mass mail composer action on leads without template. Indeed a default_get
is called on subject alone. As web client adds active_model / active_id
automatically default returns a value for subject while it should not as
other values (model, res_id) are not asked and therefore not correctly
computed. It makes composer compute values in comment mode while it should
stay in mass mode.
In this commit we fix that behavior by
* computing only requested values (better match returned values and asked
fields);
* avoid computing values if context values are not given (model, res_id or
res_ids, composition_mode);
Task ID-2390314
PR odoo/odoo#62061
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Courtesy of translators Reexport .pot of modified modules closes odoo/odoo#61002 Related: odoo/enterprise#14485 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
due to breaking changes in https://github.com/odoo/odoo/commit/bf32b22ce247c19fda94ded74e37f7c6120ce2c4 and especially the part: "NOTE 1. If the default_get within the onchange returns a value for a field that is not in the view, we ignore it, and it won't be saved. Before, that value was kept and sent upon save. This change in behavior may prove problematic, although the overall risk is small. Decision has been made to keep heavy comments and code snippets if we were to revert back somehow to the previous situation." the wizard to sending failures email was broken as the field partner_id which is required was not present in the view and was thus ignored by to web client when calling 'create'. closes odoo/odoo#58299 Task: 2341593 Closes: https://github.com/odoo/odoo/pull/58299 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
For large lists of blocked emails, the time taken to load the records in
cache becomes prohibitive. For instance on a sample blocklist of 600k
entries, the `search([])` to load them could take 80-90s to run!
And this toll is taken every time the mail composer processes an email
batch in mass-mailing mode. Technically, most of the time is spent
iterating on the list of ids many time, in order to prefetch fields
into cache by determining what's missing.
Loading the contents of the list in raw SQL takes a fraction of that
time (400ms vs 90s).
Subsequently using a set for lookups in that blocklist is also much
faster (average time complexity O(1) vs O(n)).
Example: looking up an item in a 600k-entry blocklist is easily 5
orders of magnitude faster!
```
In [1]: blocklist = set(x[0] for x in self._cr.fetchall())
In [2]: len(blocklist)
Out[2]: 634610
In [3]: self._cr.execute("SELECT email from mail_blacklist")
In [4]: blocklist = set(x[0] for x in self._cr.fetchall())
In [5]: %timeit "hello@hello.com" in blocklist
The slowest run took 35.29 times longer than the fastest. This could mean that an intermediate result is being cached.
10000000 loops, best of 3: 31.6 ns per loop
In [6]: self._cr.execute("SELECT email from mail_blacklist")
In [7]: blocklist = [x[0] for x in self._cr.fetchall()]
In [8]: %timeit "hello@hello.com" in blocklist
100 loops, best of 3: 2.24 ms per loop
```
closes odoo/odoo#57128
X-original-commit: 3b9a85754f30f0bef508d0b576ff679c87ead5da
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>