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
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
This commit improves sale management through a better integration of
activities and addition of automated activities. Several things are done
in this commit :
* automatic activities generation is added for sale order upselling.
They are also automatically removed or updated when the sale order state
changes from or to upselling to avoid bloating users with unnecessary
activities;
* a menu to configure activity types is added. Indeed HR managers should be
able to see and configure activity types related to their job;
Technically we choose to override _write in order to catch the invoice_status
computed field update and try to have a lightweight implementation. Indeed
sale.order is a complex model and we tried to have a low-level override
that do not mess with business overrides.
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.
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
This commit adds demo data to populate
the project overview with billable
timesheet on sold projects and tasks.
This will ease the testing and reinforce
the wow effect during demonstration.
Note: those demo data should never be
involved in python test cases.
Closes#21132
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.
Before this commit, Sale order and invoice notification email templates broke when doing any action on them (duplicating, open preview etc...)
This is because the model is saved during those operation, and the css style gets converted to inline style.
The table tag present in those templates, was wrongly associated with the bootstrap rule for tables, collapsing their border, hence the break of the templates.
After this commit, we force the borders not to collapse, and the templates don't break
OPW 774323
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.
The 'View', 'Accept and Sign', 'Pay Online' buttons are now correctly
computed based on the sales settings or the online quote settings.
Indeed it is now possible to sign and/or pay quotations without having
website_quote module installed.
Suppose two ways to install sale:
-i account followed by -i sale: account is installed, the execute is done on the chart template and then,
sale is installed. In this case, the IrDefault values already exists when sale is loaded.
-i sale directly: account and sale are installed, the execute is done on the chart template.
The difference is that there is no IrDefault values set on the demo data in sale.
The problem is that such behavior can lead to wrong tests. For exemple, having taxes_id/supplier_taxes_id
set or not set on product.template during sale tests.
Customer portal is now a feature coming directly with sale module. As
it uses a simple website renderer customization and advanced website
features are not available and depends on having website module
installed.
PURPOSE
=======
Currently 'Sales Analysis' report have by default group by creation date. here matters if confirmed SO is the confirmation date(for sales commission, etc), not the creation date.
SPECIFICATION
=============
'Sales Analysis' have default group by 'Confirmation Date' instead of 'Creation Date'
PS: Validate 2 SO to have a confirmation date.
Mail now can handles a generic access_token in /mail/view route. Mail does
not do anything with it. Addons can override the controller and add their
specific management of this token according to some specific business
logic.
Sale order emails now contains the access token to grant access from the
notification email url without logging in. Sale portal now allow customers
to log in using an access token without having to use Online Quote. If
the user doesn't have an account yet and signup is allowed (B2C) an extra
parameter is added to the url to link the correct partner to the user upon
signup. If the user already has an account an extra parameter is added to
auto-fill the user's login if he wants to login from that session.
Account is also updated to prepare accepting access tokens. However the
complete implementation of accounting customer portal will be done in
another task coming soon.
Purpose
=======
pro-forma concept is not easy, it is an adjective in english, it should be "Pro-Forma Invoice" to avoid confuision
Rename it everywhere (report, form, settings)
Specification
=============
In Sales/Settings, Sales/Quotations and in the report (.pdf)
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
This reverts commit 9ab421d99a.
We should use the active field on the ir.ui.menu with the root menuitem instead of moving all the menuitems into a new module
Correctly display 'Pay online' or 'View online' depending on payment
required option. Also correctly set the URL that comes from the
get_access_action method.
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
Currently the link is always the website link once website_portal or
website_quote is installed. However it is better to use the generic
/mail/view controller that chooses the right redirection depending on
the user trying to access the document.
This commit also fixes redirection in website_quote that is always
redirecting to the front-end. Classic users should land on the backend.
Indeed seeing the front-end page is rarely interesting for them.
rename values of selection field to actual model names.
this prevents the need of a separate function to get the sql table
and allows to get direct access to the model.
(needed for the next commit)
When disabling the customer portal
in the general settings
(or uninstalling the `portal_sale` module directly),
the model `sale.order` no longer has a method
`get_signup_url`, and it therefore leads
to the fail of the email template rendering which is
still referencing this method.
Besides, the `access_url` is actually used only if
`is_online` is True,
(see the `% if is_online:` few lines later)
and in this case `get_signup_url`
was not used at all.
Therefore, we can assume `None` is a good alternative,
as the resul of `get_signup_url` was actually no longer
used.
opw-710481
The notification mail template of a SO and an Invoice displays the logo
of the company. However, the logo is always the logo of the superuser's
company.
When accessing the logo from an email client, the UID is not defined.
Therefore, we fall back on the superuser, and display the logo of his
company.
We add the support of a `company` key in the kwargs, so we can force the
company from which we retrieve the logo. Note that this key was used
elsewhere, such as:
addons/web/static/src/js/web_client.js
opw-705420
Purpose
=======
External links in the data sometimes open in the same tab, the users loses times as he has to come back (and looses the context).
Specification
=============
Any external links in data (planners, settings) should open in new tabs.
Purpose
=======
we use to make proforma invoice to get payment before the creation of the real invoice. In the current odoo, the proforma state is too late. Because you have to confirm the SO to generate the draft invoice and so the proforma. But, if you do that, you have generated a subscription or a delivery order in the mean time. A proforma is actually a quote. In old ERP they used to make proforma to send a quote and don't generate invoice number.
Specification
=============
- Remove everything related to Proforma from accounting
- Remove the configuration of pro-forma from account setting
- Invoice form, remove "Pro-froma" button, stage, report title
- Add proforma configuration option in sales setting under "Quotation and Sales" section
- In quote/sale, add Pro-forma under Print
- A pro-forma is a quote, but the title of the report is Pro-Forma and not Quotation
- button (secondary) on quotation form "SEND PRO-FORMA" to send proforma by mail attached with related report.
- button
- mail template
- when preparing a quotation this button is visible but if even one invoice this should be invisible (as confirming SO doesn't generate invoice currently)
Functional
==========
Sales teams become sales channels. Their dashboard cards now include a graph
displaying customizable data for managers (comparable to those in accounting).
By default, you now have the following sales channels (non-demo):
Direct Sales (with installation of crm or sale)
Sales Channel type: Sales
Works same as before, what's changed is:
- their cards display one big button directing to the start of their
workflow
- the links on the right-hand side have been reworked, and are only
displayed when there is at least one item requiring attention.
- 'More' tab remains unchanged.
Website (with installation of website_sale)
Sales Channel type: Website
Differences lies in the links displayed in the dashboard card:
- it displays abandoned carts, awaiting payments and payments to capture
Default Channel linked to all sales made from the eCommerce.
Point of Sale (with installation of sale and point_of_sale
-> auto-installs pos_sale)
Sales Channel type: Point of Sale
Linked to pos.configs and their pos.sessions and pos.orders.
- only links to their linked pos.config dashboard and open sessions
- can't use opportunities, lead or invoicing and can only display
pos.order data in the graph.
Default Channel linked to the default pos.config.
Technical
=========
- Add a channel type: sales, pos, website that have different actions/settings
- Add a graphs to the kanban cards in the sales/crm dashboard, configurable in
the form view in the new dashboard page.
- Rename sales teams to sales channels, rename and add default and demo sales
channels
- Change dashboard links depending on the channel type and add a related
computed fields on crm.team
- Rename strings and improve channel form view.
- Leads are now checked by default once activated for 'sales' type channels
- Disable checking "leads" without using "opportunities".
- Hide invoicing and invoicing target depending on channel type.
- Move currency_id to sales_team
Christophe Simonis