Monday, August 11, 2025
19 changes · saas-18.4
Enhancements to existing features
Invoice document layout settings now show the same Tax ID, bank account, and QR code options whether users send, print, or configure documents in settings. This makes previews more accurate and reduces confusion when preparing customer-facing invoices.
Original PR description
Previously, the document layout wizard used when sending invoices included fields for Tax ID, Bank Account Number, and QR Code. However, these fields were missing from the wizard accessed via the…
Previously, the document layout wizard used when sending invoices included fields for Tax ID, Bank Account Number, and QR Code. However, these fields were missing from the wizard accessed via the `Print` button and from the layout configurator under `General Settings > Configure Document Layout`. This was because only the send flow was using the inherited report layout from the `account` module, while the print and settings flows were using the base layout from `web` directly. Additionally, the preview template in web did not include the bank account number or QR code With this **PR**: 1. The `Print` button now uses the inherited layout from `account`. 2. The settings configurator button also uses the correct layout from `account`. 3. The bank account number and QR code fields are now dependencies of the _compute_preview method, making the preview responsive to their changes. 4. Both fields are now shown in the preview when configuring the layout in settings. This ensures the document layout behaves consistently across send, print, and settings configurator flows. **task**-4954030 Forward-Port-Of: odoo/odoo#222380 Forward-Port-Of: odoo/odoo#220149
The live chat information panel now presents visitor context and related records more clearly, including website names on recent page views and better placement of notes and status details. It also improves usability by hiding recent conversations when chats are closed, opening panel links in new tabs, refining dark-mode chatbot answers, and enhancing helpdesk ticket accessibility.
Original PR description
1. Add website name to recent page views. 2. Improve chatbot answers display in dark mode. 3. Update recent conversations button alignment. 4. Do not display recent conversations when the chat is closed. 5. Move notes section next to the status section. 6. Open links in the info panel in a new tab. 7. Helpdesk tickets accessibility improvements. Task-4929870 https://github.com/odoo/enterprise/pull/90350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors now have clearer carousel settings that better match expected carousel behavior, including more precise autoplay choices and context-aware speed options. Image gallery carousels also gain the same configuration options, making carousel setup more consistent across website content.
This update ensures Saudi e-invoicing certificate requests use the correct parent company or branch information required by ZATCA. It also blocks invoices from being posted with a mismatched journal company and improves test coverage for business-to-business Saudi e-invoicing flows.
Original PR description
…nches Description of the issue/feature this PR addresses: The current implementation of generating CSR files for EDI doesn't differnetiate between parent companies and branches. ZATCA, however,…
…nches Description of the issue/feature this PR addresses: The current implementation of generating CSR files for EDI doesn't differnetiate between parent companies and branches. ZATCA, however, expects slightly different information depending on whether the company is a branch or a parent. This also includes a refactor of the tests for l10n_sa_edi. Current behavior before PR: The Organization Name, Organization Unit Name, and Organization Identifier of whichever company on the journal were being sent to ZATCA. You could also Onboard/Re-Onboard a journal in different company. The unit tests for EDI document generation were primarily using a partner based in the US, which meant that the b2b invoicing main flow was not being properly tested Desired behavior after PR is merged: Parent/Standalone Company: - Organization Name: The name of the company - Organization Unit Name: First 10 characters of the VAT - Organization Identifier: The VAT of the company Branch: - Organization Name: The name of the parent - Organization Unit Name: The name of the branch - Organization Identifier: The VAT of the parent - Prevent users from posting invoices, credit notes, or debit notes whose invoice company doesn't match the journal company - The tests are easier to read and they test the b2b flow correctly opw-4794842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221476 Forward-Port-Of: odoo/odoo#213518
Website editors can now preview more shop page customization options instantly before applying them. This makes it easier to adjust product list layouts and related settings with fewer page reloads and a smoother editing experience.
Original PR description
This PR was split into: - [x] https://github.com/odoo/odoo/pull/212340 - [x] https://github.com/odoo/odoo/pull/215019 - [x] fwport: https://github.com/odoo/odoo/pull/215852 - [x] https://github.com/odoo/odoo/pull/215218 - [x] fwport: https://github.com/odoo/odoo/pull/217405 - [x] https://github.com/odoo/odoo/pull/217697 - [x] fwport: https://github.com/odoo/odoo/pull/219499 - [x] https://github.com/odoo/odoo/pull/220951 - [x] fwport: https://github.com/odoo/odoo/pull/222394
Website editor options now preview more consistently, even when some changes require a page reload. The update also improves how changes are saved or reverted behind the scenes, reducing the risk of edits appearing out of order or not being applied correctly.
Xendit credit card payments now support the required authentication flow while enabling future merchant-initiated recurring purchases after an initial authorized transaction. This helps merchants comply with Xendit's authentication requirements and reduces friction for repeat payments where allowed.
Original PR description
By default, Xendit will require authentication for all credit card payment. Previously, we assume that optional 3DS is easily configurable for each user which will omit authentication for tokenization flow. Turns out, this configuration requires permission from Xendit. Instead of that, Xendit provides the Merchant Initiated Transactions (MIT) which allow users to purchase without authorization as long as the first transaction was already authorized successfully. To accomodate this, we need to support authentication flow and adding extra parameter `is_recurring` in the payload, --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221976 Forward-Port-Of: odoo/odoo#214708
The live chat information panel is easier for support teams to use, with clearer recent page views, better link behavior, improved layout, and enhanced accessibility for helpdesk tickets. These updates make customer context easier to read and reduce distractions when chats are closed.
Original PR description
1. Add website name to recent page views. 2. Improve chatbot answers display in dark mode. 3. Update recent conversations button alignment. 4. Do not display recent conversations when the chat is closed. 5. Move notes section next to the status section. 6. Open links in the info panel in a new tab. 7. Helpdesk tickets accessibility improvements. https://github.com/odoo/odoo/pull/219053 task-4929870
Resolved issues and error corrections
Purchase orders created outside the standard purchase screen now correctly use the supplier’s preferred currency instead of defaulting to the company currency. This prevents incorrect currency selection when purchase orders are generated from workflows such as approvals.
Original PR description
Steps to reproduce: - Go to Invoicing > Configuration > Accounting > Currencies: - Enable the Euro currency - Set company currency to USD - Go to any partner form (e.g. Azure Interior): - In Sales &…
Steps to reproduce:
- Go to Invoicing > Configuration > Accounting > Currencies:
- Enable the Euro currency
- Set company currency to USD
- Go to any partner form (e.g. Azure Interior):
- In Sales & Purchase tab: - Set Supplier Currency to Euro
- Create a purchase order from the UI:
- Select Azure Interior → Currency is correctly updated to Euro (via onchange)
- Install the Approvals module
- Create a storable product "P1":
- Under Purchase tab: - Vendor: Azure Interior - Price unit: 5 EUR
- Create an approval request:
- Request Owner: Marc Demo
- Product: P1
- Approver: Mitchel Admin
- Submit and approve the request
- Click on "Create Purchase Order"
Issue:
The purchase order is created with the correct partner and product. But the currency is incorrectly set to the company currency (USD), instead of the supplier's currency (Euro).
Cause:
The currency was updated via an `@onchange`, which is only triggered in the UI.
When creating a PO programmatically (e.g. via approvals or in a test), the onchange is not executed and the currency falls back to the company default.
Solution:
Replace the `@onchange` logic for `currency_id` with a stored compute field.
This ensures that the correct currency is always computed, regardless of how the purchase order is created.
opw-4938390
Forward-Port-Of: odoo/odoo#222235
Forward-Port-Of: odoo/odoo#221907This fixes an issue where sales order line prices could stay unchanged after increasing the quantity, even when a pricelist rule should apply a lower price. Businesses using quantity-based pricelists can now rely on accurate pricing without manually switching pricelists or forcing an update.
Original PR description
**Steps to reproduce**: 1. Install the `sale` module. 2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`. 3. Create two pricelists: - Pricelist A with two fixed-price rules: -…
**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
- Pricelist A with two fixed-price rules:
- `0.75` for quantity ≥ 0
- `0.50` for quantity ≥ 1000
- Pricelist B with a `-10%` discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.
**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.
**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since PR [#21392](https://github.com/odoo/odoo/pull/213912), `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.
**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.
opw-4944644
Forward-Port-Of: odoo/odoo#221389This fixes Belgian POS reporting so credit notes show as negative amounts while invoices remain positive, making sales details clearer and consistent with totals. It also prevents the POS from accidentally removing two order lines when decreasing an unsaved item quantity.
Original PR description
- Fix issue on the POS sale details report, where the amount of credit notes was displayed as a positive amount along invoices while the total was correctly computed. Now we displayed the signed amount (negative amount for credit note, and positive ones for invoices). - Fix issue in `handleDecreaseUnsavedLine` which was leading to removing two orderlines instead of one in the current order. This issue appeared since this commit (1aaa600801d9ecf23d9c460690587ec4e4d9b423). Since we already set the line qty to 0 (or remove it) inside `updateSelectedOrderline` after calling `_showDecreaseQuantityPopup`, we don't need to call `removeOrderLine` inside `handleDecreaseUnsavedLine`. task-id: 4901299 enterprise PR: https://github.com/odoo/enterprise/pull/92070 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now loads the same style foundations used by the live website, so theme colors and other design settings are available while editing. This reduces visual mismatches and makes product page previews and customization controls more reliable for website builders.
Original PR description
The `html_builder.inside_editor_style` bundle provides style assets that are loaded exclusively inside the editor's iframe during edition. We want to use scss variables that are sometimes overriden in various ways such as the theme tab of the website builder, website settings or website themes. The inheritance currently does not work and some variables are straight up not available. To resolve this, this commit inherits the `web.assets_frontend` which provides all those variables and is overriden by all said mechanisms.
Receipts that include stock moves linked to different partners can now be opened without triggering an error. This prevents a crash in Inventory operations and allows users to view imported receipt records normally.
Original PR description
When opening a Receipt containing stock moves linked to different partners, A traceback will appear. Steps to reproduce the error: - Install ``stock`` module with demo data - Go to Inventory > Operations > Receipts - Import this [file](https://docs.google.com/spreadsheets/d/1LkplPQqWdUGOUHaTuJ1khXdvB6kGDVwb/edit?usp=sharing&ouid=106663959141116380430&rtpof=true&sd=true) - Open the imported record Traceback: ``ValueError: Expected singleton: res.partner(1, 2)`` https://github.com/odoo/odoo/blob/ac2b182f55a632f4e8a869cbf61613ebc93d8ae2/addons/stock/models/stock_move.py#L710 Here, ``_get_lang`` method is called on self containing multiple stock moves. So, it will give the traceback from below line because it will have multiple partners. https://github.com/odoo/odoo/blob/ac2b182f55a632f4e8a869cbf61613ebc93d8ae2/addons/stock/models/stock_move.py#L2214-L2216 sentry-6798363441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting administrators without expense permissions can now create expenses without running into a misleading validation error. To prevent incorrect employee selection, these users can only create expenses for their own employee record.
Original PR description
- Create a user and its related employee without any expense access rights but with accounting admin rights. - With that user create a new expense. - On the employee field select a different employee…
- Create a user and its related employee without any expense access rights but with accounting admin rights. - With that user create a new expense. - On the employee field select a different employee and save. - The following error appears: Validation Error The operation cannot be completed: Missing required value for the field 'Description' (name). Model: 'Expense' (hr.expense) - create/update: a mandatory field is not set - delete: another model requires the record being deleted, you can archive it instead Since b1ac6f52d37cd59fdb973ce87f93d1d0a69dd204, the field employee_id is no longer invisible for users without hr_expense rights. However, in the method _search_filter_for_expense, users without hr_expense rights but with account rights are able to select every employee (commit 87cca4a9ee64c890ccbd24e2d6766f9f8799a0c0). But in hr_expense, the method _compute_is_editable only considered hr_expense rights, which meant that users trying to create a new expense with only accounting rights would get an error if they were not the approver of the employee they tried to create the expense for. After this commit: If the user has no hr_expense rights but has account rights, they will only be able to create expenses for themselves. opw-4780218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222253 Forward-Port-Of: odoo/odoo#215452
Website table of contents links now update when headings are translated, so visitors see navigation labels that match the selected language. The change also prevents editors from directly changing generated navigation items, reducing inconsistent content in multilingual pages.
Original PR description
When we translate headings in the Table of Content snippet, the snippet's navbar items aren't responsive, they stay connected to the original language headings. Steps to reproduce the problem: - Add a second language to your website - Open Website and start editing - Drop the table of content snippet - Save, switch to your secondary language and start translating - Modify the table's heading => Navbar headings aren't updated. This commit also fixes the possibility of editing a navbar item directly, which shouldn't be the case. This commit follows the [html_builder refactoring]. Related to task-4367641 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb
The point of sale now calculates prices correctly when products have dynamic or configurable variants with extra charges. This prevents customers from being charged duplicated or incorrect variant surcharges, improving checkout accuracy.
Original PR description
When you have product with dynamic variants using extra price, the price added to the cart is not correctly computed. Steps to reproduce: ------------------- * Create a product with a dynamic variant…
When you have product with dynamic variants using extra price, the price added to the cart is not correctly computed. Steps to reproduce: ------------------- * Create a product with a dynamic variant (2 values), price 1 * Add an extra price for each value, ex 10, 20, 100 * Make a sale order with the first two variant value * Open shop * Add the product to the order 3 times, 1 for each value > Observation: Prices are respectively: 21, 41, 111 Why the fix: ------------ In the shop only `product.product` are shown. When selecting the product with variant, the product has a `lst_price` of 11 which corresponds to the price of the `product_template` plus the extra price. This value is normal but cannot be used in the computation of `get_price` as we also provide the value for `extra_price`. We can use `list_price` instead of `lst_price` as it does not include the information related to variants. Why do we see 2 different behaviors before this fix? When selecting a variant option, if the product with this variant already exist, the lst_price already contains the information about the selected variant. Which explains why, in the end, the price has twice the extra price of the variant selected. When the product with the variant does not exist, the price has one time the price of the selected variant plus one time the price of the first product with variant the is created. Configurable products were also having issues when mixing multiple variants, especially when one of them had creation mode set to "always". When exiting the configuration popup the payload does not include the extra price coming from "always" attributes. depending on what the other choices were we would have an extra price, meaning we would compute the price with `list_price` but the extra price did not include the information about the "always" variant if it had one. Using `list_price` is enough for the initial problem but only when the selected DYNAMIC variant has an extra price otherwise the code does not pass through the condition asking for extra price. In such case there is no extra price from the payload and it's still computing the price with `lst_price`, which includes information about the extra price of the variant that was already sold previously. Thus we make sure that we compute with `list_price` whenever a configurable product is added. opw-4815555 Forward-Port-Of: odoo/odoo#220091 Forward-Port-Of: odoo/odoo#216649
Fixes a point of sale issue where completing a payment with automatic receipt printing could create two new draft orders instead of one. This helps keep cashier workflows cleaner and avoids unnecessary empty orders after a sale.
Original PR description
Steps to reproduce: ------------------------- - Open a session with automatic receipt printing enabled. - Pay an order when only one open order is present. Issue: ------- - Two new draft orders are created instead of one. Cause: --------- - `this.pos.defaultPage` is a getter that creates a new draft order if none exists. Later, `selectNextOrder()` was also triggering a new order creation when automatic receipt printing was enabled, causing the creation of two draft orders. FIX: ----- - Removed the redundant order creation logic from `selectNextOrder()`, as the new order is already created through the default page getter also moved that function logic to pos store. Task: 4925669
Project profitability now continues to include invoices from subscriptions that were renewed. This prevents previously invoiced revenue from disappearing after renewal, giving businesses a more accurate view of project profitability.
Original PR description
To reproduce: ============= - create a subscription with a service and link it to a project - confirm the subscription and invoice it - check the profitability of the project, everything is fine - renew the subscription and invoice it - check the profitability of the project, the invoiced amount is not taking into account the previous invoiced amount Problem: ======== renewed subscriptions are excluded from the profitability computation because they are closed by the renewal and not bringing any profitability, but with that we loose the profitability of the previous invoiced amount. Solution: ========= keep renewed subscriptions in computing `Invoiced` amount. opw-4755016 Forward-Port-Of: odoo/enterprise#92052 Forward-Port-Of: odoo/enterprise#91437
The Czech VIES summary report now counts supplies by invoice instead of invoiced quantity, groups data by journal entry, and rounds total values correctly to whole Czech crowns. This helps businesses submit more accurate VAT reporting in line with Czech tax authority requirements.
Original PR description
There are some errors in the VIES summary report fixed here:
1. The supply number is not the quantity invoiced, it is the
number of invoices
2. There was some confusion between the terms "supply transaction"
and "supply code", with "supply code" not being used
in this report (but still in Python code to avoid breaking stable versions)
3. We were considering journal items, whereas it is preferable
to group them by journal entry
4. The total value is rounded up to the nearest whole crown (Czech currency)
Here is a link to the documentation:
adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV
where pln_hodnota is the total value; pln_pocet is the supply number; and k_pln_eu is the supply transaction.
opw-4688616
Forward-Port-Of: odoo/enterprise#91891
Forward-Port-Of: odoo/enterprise#88279