Monday, April 20, 2026
19 changes · 19.0
Resolved issues and error corrections
The Indian withholding tax setup now requires an aggregation period whenever aggregate limits are enabled. This prevents invoice creation from failing if that required period was accidentally cleared.
Original PR description
Previously, if `is_aggregate_limit` was set to True while `aggregate_period` was left empty, it would raise a traceback during invoice creation. Although `aggregate_period` has a default value, it can still be manually cleared. With this commit, `aggregate_period` is enforced as mandatory whenever `is_aggregate_limit` is enabled, preventing such errors. Forward-Port-Of: odoo/odoo#259737 Forward-Port-Of: odoo/odoo#259634
This update corrects an issue in stock accounting related to product valuation records. It helps ensure inventory values remain accurate for accounting and reporting purposes.
A typo was fixed in an internal warning message about SQL constraints. This makes developer-facing guidance clearer and helps reduce confusion when configuring constraints, with no expected impact on normal business workflows.
Original PR description
In this commit: --------------- - Corrected a typo in the SQL constraint warning message, updated `model.Constraint` to `models.constraint`. Forward-Port-Of: odoo/odoo#259867
The Inventory move history screen no longer lets users edit a reference value that cannot actually be saved. This prevents confusion where a user could make a change, save, and later see the original value restored.
Original PR description
### Issue before this commit: Before this commit, the Reference field displayed on stock.move.line was editable in the user interface, even if the modification made by the user was not persisted.…
### Issue before this commit: Before this commit, the Reference field displayed on stock.move.line was editable in the user interface, even if the modification made by the user was not persisted. After saving and reloading the Move History view, the original value was restored. ### Steps to reproduce the issue: 1. Go to Move history in Inventory app 2. Try to change the name of a line and save 3. If you go back to the Move history you can see that the name is not changed ### Cause of the issue: The issue was caused by a mismatch between the stock.move.line.reference field and its target field stock.move.reference. The field on stock.move.line is a related field that appears editable (readonly=False), but the underlying stock.move.reference field was not writable. As a result, user could edit the field but the modifications were ignored, preventing changes from being effectively saved. ### Reason to introduce the fix: The fix ensures that the reference field in stock.move and in stock.move.line are readonly. opw-6055708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256434
ECpay invoice PDFs now include the item unit of measure in the remarks column. This makes returned documents easier to understand by showing details such as "商品單位: Units" alongside each item.
Original PR description
Issue: -- The documents returned by the ECpay API can be confusing as it does not include the measurement (UOM). The make it clearer a description is provided to ECpay through the json with the Key "ItemRemark" Current behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 Expected behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 商品單位: Units opw-6070269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259536
This fixes an error that could appear when editing a blog post cover and adding multiple tags. Users can now add new and existing tags without the page editor showing a traceback.
Original PR description
# How to reproduce - Go to a blog page and edit the Blog Post Cover - Add a tag - Try to add another one # The problem A traceback is shown # Why When adding a new record for a many 2 many relation, the framework ensure the user cannot create a record with a name that already exists via a name search. This commit (https://github.com/odoo/odoo/commit/3631757a4766bc59378bb975e01e115c92ef1dd4) changed the way the name search is done to add this domain to the request : ```py domain.push(["id", "not in", selectedIds]); ``` But selectedIds can contain strings in the case of uncreated records, which causes the SQL query to throw an error trying to match the model id with strings opw-5978305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251469
This fix prevents Odoo from running a garbage collection timing callback after parts of the system have already been shut down. It avoids harmless but confusing errors during server shutdown, improving reliability and log clarity.
Original PR description
Odoo registers a callback function to track how much time is spent in garbage collection. But while the Python interpreter is shutting down and clearing out global modules and variables to free up memory and the Garbage Collector triggers one last time, the callback function `_timing_gc_callback` tries to run, but the function it depends on (like time.thread_time_ns) have already been set to None by the interpreter. Forward-Port-Of: odoo/odoo#259328
A point of sale test was corrected so its sample product barcode matches the expected GS1 format. This helps keep automated checks reliable and prevents false failures during development, without changing day-to-day user behavior.
Original PR description
The test_GS1_pos_barcodes_scan was failing because the "GS1 Variant Product" barcode was defined as a 13-digit string, while the tour scans it using the GS1 AI 01 (GTIN), which expects a 14-digit GTIN-14. By adding a leading zero to the barcode in the test setup, we align it with the GTIN-14 format parsed by the POS barcode parser during the scan, ensuring the product is correctly added to the order. runbot-error: 242323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258089
This fixes an internal cleanup issue where custom fields linked to standard fields could accumulate during system reloads. It helps keep the system stable and avoids unnecessary memory or performance issues over time.
Original PR description
When a custom (manual) field is related to a base field, it is added to `registry.field_setup_dependents`. However, these custom fields were not being cleaned up correctly, causing them to duplicate and leak during each model setup. This fix explicitly cleans these manual fields from `field_setup_dependents` inside `_add_manual_models()` when manual models are removed from the registry and the registry is being reloaded. Similar to https://github.com/odoo/odoo/pull/253377.
This fixes an issue where users could encounter an error while editing a scheduled chatter message and removing an attachment. The editor now safely handles this case, making scheduled message updates more reliable.
Original PR description
scheduled message editor Problem: When editing a scheduled chatter message, removing an attachment raises a traceback. Cause: `fullComposerBus` is available in the `Composer` environment but not in `ScheduledMessage`. The code assumed its presence and attempted to use it unconditionally. Solution: Check whether `fullComposerBus` exists in `env` before using it. Steps to reproduce: - Add a log note. - Open the full Composer. - Add an attachment. - Schedule the message. - Save. - Edit the scheduled message. - Remove the attachment from the attachments list. - Observe a traceback. opw-6098302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how retry messages are handled in automated build logs, so expected retry notices are no longer shown as prominent warnings. This makes build logs cleaner and easier for teams to review when diagnosing real issues.
Original PR description
While moving the logic from common to suite, the logger was changed from common._logger to suite._logger, but the monkeypatching was not updated, resulting in the "Retrying" logs not being downgraded to info and spamming the logs of the builds.
This update fixes an internal testing issue where retried tests could keep using outdated test information. It helps make automated test runs more reliable and reduces the chance of misleading failures during development.
Original PR description
When a test is retried, the current_test variable was not updated to the new test instance, which could lead to issues when opening a test cursor. This commit ensures that current_test is updated on each retry attempt. While there update the condition to have a stronger check in this specific case since test equality only uses test name
The domain selector and expression editor now show numbers using the user's local decimal and thousands separators. This makes filter values easier to read and avoids confusion, while keeping the underlying expression data unchanged.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. 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#259436 Forward-Port-Of: odoo/odoo#258287
This fixes a website builder issue where file names added with the /file command could hide their translation status when viewed in translation mode. Business users translating websites can now more easily see which uploaded file labels still need translation.
Original PR description
Commit cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 added a resource to repeat the background color of the translation state inside elements, for the cases where an element has a background color that hides the translation state. This commit uses the resource for file's names (added by typing `/file`) Steps to reproduce: - Open website builder - Type `/file` and add a file - Add a language - Open in translate mode - Bug: the translation state is not show on the file name task-6038029 Forward-Port-Of: odoo/odoo#259902
The self-ordering flow now sends only the information the frontend actually needs. This reduces unnecessary data transfer and helps keep the customer ordering experience leaner without changing visible functionality.
Original PR description
Fix _generate_return_values to remove some fields that are not needed on the frontend Forward-Port-Of: odoo/odoo#259915
Invoice emails now name dynamic report attachments using the configured Printed Report Name when one is set. This prevents customers and staff from seeing generic or inconsistent attachment names and keeps invoice email documents aligned with business naming rules.
Original PR description
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice…
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number). This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself. To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved. The fix will ensure extra dynamic reports follow their configured printed name. Steps to reproduce: 1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. 2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). 3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”. 4. Add the duplicated report under Dynamic Reports. 5. Create a customer invoice and confirm it. 3. Click Send (or Send & Print) to open the email preview. Related Ticket: opw-6058716 Forward-Port-Of: odoo/odoo#259767 Forward-Port-Of: odoo/odoo#259267
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
This update prevents the barcode app from showing a stock location warning when users add non-storable products to a delivery. It makes the flow smoother and avoids confusing prompts that do not apply to products that are not kept in inventory.
Original PR description
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P…
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P as product > Confirm #### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there? ### Expected behavior: Since the product is not storable it should not trigger the dialog ### Cause of the issue: The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant. opw-6110655
Miscellaneous changes
Fixes the merge conflict in the Slovak translation file.
Original PR description
Fixes the merge conflict in the Slovak translation file.