Wednesday, August 26, 2026
15 changes · saas-18.4
Resolved issues and error corrections
This fixes an error that could prevent a Point of Sale session from closing when orders include both a tracked product and a kit containing that product. The system now correctly totals quantities across multiple matching order lines, making session closing more reliable for stores using kits and lot-tracked products.
Original PR description
**Step to reproduce :** 1. Create Product A and enable lot tracking for it. 2. Create a Kit product and add Product A as one of its components. 3. Go to PoS and create orders using: - Product A - The…
**Step to reproduce :** 1. Create Product A and enable lot tracking for it. 2. Create a Kit product and add Product A as one of its components. 3. Go to PoS and create orders using: - Product A - The Kit product - A combination of Product A and the Kit product 4. Create three different orders with these combinations. 5. Try to close the PoS session. **Issue :** An error occurs when attempting to close the PoS session. The issue is in the pos_mrp module, specifically in the _get_lot_line_qty method. When accessing the following line: `lines_data[move.bom_line_id.bom_id.product_tmpl_id.product_variant_id.id]['order_lines'].qty` we expect order_lines to contain a single record. However, in this scenario, multiple order lines can be returned for the same product. As a result, accessing .qty directly on order_lines raises a singleton error. **Solution :** With this fix, we first retrieve the quantity from each order line and thensum the quantities together. This ensures that multiple matching order lines are handled correctly and prevents the singleton error when closing the PoS session. opw-6442765 Forward-Port-Of: odoo/odoo#284233 Forward-Port-Of: odoo/odoo#281622
Website appointment records can now be opened for editing from the kanban view. This fixes a broken Edit action, helping website administrators update appointment pages without needing a workaround.
Original PR description
Steps to reproduce: 1. Install website_appointment 2. Website > site > appointment > kanban view 3. On a record, open the dropdown menu and click Edit. Issue: The Edit button does nothing. Cause: The Website appointment pages action only defines list,kanban views. When the kanban Edit action is triggered, the web client tries to switch to a form view, but no form view is available in the action, so nothing happens. Solution: Add the `appointment_type_view_form` to the Website appointment pages action and include form in its view_mode, so kanban Edit can open the selected appointment type correctly. opw-6197438 Forward-Port-Of: odoo/enterprise#117381
This fixes an internal sales timesheet test so it is not affected by unrelated discount price lists installed by other modules. The change helps keep automated quality checks stable and prevents false failures during development and releases.
Original PR description
The project profitability test assumes that the service product is sold at its list price. However, some modules such as `pos_pricer` add a globally applicable pricelist in their data. In 18.0, this pricelist can be selected for the test partner even when the pricelist feature is disabled, causing a discount to be applied and the expected profitability amount to differ. The fix is to remove existing pricelists in the test, as done in other tests affected by the same issue, so that the sale order price is deterministic. [error-944526](https://runbot.odoo.com/odoo/error/944526) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282712
Fixes an error that could occur when users selected multiple appraisals and marked them as done from the list view. Each appraisal now receives its completion message separately, allowing managers and HR users to process appraisal batches without interruption.
Original PR description
Steps to reproduce: - select multiple appraisals and try to mark as done from list view. Issue: - The completion notification uses an appraisal variable assigned by a previous loop, raising an UnboundLocalError. Furthermore, message_notify() requires a singleton. Fix: - notify and post the completion message for each appraisal explicitly. task-6479018 Forward-Port-Of: odoo/enterprise#128207
This fix ensures fiscal year periods cannot be saved when one completely contains another existing fiscal year. It helps prevent inconsistent accounting periods and reduces the risk of reporting errors.
Original PR description
Before this commit: - The current constraint for overlap check allows if we define a new, larger fiscal year that completely swallows an existing smaller one (e.g., creating Aug 2025 - Nov 2026 when Sept 2025 - Oct 2026 already exists). After this commit: - The constrain domain was changed to consider the above missed case. no task Forward-Port-Of: odoo/enterprise#128942
Saudi e-invoices in SAR now generate the correct tax information without repeating the same tax total in the XML. This prevents ZATCA validation warnings or errors for standard Saudi invoices and improves compliance reliability.
Original PR description
Steps to reproduce: - Create an invoice in a Saudi company (currency SAR) - Process it with ZATCA and review the generated XML file - ZATCA reports a validation error/notification for duplicate tax values, because the XML contains two cac:TaxTotal elements holding the same amount and currency Cause of the issue: _l10n_sa_get_additional_tax_total_vals always appended a second TaxTotal node regardless of the invoice's currency. this extra node is only valid when the invoice currency differs from the company's accounting currency (SAR). Since most Saudi invoices are issued in SAR (same as the company currency), the second TaxTotal was an exact duplicate of the first one's total amount. Solution: Only add the additional TaxTotal node when the invoice currency differs from the company currency opw-6409881 Forward-Port-Of: odoo/odoo#281667 Forward-Port-Of: odoo/odoo#279929
When users reduce or remove a column layout in the HTML editor, empty placeholder columns are now discarded instead of leaving behind blank paragraphs. Meaningful content is still preserved, and the editor remains usable when all columns are empty; labels were also clarified to better describe the action.
Original PR description
#### Description of the issue this PR addresses: - When reducing the number of columns or removing a column layout, empty columns were previously unwrapped like any other column. - As a result, columns containing only placeholder paragraphs contributed empty paragraphs to the resulting content, even though they did not contain any meaningful user content. #### Desired behavior after PR is merged: - Fully empty columns are discarded when they are removed. - Non-empty columns continue to be merged as-is, preserving their content. - A single empty paragraph is still kept when all columns are empty to ensure the editor remains editable. - Rename `Remove columns` to `Remove column layout` and update its description to `Convert columns to regular content` to better reflect the operation. task-6296536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282064 Forward-Port-Of: odoo/odoo#270220
Credit notes created from existing customer invoices in the Turkish localization now use the sales journal's designated return account instead of incorrectly keeping the original sales account. This helps ensure Turkish accounting reports separate sales and returns correctly, while cancellation reversals still mirror the original entry as required.
Original PR description
The Turkish chart of accounts keeps sales and sales returns on separate accounts, and the sales journal carries the account to use for returns. A credit note typed in by hand already lands on it, but one created from an existing customer invoice did not. Reversing an invoice copies `account_id` over from the invoice line, and since that field is a stored compute without depends, nothing ever recomputes it, so the return kept the sales account. Set the journal account on the copied product lines instead. Reversals made to cancel an entry are left alone, as those have to mirror the original move exactly for the two to net out, and a plain duplicate is untouched. Task-6438412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282858
Helpdesk contact forms generated for a website now keep all available translations instead of being locked to the language of the employee who set them up. This ensures visitors see the form in the correct website language, improving multilingual customer support experiences.
Original PR description
When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the…
When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the team, so a team set up by an English user language produced an English form even when the website served another language. Steps to reproduce ================== 1. Set a language other than English as the website default language. 2. While your user language is English, create a helpdesk team with the website form enabled. 3. Open the team form on the website. => The form is rendered in English instead of the website language. Root cause ========== `_ensure_submit_form_view` read the template arch without forcing a language, so it used the current user's language and stored only that value on the generated per-team view. Fix === Read the template arch in the default language of the team's website, so the generated form matches the website language regardless of the user's own language. opw-6303903 Forward-Port-Of: odoo/enterprise#121164
The UPS shipping integration now accepts phone numbers that match UPS rules, including shorter numbers used in countries such as Luxembourg. This prevents valid customers from being blocked when sales teams request shipping rates or create shipments.
Original PR description
**Steps to reproduce:** - Create a contact with a phone number that has 9 characters - Setup an UPS carrier, a configuration that works is UPS Saver as Service Type and UPS Package/customer supplied…
**Steps to reproduce:** - Create a contact with a phone number that has 9 characters - Setup an UPS carrier, a configuration that works is UPS Saver as Service Type and UPS Package/customer supplied as a package type - Create a quotation, put the created contact as a client - Try adding a shipping and getting the rates - An User Error appears, the phone number is too short **Why the fix:** Before this commit, any phone number that was less than 10 characters would raise an User Error, but some countries, such as Luxembourg, use phone numbers that are nine characters long or even less. If we check the official UPS documentation (https://developer.ups.com/tag/Shipping?loc=en_EN#operation/Shipment), we can see in the Ship_to/Phone section, that the phone number should be a number between 1 and 15, not saying it should be 10 characters or more. <img width="495" height="473" alt="image" src="https://github.com/user-attachments/assets/fed82987-ffb8-4b84-b282-6c3d3b4f304e" /> After this commit, we adapt the way we prevent the user from inputing phone numbers to fit the official UPS documentation. opw-6307577 Forward-Port-Of: odoo/enterprise#128632 Forward-Port-Of: odoo/enterprise#122831
This fixes an issue where using the editor command menu after selecting text could trigger an error and interrupt editing. Users can now apply commands such as separators more reliably without losing the editor selection state.
Original PR description
#### Steps to reproduce: - In an editor field, select some text. - Type `/` to open the powerbox: the selected content gets deleted. - Apply any command, e.g. `Separator`. => Error: Selection is not…
#### Steps to reproduce: - In an editor field, select some text. - Type `/` to open the powerbox: the selected content gets deleted. - Apply any command, e.g. `Separator`. => Error: Selection is not in editor #### Description of the issue this PR addresses: - `makeSavePoint` overwrites the preserved cursors with the selection staged on the last reverted step, then re-applies the draft mutations. Here those mutations are the deletion of the selected content, done by `onBeforeInputInsertText` before `SearchPowerboxPlugin.onBeforeInput` makes the savepoint. Re-applying them removes the very nodes the staged selection points to, so the cursors end up detached. #### Desired behavior after PR is merged: - Only reset the cursors when there is no draft mutation, so the initially preserved selection is restored instead. - This check added in 19.0 [1], but it isn't in 18.0 to saas-18.4. [1]: https://github.com/odoo/odoo/pull/244758 task-6442210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283614 Forward-Port-Of: odoo/odoo#282162
The lunch order test now waits for the correct product to appear before placing an order. This prevents intermittent failures caused by outdated demo products still showing while the lunch location is changing, making automated checks more dependable.
Original PR description
The lunch order tour selects `Farm 1` before ordering a product. However, it only waits for the location input to be updated before clicking the first kanban record. With demo data installed, a product from the previous location can still be displayed while the product model is being reloaded. The tour can therefore order a demo product instead of the product created by the test. This notably fails during weekends when the corresponding demo vendor is unavailable. To fix we need to wait for the product created by the test before clicking it. Besides selecting the intended product, this also ensures that the product reload following the location change has completed. [error-181572 ](https://runbot.odoo.com/odoo/error/181572) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281753
Argentine localization users can now create invoices for foreign customers even when export journals are unavailable or archived. The system falls back to a standard Invoice B document type, avoiding an unnecessary workflow block while preserving invoicing continuity.
Original PR description
### Issue before this commit: Before this commit, users were completely blocked from creating an invoice for a foreign partner (e.g., "Cliente del Exterior") if all exportation journals were archived…
### Issue before this commit: Before this commit, users were completely blocked from creating an invoice for a foreign partner (e.g., "Cliente del Exterior") if all exportation journals were archived or unavailable, as the system would immediately trigger a RedirectWarning error. ### Steps to reproduce the issue: 1. Download Accounting and l10n_ar 2. Go to contacts and create a new one with: 1. Country as United States 2. VAT number ex. 55000002126 3. AFIP Responsibility Type as Cliente del Exterior 3. Go to Journals, filter for sales journals and archive: 1. Electronic Exportation Invoice (FEX) 2. Expo Sales Journal 4. Go to invoices and create a new one for the client you just created 5. As soon as you insert the client you will receive the error: You are trying to create an invoice for foreign partner but you don't have an exportation journal ### Cause of the issue: https://github.com/odoo/odoo/blob/014d58e3204d17db6dcba3c8ab7d8ad35003300e/addons/l10n_ar/models/account_move.py#L186-L189 The _onchange_partner_journal method rigidly enforced the use of an exportation journal for foreign AFIP responsibility types (codes 8, 9, and 10). If the query failed to find an active export journal, the code intentionally threw a hard error instead of providing a fallback mechanism. ### Reason to introduce the fix: This fix is introduced to prevent unnecessary workflow blocks. By catching the missing journal and defaulting the document type to "Invoice B" (code 6), the user can now successfully generate the invoice using a standard domestic sales journal without being forced to configure an exportation journal. opw-6442501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282971
This fix prevents an error when reconciling accounting entries while multiple companies are selected. It ensures the currency conversion uses the relevant company from the accounting entry, so users can complete reconciliations across parent and branch companies without interruption.
Original PR description
When having multiple companies selected at the same time, _get_conversion_rate returns: File "/data/build/odoo/odoo/orm/fields_misc.py", line 114, in get raise ValueError("Expected singleton: %s" %…
When having multiple companies selected at the same time, _get_conversion_rate returns:
File "/data/build/odoo/odoo/orm/fields_misc.py", line 114, in get
raise ValueError("Expected singleton: %s" % record)
1 - Create a new company with currency EUR.
2 - Create a branch company underneath the main company.
3 - In Accounting, install fiscal localization, e.g. Belgian Companies on the company configuration settings.
4 - Select an account like 600000 Raw Materials, and enable Allow Reconciliation on this account. The exact account isn't important, only that we can make credits / debits to it to be reconciled.
5 - With only the top level company selected, make a debit of 100 USD, e.g. Vendor Bill, set in currency USD to the account 600000.
6 - Now with only the branch level company selected, make a credit of 100EUR, e.g. Customers Invoices, set in currency EUR to the same account with an amount equal to the credit in step 5. (if 1USD == 1EUR, 1-1), so that there is no residual amount, i.e. credit == debit.
7 - Now select both the top level company and the sub branch company in the company context.
8 - In Journal Items, reconcile the unreconciled journal items for the Account 600000.
With this commit we select the first company of the aml instead of every companies on the amls.
opw-6290703
Forward-Port-Of: odoo/enterprise#123774Italian withholding tax returns submitted in quarter-ending months no longer trigger the periodic VAT return export by mistake. This prevents crashes and avoids creating or attaching the wrong XML file to the wrong tax return.
Original PR description
In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the…
In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the kind of return, so every Italian return locked on a quarter month was treated as a LIPE. Submitting the withholding tax return therefore opened the LIPE export wizard. Depending on the record the wizard receives, it either crashes while reading the VP lines missing from the withholding report, or silently generates a LIPE file and attaches it to another return. Add an `is_lipe_return` field telling whether the return actually produces the LIPE. Steps to reproduce: - Install `l10n_it_xml_export` and `l10n_it_edi_withholding_reports` on an Italian company with monthly returns - Open Accounting > Reporting > Tax Return - Review and submit the withholding returns up to February - Review then submit the March withholding return --> The LIPE export wizard opens, and the export fails on the withholding report. opw-6255016 Forward-Port-Of: odoo/enterprise#125263