Daily updates from Odoo
Friday, October 24, 2025
20 changes · 19.0
New functionality added to Odoo
Finnish accounting reports can now generate an export file for tax reporting, helping customers submit required tax information to the Finnish administration more easily. The update also improves automated checks so report export files are generated with the correct settings.
Original PR description
The aim of this commit is adding the tax report export file to allow our customers to send their tax reports to their administration. task-5135868 Forward-Port-Of: odoo/enterprise#97867 Forward-Port-Of: odoo/enterprise#96256
Enhancements to existing features
This improves the speed of switching a product category between manual and real-time inventory valuation, especially for categories with very large numbers of product variants. In the reported case, a process that previously timed out after more than 15 minutes completed in about 18 seconds, reducing delays for inventory and accounting operations.
Original PR description
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish…
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation. This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance. This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase. A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here. #### speedup In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231206
Hong Kong payroll declaration forms now include chatter, allowing users to track discussions and activity directly on the forms. This improves collaboration and record visibility for teams handling payroll declarations.
Original PR description
Based on HK feedback, chatter is added on their declaration forms task:5067386
The German tax report has been reworked after the balance column was removed, ensuring the report logic and tests match the new layout. This helps keep German tax reporting accurate and consistent for businesses using Odoo.
Original PR description
After removing the balance column, we need to refactor the code that depends on it task-5046641
The German tax report has been reorganized to better match the official ELSTER VAT filing structure. This makes the report easier to follow for German businesses and helps align Odoo's tax reporting with expected filing categories.
Original PR description
Rework the structure of the German Tax Report according to the very well detailed structure https://sevdesk.de/ratgeber/buchhaltung-finanzen/ustva/formular-elster/ task-5046641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The China ASBE balance sheet report now classifies liabilities correctly and includes previously omitted report data. This helps ensure financial statements balance as expected and improves confidence in statutory reporting.
Original PR description
Fixes the balance_sheet_balanced test for asbe where the wrong line was set as liability. Also fixes the report itself that was ignoring one line, and missing one account. task-5175789 Forward-Port-Of: odoo/enterprise#97720 Forward-Port-Of: odoo/enterprise#97460
This fix changes the Vietnam localization migration so tax updates are applied more selectively. Businesses keep their customized accounting settings during the update, reducing the risk of unexpected configuration changes.
Original PR description
Problem The previous implementation used try_loading() which would reload the entire chart template, potentially overwriting user-customized configurations settings. Solution Replaced try_loading() with a more targeted approach usin _load_data for account.tax.group and account.tax 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#229476 Forward-Port-Of: odoo/odoo#227918
Fixes a problem that could stop very large email campaigns from being retried after a mail server outage. Failed emails are now retried in smaller batches, helping larger customers recover campaigns with hundreds of thousands of recipients more reliably.
Original PR description
Steps to reproduce the issue: 1. Have 100s of thousands of recipients on a campaign 2. Disconnect your outgoing server and send 3. Reconnect the mailing server and retry sending. Current behavior before PR: A `MemoryError` is raised due to the large number of emails processed to `unlink()` Desired behavior after PR is merged: Larger-scale clients would be able to resend 100s of thousands of emails if they fail opw-5091567 Forward-Port-Of: odoo/odoo#228446
Subscription orders that use an external tax calculator now keep the externally calculated amounts when showing recurring totals. This prevents recurring totals from being recalculated incorrectly and helps customers see accurate subscription charges.
Original PR description
sale_subscription now uses `account.tax` to recalculate the tax amounts [1], thus bypassing amounts set by external calculators. For externally calculated orders, we override the recurring_total calculation to restore the previous behavior of calculating the amount using `price_subtotal` on the lines. This field will contain the amount returned by the external calculator. [1] https://github.com/odoo/enterprise/commit/70376f94e9f26e631890312edc0857d9ff37dc7b opw-4964610 Forward-Port-Of: odoo/enterprise#94855 Forward-Port-Of: odoo/enterprise#93054
This fix prevents crashes when users quickly drag and drop multiple cards in large grouped Kanban views. It makes the interface handle background refreshes more safely, improving stability for teams working with many records at once.
Original PR description
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this…
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this commit, different crashes could occur. The first category of crashes concern the sortable hook. It called the onDrop callback even if the dragged element was no longer in the DOM (which occurs if there's a re-rendering while the user is dragging). This has been fixed in the hook, and tested. Another crash could arise in kanban (in the model). If the user dropped the card while there was a scheduled/ongoing re-rendering, i.e. at a specific moment where the model isn't synchronized with the DOM, the dropped card was still in the DOM, but it's associated datapoint was no longer referenced in hte model. In that case, we can do nothing but cancel the d&d. Note that this couldn't be tested, as reproducing the exact behavior (typically having a slow rendering due to the number of cards to render) isn't possible in a unit test, where user interactions are done programmatically. Task~5167650 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#232353 Forward-Port-Of: odoo/odoo#231886
SEPA payment files using the Belgian pain.001.001.03 format now include the required end-to-end payment reference correctly. This prevents generated bank files from containing an empty reference field, reducing the risk of bank rejection or reconciliation issues.
Original PR description
The XML of the sepa file in format `pain.001.001.03` in `l10n_be` has a missing `EndToEndId` tag. - Configure the bank to use the `pain.001.001.03` sepa xml format. - Generate a payment using sepa. Create a batch for this payment and validate. - The resulting xml has an empty `EndToEndId` tag. Commit fa08eac141956141bc12c1d5619bd57f487c36e9 removed the end_to_end_id used in the tag. The correct format of the tag is end_to_end_uuid. opw-5150525
Website administrators can no longer delete custom fields that are still used in website forms. This prevents crashes when editing forms and guides users to remove the field from the form before deleting it.
Original PR description
The system crashes when a user tries to edit a website form field and that field has already been deleted from the model. **Steps to produce:-** - Install the `website` module. - Create a `new custom…
The system crashes when a user tries to edit a website form field and that field has already been deleted from the model. **Steps to produce:-** - Install the `website` module. - Create a `new custom field` on a model(for example, a field on the `mail.mail` model). - Website > edit > `add Form` widget to a page, and configure it to use the `mail.mail` model. - Add the newly created custom field to the form and save the page. - Now, `delete` the custom field which is created previously. - Return to the website page > edit > mark the deleted field as required, and attempt to save the changes. **Error:-** `ValueError: Unable to whitelist field(s) [''] for model 'mail.mail'.` **Root cause:-** - At [1], we can see that in the current version, it `only logs an error` using the logger, but in later versions, it `raises a ValueError` instead. **Solution:-** - This fix prevents a field from being deleted if it is actively used in any website form. - It adds a validation check that blocks the deletion and raises an error, forcing the user to remove the field from the form first. [1]: https://github.com/odoo/odoo/blob/d4f424d731fa93ccd232d0def0a7612997345ef7/addons/website/models/website_form.py#L123-L126 **sentry-5689731444** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232707 Forward-Port-Of: odoo/odoo#219590
This fix makes the Backspace key behave predictably when editing bold or otherwise formatted empty paragraphs in the HTML editor. Users should no longer see empty paragraphs remain stuck or multiple paragraphs disappear unexpectedly, reducing accidental content loss while editing.
Original PR description
Steps to Reproduce Issue 1 - Apply bold on an empty paragraph using **Ctrl+B** and press Enter. - Press Backspace - the paragraph is not removed. Issue 2 - Write some text. Apply bold on that text. -…
Steps to Reproduce Issue 1 - Apply bold on an empty paragraph using **Ctrl+B** and press Enter. - Press Backspace - the paragraph is not removed. Issue 2 - Write some text. Apply bold on that text. - Press Enter multiple times to create 2–3 new paragraphs. - Press Backspace. - A single backspace removes multiple paragraphs at once, and the cursor jumps back to the paragraph with the text. Description of the issue: After a recent commit [1], only a **zws** is inserted inside blocks containing empty inline elements. As a result, when an inline element contains only a **zws**, `adjacentLeafFromPos` returns the **zws** as a leaf node. Since **zws** is not a visible character and there are no visible characters nearby, it is not treated as a valid stop point, and the traversal continues searching for a visible character. - In the first case, no visible character is found, so backspace does nothing and the block remains undeleted. - In the second case, a visible character is eventually found further away, so all blocks between that character and the current selection are removed in a single operation, causing multiple paragraphs to be deleted at once. Solution: The fix ensures that when a block is empty and a block switch occurs, the **zws** is returned immediately instead of continuing the traversal. This prevents backspace from skipping or deleting multiple blocks unexpectedly. task:5071252 [1]: https://github.com/odoo/odoo/pull/220568/commits/1cc0670aa4d8f1552ff6ea0cba304c8c74ffc263
This fixes an issue in Point of Sale where the cash drawer would not open if an unrelated IoT box was unreachable. Cashiers can now use an ePOS printer-connected cash drawer reliably, even when another configured device is offline.
Original PR description
Steps to reproduce: 1. Configure a POS to use an ePOS printer with the cashdrawer enabled. 2. Also configure the POS to use an IoT box with a dummy device, e.g. '[Shop] Scale'. The important thing is that the IoT box is not reachable when the POS opens, so the dummy devices work well for this. 3. Open the POS, make an order and go to payment, then click 'Open cashbox'. Expected behaviour: The cashdrawer opens Actual behaviour: Nothing happens task-5059502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232852 Forward-Port-Of: odoo/odoo#232797
Fixed an issue where landscape reports printed through a Virtual IoT Box could come out as cropped portrait pages. The printing process now fits PDF pages to the selected paper format, helping documents print in the expected orientation.
Original PR description
When printing a landscape report using a Virtual IoT Box, we end up printing a portrait page cropped. This commit adds the "pdf fit page" argument to ensure the page printed follows the report orientation. opw-5051809 Task: 5149706 Forward-Port-Of: odoo/odoo#232952 Forward-Port-Of: odoo/odoo#232866
This fix ensures POS payments through Six terminals correctly identify the currently logged-in cashier, even when another user opened the session. It prevents payment startup issues caused by missing user information in shared or multi-tab POS workflows.
Original PR description
This commit fixes an undefined `user_id` on the pos session when trying to start a payment with a Six terminal from another user than the one that started the session. Before this commit: - open a pos session with Mitchell Admin, - check the value of `pos.session.user_id` (it will be `2`), - open another tab and connect as Marc Demo, - check the value of `pos.session.user_id` again: it should be `6`, but instead is `undefined`. After this commit: We use `pos.user.id` instead of `pos.session.user_id.id` to get the user ID. opw-5055977 Forward-Port-Of: odoo/enterprise#98021 Forward-Port-Of: odoo/enterprise#97975
This fixes manufacturing order cost overviews so component costs are calculated using the correct unit of measure. Businesses using bills of materials with units like liters and milliliters will now see accurate production costs instead of inflated values.
Original PR description
**Problem:** The overview of a produced MO does not take into account the uom of the component for the valuation **Steps to reproduce:** - Create a storable product (the comp) - set the uom as L and the cost as 40$ per L - set an on hand quantity - Create a storable product (the final product) - Create a bom for this final product using 100 ml of the comp - Create, confirm and produce a MO for the final product - click on the overview smart button **Current behavior:** the real cost is 4000$ (100*40) **Expected behavior:** it should be 4 (0.1 * 40) **Cause of the issue:** https://github.com/odoo/odoo/blob/11cbbb85b1ee2a620d752b79e86fc51a8e3b33e4/addons/stock_account/models/stock_move.py#L191-L198 _get_price_unit() does not take into account the case where the uom of the move is not the uom of the product opw-5102760
Sales commission achievement reports now return the correct grouped results instead of often appearing empty. This helps managers and sales teams review commission achievements reliably when using grouped report views.
Original PR description
Before this commit, grouping achievements would result in empty list most of the time. It happened because offset and limit were switched by mistake in the override. As a result an offset of 80 was applied in the request during group by. Forward-Port-Of: odoo/enterprise#97959
Fixed-tax amounts now correctly become negative when applied to invoice lines with negative prices. This prevents tax totals from showing the wrong sign on refunds, credits, or other negative invoice lines, improving accounting accuracy.
Original PR description
Steps to reproduce: 1. Create a fixed tax 2. Create a invoice with a product with negative price Problem: The amount of the tax is positive while the line is negative. opw-5128767 Forward-Port-Of: odoo/odoo#232394 Forward-Port-Of: odoo/odoo#232084
In multi-company setups, shared accounts can no longer be deleted when they are still used by journal entries in another company. This prevents accidental loss of accounting references and keeps financial records consistent across companies.
Original PR description
In a multi-company environment, accounts can be shared. A Python constraint prevents deleting an account if it has journal items in the current company. However, this check was missing when an account only contained journal items belonging to other shared companies. This commit fixes the issue by: 1. Updating the `ondelete` attribute of the `account_id` field on `account.move.line` to cascade the restriction at the database level. 2. Updating the existing Python constraint on `account.account` to enforce this logic in stable versions without a module update (this will be removed in the master branch). task-5158966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232957 Forward-Port-Of: odoo/odoo#232530