formataddr (from the email python library) writes email_from as '"name" <email>'
in the email_from field of the mail.compose.message record.
When the mail is rendered, onchange_template_id is triggered.
This then overwrites the values of email_from among other fields.
What happens is that it uses the email_from field from the template to render
the email_from, bypassing what was put by formataddr before.
What happens in some cases is that it is rendered as 'name <email>'
(note the quotes have been stripped away).
If name contains arbitrary symbols, e.g. name = 'pépé [company] <pdg>, ohlala',
then getaddresses which is supposed to parse the (name, email) pairs gets thrown
off (in particular, <pdg> will be interpreted as an email address, and many
other problems with the various special symbols).
It then gives these wrong elements as email addresses, which will usually crash
when getting non-ascii symbols (i.e. these strings don't respect the relevant
RFC for email addresses).
Closes:
https://github.com/odoo/odoo/issues/23502https://github.com/odoo/odoo/pull/2311823118
opw 815202
opw 1824243
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
In 41ffb503 the "Invoice Notification Email" and "Sale Order
Notification Email" were modified so the company used was the one of
the object if available or the sender otherwise.
This had not been done for the "Purchase Order Notification Email" which
was added in saas-14 which might be unexpected.
Also as in 7a03f9ce9 specify the company when displaying the logo.
opw-1838112
closes#24344
Steps to reproduce the bug:
- Set a multi company environment with two company A and B
- Set user admin in company A
- Set user demo in company B
- Create a PO with user demo
- Send a RFQ
Bug:
The company of the admin user was displayed in the footer of the email.
The function _notify called on res.parter model is called in sudo by
the function _notify on mail.message model.
The function render_template on mail.template model uses the user defined
on self.env to render the template. So the user admin was always used.
opw:1835647
Before checking the first element of
'partner_id.child_ids', rather check that
the partner and not the object has children,
to avoid crashes when the partner of the PO
is a company.
opw-1826359
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
All those templates are basically the same except some bug fixes that
were not propagated about company. Let us use just the one we just
defined in the mail module.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
template people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
Use case to reproduce the bug:
- Enable multi company and create a second one.
- Add both company to another user and give him stock manager rights
- Login on the second user and select as active the created company
- Go to product and create one
-> access right error on stock.location.route message.
It happens because the routes 'buy' is selected by default.
However the route buy when created use the default company
although it's generic for all companies.
This commit change the data in order to remove the company on
routes buy, mto, manufacture and drop_shipping. Since this commit
was released after v11 release, it could happens that already created
database still have the problem thus the solution is to remove
manually the company on the routes quoted above.
opw-777718
Not used since a while, remaining of old res.request. Requests have been
removed at 881a76dbcf . Links have been kept because still
used in some reference fields. It seems the last use was in OpenERP v9.0
in crm_claim module. As links are not used since a while let us get rid of
it.
Templates used to send invoice / quotation / PO by email are cleaned. Custom
style is removed. Content is simplified.
For sale, only one template is kept through the various addons. Previously to
this commit there are 3 templates: standard, portal and online quote. Those
template are similar except the link to get the sale order. Now the base template
contains some logic that should be sufficient to cover all cases. This breaks
the modular approach but is easier to use for users. As templates are still mako
it is not possible to use inheritance. So having a base template knowing some bits
of overriding modules is necessary if we want to avoid having the same template
duplicated.
In qweb reports, the address is displayed according the standards of the
country where it belongs. In the email templates, the company address was
always displayed in the same way, no matter the country of the address.
These templates were deleted with c04065abd8 but there xml_id were still used in the code. Mail template are good for people, so we make them come back from the dead ...
Christophe Simonis