Daily updates from Odoo
Monday, July 14, 2025
38 changes · saas-18.4
Resolved issues and error corrections
Fixes issues where invoices using cash rounding could produce invalid UBL electronic invoice files or import back with different totals. This helps ensure compliant e-invoicing and consistent invoice amounts across export and import, especially for tax-related rounding cases.
Original PR description
Currently these problems can appear when an invoice is cash rounded. 1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy: The rounding amount is added to the taxes in…
Currently these problems can appear when an invoice is cash rounded.
1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy:
The rounding amount is added to the taxes in Odoo but not in the UBL XML
- This affects everything that uses `_prepare_invoice_aggregated_taxes`
(and not just UBL XML)
2. The generated UBL XML is invalid (for any rounding strategy).
See below for details.
3. The import of the exported UBL XML does not yield back the same invoice
(even after fixing the export / the previous 2 problems).
Also there are some problems with the correction of tax values
of imported UBL XML (`correct_invoice_tax_amount`).
(They probably do not cause issues in practice but would after this
fix. We adapt the correction as part of the fix for (3).)
#### Runbot: How to generate problematic XML
1. Select BE Company CoA
2. Enable Cash Rounding in the settings
3. Create a cash rounding method
(in the settings where cash rounding can be enabled):
- precision `1.00`
- strategy: any
- profit / loss account: any
4. Create an invoice
- Set a Belgian partner (e.g. "BE Company CoA" is okay)
- Set the the cash rounding method from step 2
- Single Line with price=70.00€ and a 21% tax
5. The total should be 85.00 € (84.70 € w/o the rounding)
In the journal items there should be the following
non payment term items:
- 70.00€ base
- 14.70€ tax
- 0.30€ rounding (depending on the cash rounding strategy the tax is set or not)
6. Confirm & Send (with BIS Billing 3.0)
7. Look at the UBL BIS 3 XML in the `Invoice` element
- `TaxTotal/TaxAmount`: 14.70€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€
- `LegalMonetaryTotal/PayableAmount`: 85.00€
8. This fails validation `BR-CO-15`:
```
Invoice total amount with VAT (BT-112)
= Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
```
(`LegalMonetaryTotal/TaxInclusiveAmount` = `LegalMonetaryTotal/TaxExclusiveAmount` + `TaxTotal/TaxAmount`)
Since the cash rounding is included in `LegalMonetaryTotal/TaxInclusiveAmount` but not in
`TaxTotal/TaxAmount` (or `LegalMonetaryTotal/TaxExclusiveAmount`)
#### Tax value correction details (with examples)
Currently we try to fix the tax amounts after importing an invoice.
The function we use for that (`_correct_invoice_tax_amount`) has the following issues:
- We look for `TaxTotal/TaxSubtotal` elements anywhere.
But i.e. such elements can also exist inside `InvoiceLine` elements.
Example:
- module `l10n_dk_oioubl` file `test_xml_oioubl_dk.py`
- function `test_oioubl_import_exemple_file_4` / XML file 'external/BASPRO_01_01_00_Invoice_v2p1.xml'
- The tax total parsed from the document may need to be inverted.
E.g. credit notes can be given as an invoice with negative amounts.
See function `_get_import_document_amount_sign`.
Example:
- module `l10n_account_edi_ubl_cii` file `test_xml_ubl_be.py`
- function `test_import_invoice_xml_open_peppol_examples` / XML file 'bis3_invoice_negative_amounts.xml'
- We compare the tax total from the document only with a single line of that tax.
But there can be multiple lines for a single tax. We have to use the sum of all those lines for the comparison.
Example:
- module `l10n_account_edi_ubl_cii` file `test_xml_ubl_au.py`
- function `test_export_import_invoice` / XML file 'from_odoo/a_nz_out_invoice.xml'
#### The fix
This commit does the following to fix that
1. We include cash rounding lines belonging to a tax in the tax computation for the UBL XML export
(or rather everything any tax computation done with `_prepare_invoice_aggregated_taxes`).
2. After fixing (1) we only have to fix the "Add a rounding line" (`add_invoice_line`) strategy.
This is as follows
- Subtract the cash rounding from the `LegalMonetaryTotal/TaxInclusiveAmount`
- Add node `LegalMonetaryTotal/PayableRoundingAmount` with the value of the cash rounding
3. Cases
- `add_invoice_line`: We create a dedicated invoice line with the amount found in node
`LegalMonetaryTotal/PayableRoundingAmount` (if it is present).
- `biggest_tax`: We update the amount on the tax line to match the value found in the XML.
(Currently we only do this if the difference is not greater than '0.05')
The fixes for the tax value correction on import are also needed for 3./`biggest_tax`.
#### Runbot: example XML after the fix
The export in the example then looks like this for the different cash rounding strategies
- `add_invoice_line`
- `TaxTotal/TaxAmount`: 14.70€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
- `LegalMonetaryTotal/PayableRoundingAmount`: 0.30€
- `LegalMonetaryTotal/PayableAmount`: 85.00€
The validation for the `LegalMonetaryTotal/PayableAmount` is still
okay since (in the example) it is just `LegalMonetaryTotal/TaxInclusiveAmount` + `LegalMonetaryTotal/PayableRoundingAmount`.
- `biggest_tax`
- `TaxTotal/TaxAmount`: 15.00€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 15.00€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€
- `LegalMonetaryTotal/PayableRoundingAmount`: (not exported)
- `LegalMonetaryTotal/PayableAmount`: 85.00€
#### References
Also see
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals
task-4854592
Forward-Port-Of: odoo/odoo#217119
Forward-Port-Of: odoo/odoo#213378Creating a website menu item now works even when a website has no existing menus. This prevents an error screen in the Website Editor and lets users save new menu items normally.
Original PR description
A traceback occurs when a user attempts to create a
menu item from the Website Editor.
**To reproduce this issue:**
1) Install the website_event module and enable debug mode.
2) Delete all existing menus for a website from the Website Configuration.
3) Now, add a menu item from the website/Site/Menu editor.
4) Save the record
**Error:-**
```
KeyError: False
```
**Cause:**
When there are no existing menus on a website and a new menu is created,
the value of parent_id in the data dictionary is False.
Although the `parent_id` key is present, using `.get("parent_id")` returns False,
which leads to a `KeyError` in the following code line:
https://github.com/odoo/odoo/blob/d6db9f910288e69ecd8e26addd20ea34bda81f15/addons/website_event/models/website_menu.py#L83-L88
**Solution:**
We can check the `parent_id` in the data using `in` to solve the issue
if the value of the `parent_id` is False.
opw-4869138
Forward-Port-Of: odoo/odoo#215564This fix prevents completed FPX payments through Razorpay Malaysia from failing because certain payment details are not returned during the redirect flow. Businesses using Razorpay FPX can now accept payments more reliably without customers encountering an error after payment completion.
Original PR description
Steps to reproduce: 1. Create a company based in Malaysia. 2. Configure a Razorpay (Malaysia) account using valid credentials. 3. Enable the FPX payment method for Razorpay. 4. Create a Sales Order and attempt to pay using FPX. Issue: - An error occurs after the payment is completed. Cause: - After this PR: https://github.com/odoo/odoo/pull/163860, we are comparing currency and amount values. However, this information is not available in the data received via the `return_url`. Fix: - Do not compare amount and currency for REDIRECT_PAYMENT_METHOD_CODES. opw-4922299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A migration script was corrected so it can reliably match localization data rows and keep existing translations when converting them to the newer format. This helps prevent translated labels and country-specific accounting or identification data from disappearing during upgrades.
Original PR description
The script failed to find the corresponding rows in the data files, leading to some translations being lost when migrating them to the new syntax. opw-4659964 Forward-Port-Of: odoo/odoo#218461 Forward-Port-Of: odoo/odoo#208454
This change updates a website test so it waits in a controlled way instead of relying on real-time delays. This helps reduce random test failures and keeps development checks faster and more dependable, without changing customer-facing website behavior.
Original PR description
In this commit, we're going to replace the use of setTimeout with advanceTime. No test should use setTimeout to wait for time, you should always use advanceTime. Using setTimout will slow down the test and cause some indeterminate bugs. 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 fix reduces the height of long selection dropdowns in the website builder so they fit within the visible screen. It helps users choose header scroll effects and other builder options without parts of the menu being cut off, especially on smaller windows.
Original PR description
> [ROMO] The dropdown to select the scroll effect for the header is partially hidden on top The size of dropdown of builder select was reduce by cdc74d6e5c1dc2c8d84d028b7b7c0284118a9d66 to avoid going out of viewport but it was not enough Steps to reproduce: - Open website builder - Find a `BuilderSelect` that is long enough (or reduce the window size) - Open it when it is near the middle of the height of the view port - Bug: the end is outside of the viewport task-4367641
Cloning a website Countdown block now hides its end-message preview, making it clearer that the full countdown snippet was copied rather than only the text. The related editing controls are also corrected so users see the right options and a clearer preview toggle.
Original PR description
This commit removes the end message preview of the "Countdown" snippet when cloning it or a snippet containing it. This makes it easier for the user to understand that he cloned the whole snippet and not just the text block. This commit also explicitely activates the `s_countdown` element options when hiding the end message preview. Indeed, if the message block was selected, its options were still activated despite it being hidden. This commit also removes the `text-primary` class from the show/hide message preview option when it is active, to make the eye more visible. task-4367641
Customers using Latin American localization could be blocked from saving a new billing address during checkout when an existing identification type was already set. The form now keeps that identification information during submission, preventing the address from being incorrectly rejected.
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Set up a company & website with Peruvian l10n; 2. add an identification type of "DNI" to your partner data; 3. set the identification number to "09123456"; 5. go to /shop; 6. add product to cart and go to checkout; 7. try to add a new billing address. Issue ----- Cannot save the address, as it thinks you selected the RUC identification type, which is not allowed. Cause ----- When a partner already has an identification type & number, they're not allowed to add new ones to alternate addresses. Issue is that the read-only field added via 5a93da8 is not an actual form field, and doesn't provide its value on submit. Solution -------- Add a hidden `input` element with `l10n_latam_identification_type_id`, after the read-only `t-else` element with a seperate `t-if` to prevent breaking xpaths in stable. opw-4817712 Forward-Port-Of: odoo/odoo#216692
Online shop carts now recalculate the correct taxes when a customer updates their address outside the checkout flow. This helps ensure customers are charged the right tax based on their location before payment.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to…
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to user settings & add an address that matches the fiscal position; 6. go to checkout & pay for the cart. Issue ----- The fiscal position's taxes aren't applied to the order. Cause ----- The `_compute_fiscal_position_id` method is triggered when changing the `partner_id` or `partner_shipping_id` of an order. It does not trigger when modifying the address of the order's current partner. There is logic in place to recompute fiscal position & taxes when an address gets entered via checkout, but not via any other route. Solution -------- Adding address fields to the `api.depends` of the compute method could introduce the unintended behavior of changing taxes & fiscal position of confirmed sale orders. Instead, we can check for fields relevant to fiscal position in `write`, then search for unconfirmed website orders, and recompute their fiscal position & taxes if need be. opw-4844132 opw-4753332 Forward-Port-Of: odoo/odoo#218516 Forward-Port-Of: odoo/odoo#214588
This update fixes how the website and HTML editors reference styling information, avoiding stale cached editor data. It helps ensure editing tools behave correctly when multiple editor instances or reloaded editing frames are involved.
Original PR description
*: html_editor, website The `editableWindow` and `editableDocument` global variables in html_builder's utils_css file were leftovers from the previous codebase. We would rather not cache them that way, as this prevents from having different instances of the builder with different editable documents, and it would also be easy to break it without noticing after an iframe reload. Utils that needed the editableDocument or window mostly needed the iframe's computed style. Therefore, instead of relying on implicit variables, `htmlStyle` is added as a mandatory parameter. task-4367641
Installing the Spanish localization no longer fails if the default Service product category was previously deleted. This prevents an installation-blocking error and helps users complete setup without manually recreating the missing category.
Original PR description
Currently, an error occurs when the user installs the modules after deleting the 'Service' product category. **Steps to reproduce:** - Install the Inventory app. - Inventory > Configuration >…
Currently, an error occurs when the user installs the modules after deleting the 'Service' product category.
**Steps to reproduce:**
- Install the Inventory app.
- Inventory > Configuration > Categories > Delete 'Service'.
- Install the `l10n_es` module.
**Traceback:**
```
ValueError: External ID not found in the system: product.product_category_services
ParseError
while parsing /home/odoo/src/odoo/saas-18.3/addons/l10n_es/data/product_data.xml:3, somewhere inside <record id="product_dua_valuation_21" model="product. Product">
<field name="name">DUA VAT Valuation 21%</field>
<field name="default_code">DUA21</field>
<field name="categ_id" ref="product.product_category_services"/>
<field name="type">service</field>
<field name="sale_ok" eval="False"/>
<field name="purchase_ok" eval="True"/>
</record>
```
The error occurs because the user deleted the category and then installed the modules that reference the missing product category.
This commit resolves the error by providing a False value for the field if the product category is missing.
Sentry - 6710886848
Forward-Port-Of: odoo/odoo#216296This fix prevents Linux-based USB receipt printers from failing to print when another connected USB device has missing manufacturer information. It makes the printer detection process more reliable, reducing interruptions at checkout or other receipt-printing points.
Original PR description
On Linux with a USB connected ESC/POS receipt printer, a traceback can occur in the following conditions: - The printer is successfully initialised as an ESCPOS printer by the `python-escpos` library at driver start - Later, when trying to print, some other USB device causes a traceback in the `usb_matcher` method, preventing the print from taking place The fix is to make the `usb_matcher` method more robust by checking the `manufacturer` property exists before using it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change stabilizes an automated test for mail connection alerts by preventing real network online/offline events from interfering with the test. It helps reduce false failures in Odoo's validation pipeline, making releases and fixes easier to verify.
Original PR description
Before this commit, the `show warning when bus connection encounters issues` test was sometime failing. [1] attempted to fix this issue and seems to have greatly reduced its frequence. However, the bus monitoring service still listens to the "offline" event. As a result, the test can still fails according to the runbot network condition. This commit fixes the issue by preventing the "online"/"offline" events during this test. fixes runbot-226443 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 Forward-Port-Of: odoo/odoo#218415
A minor wording typo was corrected in the portal sharing flow, with a small cleanup to make the related code clearer. This helps keep user-facing text polished and reduces future maintenance risk without changing core behavior.
Original PR description
fix a small typo and and refactor for clarity opw-4938011 Forward-Port-Of: odoo/odoo#218570
This fix prevents errors when users transform certain image shapes in website snippets. It recognizes older shape identifiers and maps them to the current naming, so image editing works reliably.
Original PR description
**Problem** Some snippets contain shapes whose ID starts with `web_editor` instead of `html_builder`. These IDs are not listed in `imageShapeDefinitions` [1], and this generates a traceback when trying to apply shape tranformations. **How to reproduce** 1. Insert the snippet `s_images_constellation` 2. Click on the bottom left image having the "Double Pill" shape 3. Click on any "Transform" button under the "Shape" row in the "Image" section 4. Problem: traceback pops up **Solution** When retrieving the shape ID, a check is performed. If `web_editor` is found at the beginning of the string, it is replaced with `html_builder`. [1] addons/html_builder/static/src/plugins/image/image_shapes_definition.js task-4367641
The shop page now avoids showing the same product category list twice when categories are placed in the sidebar and filters are opened from the offcanvas menu. This makes the shopping interface cleaner and reduces confusion for customers on larger screens.
Original PR description
Steps to reproduce: 1. Go to the shop page. 2. Open the editor and configure Categories to display on the left, and Attributes at the top. 3. Save the changes and click the offcanvas toggle button next to the layout buttons. Issue: - The category list appears twice: once on the left side and again in the offcanvas dropdown. This is redundant and affects the user experience. Cause: - The category list in the offcanvas menu isn’t restricted to mobile view, so it also displays on larger screens where it’s already visible in the sidebar. Fix: - Add the 'd-lg-none' class to hide the category list in the offcanvas menu on large devices. opw-4830180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218330
This fix prevents users from seeing actions like starring or marking messages as read on livechat chatbot messages that are not yet fully saved. Hiding these unavailable actions avoids errors and makes the chat experience more reliable.
Original PR description
**Before this PR:** the toggle-star and mark-as-read actions were visible on chatbot messages in a non-persisted livechat thread. Clicking these actions caused errors. This PR hides these actions when the thread is in a non-persisted state, preventing such errors. task-[4743758](https://www.odoo.com/odoo/project/1519/tasks/4743758) Forward-Port-Of: odoo/odoo#218367 Forward-Port-Of: odoo/odoo#214382
Opening a task's Subtasks action now reliably shows its subtasks, even when the subtasks topbar filter is turned off. This prevents users from thinking subtasks are missing and makes project navigation more consistent.
Original PR description
Steps to reproduce: ---------------- - Install the Project module. - Go to Project and create a project. - Create a task and a subtask. - Deactivate the subtasks topbar in the control panel. - Open the task's form view and click on the Subtasks action. Issue: ----------- Currently, if the subtasks topbar is deactivated and the user clicks on the Subtasks action from the task form view, the subtasks do not appear. Reason: ------------- We are only displaying subtasks if the subtasks topbar is active and when accessed via the My Tasks menu. Fix: -------- We fixed this by checking the subtask_action context in project_task_model_mixin.js. When the user opens subtasks through the subtask action, this context is set, allowing subtasks to be shown even if the topbar is deactivated. Effected Commit- https://github.com/odoo/odoo/pull/213096/commits/268ffa321e12466682b520740b576b71d36eabd5
This fix prevents Odoo from crashing on Ubuntu Jammy systems that use the distribution-provided BeautifulSoup package. It restores support for that environment so related data import and parsing features continue to work reliably.
Original PR description
Ubuntu Jammy ships BeautifulSoup 4.10, which does not have the `XMLParsedAsHTMLWarning` symbol. Because the import guard was removed in #212408 any use of ofxparse or bs4 (directly) on jammy using distro packages will blow up. https://runbot.odoo.com/odoo/error/226555
Deleting attachments is made faster on very large databases by restoring an optimized lookup for related attachment records. This reduces delays during cleanup operations and improves reliability for systems with millions of attachments.
Original PR description
On a DB with 15M+ attachments, deleting a single attachment takes several seconds. Most of the time is spent on the circular `original_id` foreign key.
We add back the index which was removed in [1]
```
Delete on ir_attachment (cost=0.43..8.45 rows=0 width=0) (actual time=0.274..0.274 rows=0 loops=1)
-> Index Scan using ir_attachment_pkey on ir_attachment (cost=0.43..8.45 rows=1 width=6) (actual time=0.252..0.253 rows=1 loops=1)
Index Cond: (id = 82807)
Planning Time: 0.049 ms
Trigger for constraint ir_attachment_original_id_fkey: time=2330.796 calls=1
```
[1] https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
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
Forward-Port-Of: odoo/odoo#218120Turkish Nilvera e-invoice XML notes now include the outstanding invoice amount written in uppercase text, helping meet local formatting requirements. For foreign-currency invoices, the note includes both the Turkish Lira amount and the original currency amount, with zero values correctly written in Turkish.
Original PR description
This commit will add the amount residual in text in the note of the xml we sent to nilvera. If the invoice is in another currency than Turkish Lira, we have to add two notes one for the amount in turkish lira and one in the other currency task-4518269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217910 Forward-Port-Of: odoo/odoo#195938
Checkout no longer presents deliveries billed at actual cost as free when the final amount is not yet known. Instead, customers see a clear notice that the delivery cost will be calculated after delivery, reducing confusion and billing surprises.
Original PR description
Issue: If the delivery invoice policy was set to "real" (meaning that we'll invoice the real delivery cost, after delivery), the delivery was shown as being free on eCommerce (since we don't know the cost yet). Fix: Show a disclaimer indicating that the cost will be computed after delivery. opw-4779059 Forward-Port-Of: odoo/odoo#218378
This fix removes a default grouping setting from attendance reports that caused problems when inserting pivot views into spreadsheets. Spreadsheet users can now add attendance reporting data without duplicated grouping entries breaking the process.
Original PR description
The attendance reporting action had search_default_groupby_name in its context, causing duplicated group_by entries in pivot views used in spreadsheets. This breaks spreadsheet insertion. We removed the default groupby to restore compatibility. Related Task: 4897934. 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 Forward-Port-Of: odoo/odoo#216013
This fix makes cash rounding details optional during electronic invoice generation. It prevents errors when that information is not provided, helping invoice exports continue reliably.
Original PR description
Recently in commit b033a87bbf38ed12364ebf2e3ce0cefb2670470f the UBL generation was improved to handle cash rounding better. I.e. a new key 'cash_rounding_base_lines' was introduced to the `vals` used in the generation. This commit makes it optional to avoid tracebacks in case it is forgotten to be added. task-None Forward-Port-Of: odoo/odoo#218621
Customers will now see out-of-stock messages even when a product is available through the "pick up in store" option. This helps shoppers understand product availability more clearly and reduces confusion during online purchases.
Original PR description
Before the commit, when a 'pick up in store' was published, the out-of-stock message was hidden to avoid confusion. However, customers want to benefit from it, and now we reintroduce it. opw-4791969 Forward-Port-Of: odoo/odoo#218472 Forward-Port-Of: odoo/odoo#218284
This update makes live chat session history and tour tests run consistently by ensuring chats are ordered predictably and UI actions wait until the page is ready. It helps reduce false test failures, improving confidence in releases without changing day-to-day user behavior.
Original PR description
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 Forward-Port-Of: odoo/odoo#218103
When customers change the number of people for an appointment, the date they already selected now remains highlighted and active. This avoids confusion during booking and helps users continue the scheduling flow without reselecting the date.
Original PR description
Step to reproduce: 1. Install appointment and website 2. Go to Appointment > create a new appointment with availability on 'resources' 3. select a 'resource' and check 'manage capacities' 4. go to…
Step to reproduce: 1. Install appointment and website 2. Go to Appointment > create a new appointment with availability on 'resources' 3. select a 'resource' and check 'manage capacities' 4. go to website by smart button 5. Select a date slot. 6. Select the Number of People. Issue: - Previously selected date gets visually deselected or does not retain active state after changing the number of people. Cause: https://github.com/odoo/enterprise/blob/955edd68837c3a8302dcd34b1a6edee28e95ba23/appointment/static/src/interactions/appointment_select_appointment_slot.js#L460 - The logic attempted to restore the previously selected date by calling .click() on the date element. However, this click() call silently failed to trigger the desired behavior. Solution: - Instead of relying on .click() to re-trigger the selection, the handler onClickDaySlot() is now called directly, passing the appropriate DOM element as currentTarget. opw-4859743 Forward-Port-Of: odoo/enterprise#87514
Customers who choose a subscription plan different from the default now get the correct pricing in their cart. This prevents checkout confusion and helps ensure orders reflect the buyer's intended plan.
Original PR description
Selecting another plan than the default one didn't work because it wasn't considered when looking for the applicable pricing.
This update ensures Colombian electronic invoice files correctly handle cash rounding and include rounding-related tax lines. This helps keep tax totals accurate and compliant when invoices use cash rounding.
Original PR description
#### [FIX] l10n_co_dian: UBL related cash rounding issues In the community PR the UBL XML generation was adjusted to support cash rounding. (See there for more details) This commit adjusts the code in `l10n_co_dian` to be compatible. #### [FIX] l10_co_edi: tax_amls include rounding lines Currently rounding lines (with taxes) are not included in the tax lines. This is fixed in this commit. See the community PR / commits for motivation. #### info task-4854592 Forward-Port-Of: odoo/enterprise#89439
This update corrects a translation maintenance process across multiple country-specific reporting modules. It helps keep localized report labels and translated content consistent, reducing the risk of incorrect or missing wording for users in affected regions.
Original PR description
Forward-Port-Of: odoo/enterprise#90004 Forward-Port-Of: odoo/enterprise#84682
Bank reconciliation now uses the same safeguards as journal entry analytic updates, preventing unwanted update loops and keeping analytic information in sync. This helps ensure reconciliation stays reliable when analytic distributions are changed.
Original PR description
Since a recent fix[^1], the analytic distribution on journal entries is updated with any update made on analytic items. In order to avoid loops and do things in the right order, a context key was added. However, the reconciliation widget was also manipulating analytic items, so it needed to use the context key as well. opw-4936028 opw-4933629 opw-4935236 opw-4933456 opw-4933652 opw-4935789 opw-4938570 opw-4938388 opw-4935709 opw-4940233 opw-4938849 [^1]: https://github.com/odoo/odoo/commit/8194c6e2bfedc9437964090b1a498c3e8cff225c Forward-Port-Of: odoo/enterprise#90175
Helpdesk tickets created directly in a closed stage are now correctly marked as closed. This prevents customers using the portal from seeing already closed tickets when they apply the Open Tickets filter, reducing confusion and improving ticket visibility.
Original PR description
**Steps to reproduce:** 1. Install the Helpdesk module. 2. Create a ticket directly in a closed stage (e.g., 'Solved') and add the portal user as a customer. 3. Log in as the portal user. 4. Apply the Open filter. **Issue:** - The ticket appears under Open Tickets, even though it was created in a closed stage. **Cause:** - Currently we consider a stage as closed if 'floded in kanban' is True and When a ticket is created directly in a closed stage, the close_date field is not set. Since the portal filter relies on close_date to distinguish open from closed tickets, this shows closed tickets in open filter. https://github.com/odoo/enterprise/blob/c34256932e593ac2774fa65af813d64edb70ec43/helpdesk/controllers/portal.py#L63 **Solution:** - During ticket creation, if the specified stage is a closing stage, set the close_date field to the current time. opw-4847097 Forward-Port-Of: odoo/enterprise#88983 Forward-Port-Of: odoo/enterprise#87293
The VoIP softphone now uses a minimize icon instead of a minus icon, aligning the interface with designer feedback. This small visual change makes the control clearer and more consistent for users.
Original PR description
Following feedback from the designers. Forward-Port-Of: odoo/enterprise#89949
Fixed an issue in barcode receipt processing where changing the unit of measure updated the completed quantity but left the reserved quantity unchanged. This keeps inventory demand and received quantities aligned, reducing confusion and potential stock discrepancies during warehouse operations.
Original PR description
Steps to reproduce:
- Create a storable product “P1”:
- UoM: Unit
- Create a receipt for 200 units of P1
- Mark it as To Do
- Go to the barcode module and start processing the receipt
- Edit the quantity:
- Set it to 2 and change the UoM to Dozen
- Save
Problem
The quantity done is correctly set to 2 dozens, But the reserved quantity remains 200
Solution:
When the UoM is changed, compute and update the reserved quantity accordingly
OPW-4716104
Forward-Port-Of: odoo/enterprise#89131
Forward-Port-Of: odoo/enterprise#85004Creating an Anniversary Discount campaign in Marketing Automation could fail because the customer selection rules were built incorrectly. This update rebuilds and simplifies those rules so the campaign can be created reliably without changing the intended targeting logic.
Original PR description
We had a traceback when trying to create an Anniversary Discount marketing campaing
due to the domain's construction.
Steps to reproduce:
-------------------
* Go to Marketing Automation app
* Go to eCommerce tab --> anniversary discount
* Click " Create Campaign"
> Observation:
File "/data/build/enterprise/marketing_automation/models/marketing_activity.py", line 142, in _compute_inherited_domain
literal_eval(activity.campaign_id.domain or '[]')])
Why the fix:
------------
The problematic line was introduced in this REV: 1aa05c89f3371981922e3dc52d8334104aa425b9.
The domain was originally built in this IMP: cf2124f4f20a805077502587f9a8be0af0a753c3.
The domain was intended to be used dynamically, but after the revision, that usage changed—so the domain needed to be rebuilt.
We've simplified the domain to eliminate overlapping conditions, ensuring the same logic and result, but with improved readability.
opw-4857722
Forward-Port-Of: odoo/enterprise#89375Belgian companies can once again export the Social Balance Sheet report in PDF or XLSX without hitting an error. The fix updates the report export logic to match the current payroll versioning behavior, preventing a crash during a routine reporting task.
Original PR description
Since the introduction of versions, a traceback occurs due to an old function call Task: 4911701
Italian POS fiscal receipts and invoices now rely on the fiscal printer's built-in header instead of adding a second one. This prevents customers and staff from receiving receipts with duplicated header information, making printed documents cleaner and compliant with printer behavior.
Original PR description
The printer is already adding a header by default so we don't need to add one manually. Steps to reproduce: ------------------- * Setup an Italian fiscal printer in the POS * Open the POS and create a new order * Add a product and validate the order > Observation: The printed receipt has 2 headers. Why the fix: ------------ According to the Italian fiscal printer documentation, the header is automatically added by the printer, so we don't need to add it manually. Ticket before and after the fix:  opw-4794322 Forward-Port-Of: odoo/enterprise#89856 Forward-Port-Of: odoo/enterprise#89419
Belgian payroll reporting has been updated to match the 2025/2 DmfA requirements. This helps ensure payroll declarations remain compliant with the latest official reporting rules.
Original PR description
Forward-Port-Of: odoo/enterprise#90016