Daily updates from Odoo
Navigate
Branch
Thursday, May 9, 2019
11 changes
Enhancements to existing features
Customers now receive clearer order and payment confirmation emails when buying through eCommerce or paying from the portal. The update adds richer templates, including product images for online purchases, and gives businesses more control over which confirmation emails are sent.
Original PR description
Purpose of this merge is to improve emails sent when confirming sale orders. A new template is added that contains lines with image for bought product to be used in eCommerce. See sub commits and task for more details. Related to task ID 1873634
Customers now receive clearer order and payment confirmation emails when they complete purchases online or pay from the portal. The update adds richer email templates, including product images for eCommerce orders, and gives businesses more control over which confirmation emails are sent.
Original PR description
Purpose of this merge is to improve emails sent when confirming sale orders. A new template is added that contains lines with image for bought product to be used in eCommerce. See sub commits and task for more details. Related to task ID 1873634
Odoo can now automatically install add-on modules based on only the key dependencies that matter, rather than requiring every related technical component to trigger installation. This makes optional bridge features easier to activate while avoiding unnecessary standalone technical modules being installed too broadly.
Original PR description
When modules have both business & technical dependencies (e.g. bridge modules w/ non-core technical component), it feels inconvenient/unnecessary/icky that the technical component (and all of its own dependencies) pretty much has to be auto_install itself for the bridge to properly get installed. This change removes that constaint, it allows auto_install to only consider a subset of dependencies by setting it to a list (/iterable). Task 1851328
Products can now share the same barcode across different companies, while still preventing duplicate barcodes within the same company. Point of Sale product lists now respect the active company, reducing confusion and incorrect product selection in multi-company setups.
Original PR description
Task : https://www.odoo.com/web?#id=1841493&view_type=form&model=project.task&action=327&menu_id=4720 Pad : https://pad.odoo.com/p/r.e1811931a7019a2340d7ddf89bd849a7
This update cleans up several Helpdesk-related integrations after recent feature work, making the code easier to maintain and more aligned with internal guidelines. It also improves how repair counts and sales order links are handled, reducing unnecessary processing while preserving existing user behavior.
Original PR description
Task 1909413 has been merged, providing lots of news feature from a helpdesk.ticket. However, some part of the code is not clean enough. This task aims to clean it, to make it fit guidelines, and to avoid bad practises. * cleaning of domain creation in helpdesk_sale * optimization of compute method in helpdesk_repair * renaming of methods to fit guidelines in several modules Task-1909413
Dashboard-related add-ons now install only when their business features need them, instead of automatically enabling the dashboard module by default. This reduces unnecessary installations while keeping dashboards available when dependent apps are used.
Original PR description
Dependents should auto_install regardless of web_dashboard being installed or not, forcing its installation in the latter case. cf odoo/odoo#29431 for technical part
Barcode scans for products now respect the company the user is working in. This helps multi-company businesses avoid selecting products assigned to another company, while still allowing shared products to be used across companies.
Original PR description
Task : https://www.odoo.com/web?#id=1841493&view_type=form&model=project.task&action=327&menu_id=4720 Pad : https://pad.odoo.com/p/r.e1811931a7019a2340d7ddf89bd849a7
Resolved issues and error corrections
The Mail activity view now keeps its first column at a consistent width. This prevents the table layout from shifting when users change filters or domains, making the screen easier to read and less distracting.
Original PR description
The first column should have a fixed width to avoid the table to resize when changing the domain for example. Task 1894990 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes issues in the Alipay payment flow so customers are routed through the standard payment processing path and transaction status is updated more reliably. It also ensures payment errors are displayed correctly to users instead of failing due to an incorrect message lookup.
Original PR description
payment_alipay: No need of return URL as '/payment/process' will handle all the cases for payment. use of _set_transaction_state as per the state of the transaction. payment: when we get an error while making the payment, it should be shown to the user. But the message is not getting from proper dict, so it will break every time. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
Invoice payments are now handled through a clearer shared registration flow, reducing duplicated logic in accounting screens. This should make payment-related behavior easier to maintain while keeping the business workflow largely unchanged for users.
Original PR description
Task 1903572 purpose: always use the transient model when registering the payemtn from invoice (single or multi) to clean some code and make things more clear specs: need to see if there are real benefits of doing so -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice payments are now registered through a dedicated temporary workflow, whether paying one invoice or several at once. This simplifies the payment process internally and should make future maintenance of payment-related features more reliable across affected accounting localizations.
Original PR description
Task 1903572
purpose:
always use the transient model when registering the payemtn from invoice (single or multi) to clean some code and make things more clear
specs:
need to see if there are real benefits of doing so