Monday, November 3, 2025
20 changes · 19.0
Enhancements to existing features
Estonian VAT report XML exports now process large batches of accounting entries together instead of recalculating each line separately. This prevents timeouts on high-volume periods and makes monthly VAT filing more reliable for companies with many transactions.
Original PR description
Behavior before: When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this…
Behavior before: When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors. Behavior after: Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets. Root cause: The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation. Benchmark: | Period size (journal items) | Before patch | After patch | |----------------------------------------|----------------------|--------------------| | ~15k | 7s | 5s | | ~200k+ | Timeout error| 21s | opw-5046077 Forward-Port-Of: odoo/enterprise#97660 Forward-Port-Of: odoo/enterprise#95047
This update makes GST return section assignment more accurate when Odoo prepares tax information for Indian accounting flows. It helps ensure moves are classified correctly, reducing the risk of incorrect reporting in GSTR-related processes.
Original PR description
This PR introduces enhancements to the `_set_l10n_in_gstr_section` method, including: -Calling `_get_l10n_in_tax_tag_ids` directly on all moves instead of ines. -Improving the logic for assigning GSTR section values.
This update makes it possible to place the cursor in spots that were previously blocked, such as between protected blocks, between tables, or at the very start or end of a page. It improves the editing experience by letting users type naturally in these edge cases and reduces unwanted extra spacing or empty paragraphs.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/96484 Currently, there is no way to put our cursor between two `contenteditable=false` blocks, between two tables, before the first block in the editable or after the last one. This introduces placeholder blocks with no height in these places, in which the user can put their selection (which will show as a horizontal blinking line). They can then start typing and the placeholder will be persisted. At the end of the document, this is bypassed and the placeholder will be persisted as soon as the selection is in it. task-4129699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the Starshipit delivery workflow by allowing shipping labels to be printed in batches instead of one by one. It also adds the sales order reference to the label’s order number, making it quicker to match labels with the correct orders.
Original PR description
Adds two improvements to the usability of the module by supporting printing starshipit labels in batch, and also adding the SO reference to the order number to more easily match the label with it. task-4821727
This update adds dedicated menus for sales and purchase accruals, making it easier to review expected revenue and expenses from one place. It also lets users inspect values as of a chosen date and opens the related order directly for quicker follow-up.
Original PR description
*: purchase_accountant,sale_account_accountant This commit adds new menu for SO and PO accruals. A custom list view (`js_class`) was created for those reports: `accrual_list_view`. AccrualListView…
*: purchase_accountant,sale_account_accountant This commit adds new menu for SO and PO accruals. A custom list view (`js_class`) was created for those reports: `accrual_list_view`. AccrualListView =============== This view is used both by `sale.order.line` and `purchase.order.line`. Its functionnalities are: - The user can choose a date to see records' values in the past; - If a line is clicked, instead of opening the line's form view, it will open its order form view instead. Technical notes about this view: - The chosen date is passed to the context but there is issue when the view is grouped (and it is by default): while the grouped lines uses the right context with the selected date, the contained lines sometime use an old version of this context with a previously selected date which means the grouped data are not the same than the single lines data. To fix that, we force the context on each group. - The "at_date" fields are non-stored computed fields. By default, there is no sum value for those fields. Server side, we override the `_read_group` method to "manually" compute those fields sum. To be able to do that, we tweak the aggregate config in this view. Boolean fields ============== Four boolean fields are created: - `prepaid_expense` and `bill_to_receive` for `purchase.order.line`; - `deferred_revenue` and `invoice_to_be_issued` for `sale.order.line`. Those fields are usefull to fetch right order lines for the right accrual and are always a balance between delivered/received quantity and invoiced quantity. [task-5075455](https://www.odoo.com/odoo/966/tasks/5075455) Community PR: odoo/odoo#231510
This change makes fiscal rates easier to review by showing the current rate and fiscal category directly in account lists. It also improves audit warnings so they only appear when relevant activity exists in the selected period, and makes the warning clickable to help users quickly find the affected accounts.
Original PR description
[IMP] account_fiscal_categories: enhance list view of account_account ====================================================== With this commit, we add a new field `current_rate` in `account.account`.…
[IMP] account_fiscal_categories: enhance list view of account_account ====================================================== With this commit, we add a new field `current_rate` in `account.account`. This `current_rate` is a non-stored compute field, used to compute the current applicable rate on the given account. This `current_rate` and `fiscal_category_id` has been introduced in the list view of `account.account`. [IMP] account_fiscal_categories: enhance multiple rate warning in fiscal report =========================================================== Before this commit, the "multiple rate" warning was shown even when no entries for accounts with multiple rates existed in the selected period. This happened because all accounts were considered for multiple rates, regardless of journal entries in that period. After this commit, only accounts with entries in the selected period are considered for the "multiple rates" warning. The warning is now clickable, redirecting the user to the accounts having multiple rates. [FIX] l10n_be_fiscal_categories: remove redundant rate on CoA ================================================= This commit removes the redundant fiscal rate on account-613311. Both fiscal categories 1206 and 1073 were assigned to this account, resulting in two rates. Only 1073 should be there. ref-https://github.com/odoo/enterprise/commit/f2579a80833ac129b2f21613b93c4e3203646a1b **task**-5163392 -----------------------
Resolved issues and error corrections
Fixes an issue where changing quantities for multiple combo products in an unsaved sales order could move the related combo items into the wrong position. This helps sales users keep orders clear and accurate while editing, reducing the risk of confusing or incorrect order lines.
Original PR description
Steps to Reproduce: - Create a Sale Order containing two combo products placed consecutively. - Change the quantity of the first combo → corresponding combo items update correctly. - Without saving,…
Steps to Reproduce: - Create a Sale Order containing two combo products placed consecutively. - Change the quantity of the first combo → corresponding combo items update correctly. - Without saving, change the quantity of the second combo. - Observe that the combo items now appear misplaced — items from the second combo are inserted before those of the first combo. Issue: - The order of combo items becomes incorrect when multiple combo products are updated consecutively in the same unsaved Sale Order. Cause: - During `onchange`, the `self.order_line` recordset reflects the *in-memory order of applied commands* rather than the database `sequence` field because they are not saved in the DB during the edition. - Each `onchange` rebuilds `order_line` using concatenated command lists (`delete + create + update`), So when multiple combos are modified without save, newly created combo items are appended according to command evaluation order — not by logical grouping. - This causes combo items to shift relative to their parent combo lines. Solution: - Restrict the recomputation of order lines to non-combo lines by filtering out combo item lines during the rebuild. As combo items will always be in their desired sequence. - This ensures that combo items always stay under their respective parent combos and their sequence is preserved, regardless of the order in which combos are updated. opw-5148770 Affected Version:18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233740
This fixes an issue in the website editor where undoing a change could restore text or elements in the wrong order in some browsers. Users can now rely on history revert actions to preserve the intended content layout, reducing editing confusion and accidental formatting errors.
Original PR description
Problem: Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`). Cause: In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the…
Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).
Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.
Example (processed in reverse order):
```js
[
{ type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
{ type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
node: { textValue: 'b' } },
{ type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
{ type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
{ type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.
Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.
Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.
opw-5139795
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233582Calendar events now use the correct known contact when adding details to event descriptions instead of guessing from the attendee list. This prevents incorrect contact information from appearing and makes related appointment and calendar behavior more predictable.
Original PR description
When a calendar event is created, the system automatically adds contact details to the description. It currently "guesses" this contact by picking the first attendee who isn't the organizer. This guessing logic can be wrong, especially for events created by other apps (like Appointments) where a specific contact (e.g., the booker) is known. This not only shows the wrong information to the user but also causes instability in automated tests, which can fail unpredictably depending on the order of attendees. This commit refactors the event creation logic to be more flexible. It allows other modules to specify *which* partner should be used as the main contact, rather than leaving it to a guess. This makes the feature more robust and stabilizes the tests that rely on this behavior. Task-5207757
This change resolves an error that could appear when users group Analytic Accounts by any field. It prevents the page from crashing, making the list view usable again for finance teams.
Original PR description
When grouping by any field in Analytic Accounts, a traceback occurs. Steps to reproduce the error: - Install ``Accounting`` module - Go to Settings > Enable ``Analytic Accounting`` > Save - Go to…
When grouping by any field in Analytic Accounts, a traceback occurs. Steps to reproduce the error: - Install ``Accounting`` module - Go to Settings > Enable ``Analytic Accounting`` > Save - Go to Accounting > Configurations > Analytic Accounts > Group by any field Traceback: ```py ValueError: Cannot convert account.analytic.account.debit to SQL because it is not stored ``` https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/addons/analytic/models/analytic_account.py#L128-L133 When the user applies Group By, the ``_read_group_select`` method is called with ``debit:sum_currency`` as the ``aggregate_spec``. This method then calls the super ``_read_group_select`` method, and the super method calls the ``_field_to_sql`` method from [1]. which uses ``field.to_sql()`` to build an SQL object for the ``debit`` field at [2]. Since the ``debit`` field is a non-stored computed field, the ``to_sql()`` method raises the above ValueError at [3]. [1]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/odoo/orm/models.py#L2002 [2]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/odoo/orm/models.py#L2930 [3]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/odoo/orm/fields.py#L1211 sentry-6921656195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when a manufacturing order is split into backorders, the linked delivery keeps the correct total quantity. Previously, only the first production updated the delivery display, which could make the delivered quantity appear incomplete until all parts were finished. This improves accuracy for sales and delivery follow-up.
Original PR description
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to…
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to reproduce ----- - Unarchive MTO route - Create a stored product - Routes MTO & Manufacturing - Empty BoM - Create a Sale Order for 3 units of the product & confirm it - Go to the linked MO and split it in 2 (quants of 1 and 2) - Confirm both MOs (and produce) - Go to the sale's delivery > The delivery's move only shows 1 unit of the product Why the move quantity is only 1 ----- After confirming the first of the 2 backorder productions, when we manufacture the product, we go through https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054 Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 Which creates a SML for the delivery move when reserving it https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858 https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971 This in turn triggers the computation of the move's quantity since it depends on the move's lines https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383 Our move ends up with a quantity of 1. When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 This means we don't create a new SML for the delivery move, so the quantity stays at 1. Why there is no move_dest_id ----- When splitting the production, we go through https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829 We create new a MO and SM for the backorder. The SM is created here https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915 When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656 So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78 In the write, we get to a line where we access the production's state https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931 This triggers a recompute of the field. https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552 In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800 The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f). https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167 ----- Ticket: opw-4865082 Forward-Port-Of: odoo/odoo#233114 Forward-Port-Of: odoo/odoo#223792
This update fixes an issue where certain leave requests could show the wrong duration, including negative values, when sandwich leave rules were applied. It now handles weekends, public holidays, and linked leave requests more consistently so leave balances and approvals stay accurate.
Original PR description
Before this PR, if you created a leave of a type that had sandwich leave enabled on a non-working day, it would show a negative duration. This PR fixes some issues related to sandwich leave cases…
Before this PR, if you created a leave of a type that had sandwich leave enabled on a non-working day, it would show a negative duration. This PR fixes some issues related to sandwich leave cases (where Saturday and Sunday are considered non-working days): - Friday - Monday across weekend - counted (4 days). - Hour-based leave types: weekend bridging increases hours accordingly - Public holiday in the middle (Tue-Thu with Wed PH) - counted (3 days). - Stop/Start exactly on a public holiday(Tue-Wed(Public holiday), or Wed(Public holiday)-Thu) - trimmed to 1 day. - Public holiday only - 0 days. - Two single-day leaves around a Public holiday - When the second leave is created, it bridges via a public holiday (2 days), - The first one remains 1 day if it stands alone - Mixed leave types: - If the linked leave type doesn’t have sandwich enabled, no sandwich rules. - If both leave enable sandwich (with different types) - sandwich rule applies - Refusing/canceling a linked leave must immediately adjust the other side’s duration (e.g., Monday refused - Friday drops from 3 - 1 day) Task-4430044 Co-authored-by: @mepe-odoo Forward-Port-Of: odoo/odoo#233717 Forward-Port-Of: odoo/odoo#193186
This update removes customers linked to non-trade receivable accounts from the Point of Sale customer list, so cashiers only see suitable customers when selecting one at checkout. It also adds two new VAT accounts to the Belgian chart of accounts for the Collection Center partner, improving local accounting setup.
Original PR description
This PR removes the partners with non-trade receivable accounts from the POS customer's list. Additionally, 2 new VAT accounts were added in BE COA to be added on "Collection Center" partner. task-5148985 Current behavior before PR: - Partners with non-trade receivable accounts were visible in POS customer list Desired behavior after PR is merged: - Partners with non-trade receivable accounts were not visible in POS customer list - 2 new accounts added to BE CoA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix brings back the tax detail breakdown in the journal audit report, including the + and - columns that were removed by mistake. It helps users review tax grids accurately and keeps the report consistent with expected accounting details.
Original PR description
During the removal of tax tag signs, the detail of the tax grids has been removed and both columns `+` and `-` have been removed by mistake.
This update brings the spreadsheet component up to its latest version, including a fix for text handling in editable content areas. It helps keep spreadsheet editing more reliable and aligned with the newest upstream improvements.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/10359f499 [REL] 19.0.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ab1bc9362 [FIX] composer: fix get/setText of the content editable helper [Task: 5082601](https://www.odoo.com/odoo/2328/tasks/5082601) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update makes Belgian VAT-related partner accounts use the correct receivable and payable accounts, so VAT payments and closing entries are recorded more reliably. It also adds a new reconciliation rule that matches the partner and payment reference to automatically create the offsetting entry, reducing manual work and improving bank matching.
Original PR description
This commit sets AR and AP accounts of "FPS" and "Collection Center" partners with the 2 new added VAT accounts. Additionally, a new reconciliation rules that detects the partner and the communication and creates a counter entry. The partner "FPS" have been added to the VAT closing line for auto-reconciliation with bank transaction. task-5148985
This fix makes ZATCA invoice checks run even when a company does not have a country set. It helps prevent invalid invoices from causing errors that could stop the EDI service from processing documents reliably.
Original PR description
ZATCA invoice misconfigurations are only checked for if the company has Saudi Arabia set as its country. However, ZATCA EDIs can be generated without Saudi Arabia set as the country. Thus, companies without a company set can create EDI documents for misconfigured invoices. This may cause traceback errors which prevent the "EDI : Perform web services operations" cron from running at all. This commit ensures that configuration checks are run on companies without countries set (and adds a relevant unit test). opw-5057792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233333 Forward-Port-Of: odoo/odoo#231255
This change prevents a crash that could happen when Odoo recalculates task dependency warnings. It ensures the warning is checked safely for each task, so updating a deadline no longer breaks dependent tasks when several are linked to the same blocker.
Original PR description
Currently, an error occurs when computing the dependency warning for tasks. **Error:** ```Expected singleton: project.task(8, 7).``` After [this commit] if task1 depends on task2, if task1's task…
Currently, an error occurs when computing the dependency warning for tasks.
**Error:**
```Expected singleton: project.task(8, 7).```
After [this commit] if task1 depends on task2, if task1's task dependency is False, then the dependency warning for task1 should also be False.
However, when task dependency is enabled and two or more tasks are blocked by a single task, changing the Deadline of the blocking task triggers the computation of the dependency warning for those dependent tasks. During this process, the system attempts to check the task dependency across multiple records, which raises the error at [1].
This commit ensures that, since self may contain multiple tasks, the dependency warning is computed safely for each specific task.
[this commit]: https://github.com/odoo/enterprise/commit/50768627accb9d9767514fda7c6975bf4d8227d3#diff-b4bb763881453b0d69cae371c4c5034f6e199dfaf3a3056aba3381cf64dbf3dc
[1]- https://github.com/odoo/enterprise/blob/769201e22618b6683863f0839d7ad80bea0927cf/project_enterprise/models/project_task.py#L350
sentry-6914184933This change removes an Enterprise-only setting from the Gelato integration, so Community users can install and configure it directly from the settings screen. It prevents an unnecessary upgrade prompt and makes the setup experience smoother for more customers.
Original PR description
Remove the 'Enterprise' widget from Gelato setting, which prevented community users from installing Gelato module from settings without upgrading to enterprise. Forward-Port-Of: odoo/odoo#230776
This change updates how company logos are fetched for partner autocomplete, moving the lookup from the browser to Odoo’s enrichment service. It replaces the previous provider with a new one and ensures logos are retrieved more reliably when enriching company data, rather than during search selection.
Original PR description
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234053 Forward-Port-Of: odoo/odoo#231397