Monday, November 24, 2025
43 changes · 19.0
New functionality added to Odoo
This change adds the Finnish EC Sales List report and its export file. It helps businesses operating in Finland produce the required cross-border sales reporting more easily and in the correct format.
Original PR description
The aim of this commit is adding the Finnish EC Sales List report. task-5126664 Forward-Port-Of: odoo/enterprise#99854 Forward-Port-Of: odoo/enterprise#95901
Enhancements to existing features
This update corrects how values are calculated in the Coretax e-Faktur XML so they are based on tax group rules instead of invoice type in certain cases. It also adds a safeguard to prevent invalid tax combinations when downloading the XML, helping avoid incorrect reports and making the setup more reliable.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267) Forward-Port-Of: odoo/odoo#236821 Forward-Port-Of: odoo/odoo#233347
Resolved issues and error corrections
When a subscription delivery is returned, the delivered quantity on the related sales line is now updated correctly. This keeps subscription invoicing and delivery tracking accurate after returns, avoiding overcounting shipped items.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
When a mass email is also logged in the chatter, its attachments are now linked directly to the related record. This makes them easier for users to find later in the record’s attachments list, improving day-to-day visibility and follow-up.
Original PR description
In [1] the argument to link attachments to messages was that it would automatically clean up the attachments when the message is deleted (typically right after sending). As it originally was kept forever, as we wanted to guarantee that it still exists by the time the email is sent. However in modern ODOO mass emails can, and often are, logged in the chatter. In that case it is relevant to link the attachments to the record directly so that users can see the attachments in the attachments menu of the chatter. [1]: https://github.com/odoo/odoo/commit/cf214ed7244207f1fd5d377ab69d85a6441ff665 task-4829625
The customer portal now reads subscription billing periods dynamically instead of relying on a fixed list. This prevents errors for subscriptions that use custom periods, such as daily billing, and makes future customizations work without extra code changes.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
This change adds triangular tax handling to Finnish tax reports so they can be used correctly in the EC Sales List report. It improves the accuracy of VAT-related reporting for businesses operating in Finland and across EU sales scenarios.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-5126664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236427 Forward-Port-Of: odoo/odoo#229269
This change improves how GSTR-2B processing handles certain return-period errors and prevents background jobs from retrying records that are already in an invalid error state. As a result, the system avoids unnecessary processing and reduces noise from known issues.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
We updated how the signature block is registered so it can be used reliably in the Email Builder and Mass Mailing tools. This fixes an issue where the signature option could stop appearing after recent editor changes, helping users keep their content consistent across templates.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **community: https://github.com/odoo/odoo/pull/190616** task-4224624
This update makes Spanish POS receipts use a consistent, consecutive number when they are not turned into invoices. It helps avoid gaps or resets in the displayed ticket number, so the receipt numbering better matches official requirements and is more reliable across devices.
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
This update adds a Reprocess action so AI source indexes can be refreshed when linked web pages, documents, or knowledge articles change. It also avoids duplicate processing of the same content, which helps keep results accurate while reducing unnecessary system work.
Original PR description
## Summary - Add 'Reprocess' button to enable recomputation of source indexes when URL content, document's documents, or knowledge articles are updated. - When triggered, the system checks for content changes and updates the index for all sources sharing the same attachment across agents. Prevents redundant reprocessing by tracking already processed attachment checksums within each batch operation. task-id-5153627
This change makes sure split payments in Point of Sale are recorded against the same customer record as the related order, even when the sale is made under a child contact. It prevents mismatches in accounting and helps keep customer statements balanced and accurate.
Original PR description
### Description Before this commit, when split payment was enabled for a payment method and a PoS order was assigned to a child contact, the accounting move for the payment was linked to the child contact, while the order move lines were linked to the parent contact. This inconsistency resulted in unbalanced customer statements. This commit ensures that the payment move is assigned to the same accounting partner as the order lines. ### How to reproduce: * Create a child contact (res.partner). * Activate "Identify Customer" (split payment) for a payment method. * Open the session. * Create an order assigning the child contact and pay using this method * Close the session. * Accounting payment for this session will be assigned to child partner opw-5121710 Forward-Port-Of: odoo/odoo#237028 Forward-Port-Of: odoo/odoo#235951
This fix ensures delivery slips show the right ordered quantity when an order is partially delivered and a backorder is created, especially for make-to-order items. Previously, the slip could incorrectly show the remaining quantity as if it were the original order quantity, which was confusing for operations and customers.
Original PR description
Steps: - Create an MTO product. - Create an SO for 10 units and confirm. - Deliver 5 on the first picking, validate, and create the backorder. - Print the delivery slip of the first (done) picking.…
Steps:
- Create an MTO product.
- Create an SO for 10 units and confirm.
- Deliver 5 on the first picking, validate, and create the backorder.
- Print the delivery slip of the first (done) picking.
Before:
- MTO: Ordered = 5, Delivered = 5, Remaining = 5.
- Normal product: Ordered = 10, Delivered = 5, Remaining = 5.
Cause:
- _get_aggregated_properties builds a display key including the description:
line_key = f"{product.id}_{product.display_name}_{description}_{uom.id}_{move.product_packaging_id}".
- In MTO, backorder delivery moves are regenerated and sale_stock recomputes description_picking from the SO line, so backorders no longer share the same line_key and previous quantities are not merged.
Fix:
- Introduce _get_group_key_from_move to group sale moves by sale_line_id (fallback: product + UoM).
- For each picking, compute Ordered as the SO line quantity (in report UoM) minus quantities delivered on preceding pickings for that group.
- Keep the original line_key-based behavior for non sale-related moves and for empty moves.
opw-5112467The Swiss Federal Tax Administration exchange rates are now saved with the correct date. This prevents rates from appearing one day off when users refresh currency rates.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
The Belgian VAT return now includes the client nihil option again, which had been lost after a system change. This makes the export more accurate by only enabling the option when it is truly applicable, based on whether any customer exceeded the yearly invoicing threshold of 250€.
Original PR description
Since the new return system, the client nihil option that was inside the vat export xml was removed. We used a too simple mechanism which only checks if the tax report was empty or not. This was completely wrong, now we added the checkbox back for finer tuning and we precomputed it. The precompute is checking if any partner is exceeding 250€ invoiced for the current year. This commit adds a new module l10n_be_report_client_nihil which will be removed in master. It will be integrated with l10n_be_reports directly. task-5217079
This update prevents the website theme editor from crashing when a Google font is available only in one weight, such as 700. It ensures the editor requests the correct font variant so users can reopen and adjust their theme normally after saving.
Original PR description
Steps to reproduce: =================== 1. Edit the website theme and set an external font, e.g., UnifrakturCook. 2. Save, exit, then reopen the editor and go to the Theme tab. → Traceback occurs. Cause: ====== Some Google Fonts (e.g., UnifrakturCook) only provide a single weight (700). When fetching the font, html_builder does not request a specific weight, so Google Fonts attempts to return the default set, including 300. Since that weight does not exist for these fonts, Google Fonts responds with an error, leading to the traceback. This issue is same to the one fixed here: https://github.com/odoo/odoo/commit/f843c591c0377e0dab1a1f0cfaca36c1981c8880 but the fix was not ported during refactoring. opw-5259891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236556
This fix ensures that when a route is chosen directly on a sales order line, Odoo keeps that choice instead of falling back to the product’s default route. This prevents the wrong supply process from being triggered, so orders now follow the intended buying or manufacturing flow.
Original PR description
**Issue** A route explicitly set on a sale order line is ignored: the system falls back to product-level routes. **Steps to reproduce** 1. Activate multi-route. 2. Unarchive the MTO route. 3. Create…
**Issue** A route explicitly set on a sale order line is ignored: the system falls back to product-level routes. **Steps to reproduce** 1. Activate multi-route. 2. Unarchive the MTO route. 3. Create a product. 4. Enable MTO + Manufacture on the product. 5. Create a sale order using this product. 6. Set the Buy route on the SO line. 7. Confirm the order. → A Manufacturing Order is created instead of a PO. **Cause** This regression originates from the changes introduced in https://github.com/odoo-dev/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a, where `propagate_warehouse_id` was removed and associated info began to be propagated through stock moves instead. In 19.0, the route of the rule started being injected into the move: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_rule.py#L367 To avoid infinite loops (e.g., WH1 resupplying WH2 and vice-versa), `_prepare_procurement_values` then filters out these injected routes: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_move.py#L1674-L1683 Unfortunately, whenever the `location_id` has a warehouse, the filtering applies to all `route_ids`, including those explicitly set by the user (e.g., on a sale order line) As soon as `route_ids` is cleared, `_get_rule` stops considering SO-line routes (first priority): https://github.com/odoo/odoo/blob/dab7c5821e627bc7120660778a288cb521a223d3/addons/stock/models/stock_rule.py#L599C13-L600C89 and falls back to product routes: https://github.com/odoo/odoo/blob/dab7c5821e627bc7120660778a288cb521a223d3/addons/stock/models/stock_rule.py#L604 **Solution** Revert the workaround that injected the rule's `route_id` into the move (added because `propagate_warehouse_id` no longer existed), and instead propagate the warehouse information directly in the inter-company case. Concretely: - Stop injecting the rule's `route_id` into the move: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_rule.py#L367 - Always keep the user's `route_ids` intact, no more filtering. - Explicitly propagate the warehouse coming from the rule in the inter-company case, restoring the intent of `propagate_warehouse_id`: https://github.com/odoo/odoo/blob/a7b504a3f5845feff8b676cc02ecf2d7b3489b7f/addons/stock/models/stock_move.py#L1655-L1656 This preserves manually-set routes (such as on SO lines) while still ensuring inter-company transfers work reliably. opw-5170290
The Spain localization balance sheet reports now open the Accounts Coverage Report without errors. The underlying report data was corrected and loaded in the right order so the report can display properly for users.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745This update stops users from accidentally changing protected values when dragging items in Gantt views. It makes rows grouped by read-only fields behave as non-editable, so planning data stays consistent and unintended changes are avoided.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#100088 Forward-Port-Of: odoo/enterprise#94166
This fix ensures that date placeholders in signed documents only appear for the intended signer. It prevents one signer from seeing placeholder information meant for another, which helps avoid confusion during the signing process.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Add date fields for multiple signers. - When the first signer signs, the date placeholder for the next signer becomes visible to the first signer. Issue: - Date fields for next signers were showing placeholders to the current signer. Fix: - Added a condition to only set the placeholder when it has a valid value. Impact: - Ensures date placeholders are visible only to the correct signer. task-5218970 Forward-Port-Of: odoo/enterprise#98256
This fix blocks saving a partner with a fiscal position that belongs to a different company. It helps avoid creating inconsistent customer/vendor records that would later fail when used on invoices.
Original PR description
It was possible to create a partner with a fiscal position from another company. Using this partner in an invoice would then raise the error like expected, but there is no reason to allow that configuration in the first place. opw-5127901
This change prevents a crash that could happen when users press backspace while editing the people assigned to a task in kanban views. It improves reliability during a common editing action and avoids an unexpected error screen.
Original PR description
How to reproduce: - Go to project tasks - Edit the list of people assigned to a task - Press backspace Current behavior: Traceback Expected behavior: No traceback task-5189783 Forward-Port-Of: odoo/odoo#235997 Forward-Port-Of: odoo/odoo#235489
This fix corrects planned hours in Timesheets / Planning analysis reports so shifts are only counted when they overlap with an employee’s working hours. This prevents hours from being incorrectly attributed to the wrong month when a shift ends outside business hours.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This update brings the spreadsheet component to a newer version with several bug fixes and small usability improvements. It addresses issues like scrolling on iOS, read-only behavior, formula handling, border display, and pivot/table limits, helping users work more reliably across devices and spreadsheet scenarios.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f5bdbccc9 [REL] 19.0.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f5bdbccc9 [REL] 19.0.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6b7c8085a [FIX] Spreadsheet: fix scroll on ios [Task: 5270869](https://www.odoo.com/odoo/2328/tasks/5270869) https://github.com/odoo/o-spreadsheet/commit/1a9de79be [FIX] borders: preserve side borders when combining External and All [Task: 5270171](https://www.odoo.com/odoo/2328/tasks/5270171) https://github.com/odoo/o-spreadsheet/commit/42fa2e10a [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/dd6124730 [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888) https://github.com/odoo/o-spreadsheet/commit/c23e4925d [FIX] functions: ignore vectorized SUBTOTAL [Task: 5261987](https://www.odoo.com/odoo/2328/tasks/5261987) https://github.com/odoo/o-spreadsheet/commit/7edc3b50b [FIX] release: make lastest [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/d59fcbf0d [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) https://github.com/odoo/o-spreadsheet/commit/2b5cd53d1 [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484) https://github.com/odoo/o-spreadsheet/commit/7ae8c7666 [FIX] composer: Enter/Tab confirm when assistant is force-closed [Task: 5153666](https://www.odoo.com/odoo/2328/tasks/5153666) https://github.com/odoo/o-spreadsheet/commit/eccc2e02f [FIX] reference_type: add single quotes for sheet names with spaces [Task: 5244798](https://www.odoo.com/odoo/2328/tasks/5244798) https://github.com/odoo/o-spreadsheet/commit/b95dcae83 [FIX] pivot: raise pivot size limit [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects how the Italian "Libro Giornale" report custom template is applied so it only affects the intended report and company context. As a result, regular journal reports keep showing journal names correctly even when the Italian localization is installed.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
This update prevents an error when opening the translation tool on invoice terms and conditions. It ensures translatable text fields load correctly, so users can translate invoice content without seeing a traceback.
Original PR description
With l10n_gcc_invoice, the narration field on invoice (the Terms & Condition part) becomes translatable. However, when opening the translation widget, a traceback happens as the "fields" (the text-to-fill part) to load don't have a specified name. opw-5269869
GCC invoices now display product line names in both English and Arabic again when both translations are available. This restores the expected bilingual presentation on printed invoices, helping customers read documents in the language they prefer.
Original PR description
### Issue: In GCC invoices the product names are not in both languages. ### Steps to reproduce: - Install "l10n_sa" and switch to a Saudi company - Have a product with its name translated in both…
### Issue: In GCC invoices the product names are not in both languages. ### Steps to reproduce: - Install "l10n_sa" and switch to a Saudi company - Have a product with its name translated in both English and Arabic - Create an invoice with this product, print it - The product name is only displayed in the language of the partner ### Cause: [This refactor](https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7) removed the [part of the code responsible for displaying the product in both languages](https://github.com/odoo/odoo/blob/f9090fff6b3564c0d7ce2363a283b81ea10b3906/addons/l10n_gcc_invoice/views/report_invoice.xml#L286-L293). Now only `line.name` is displayed. ### Solution: We use the same XML architecture as in 18.0. As `line.name` is composed of several fields combined we need to check if the English and/or Arabic name is in `line.name` to display it or not. We use a replace in the xpath to add `dir="rtl"` on `line.name`. This ensure that when the partner lang is Arabic then `line.name` is displayed right to left. ### Note: `line.name` can contain other field like `description_sale` or `description_purchase` that will still be displayed in only one language. opw-5219783
This update restores the expected payment rule for standard ISO 20022 payments, ensuring the correct service level is used by default. It helps avoid payment rejection or processing issues when sending payments outside the SEPA zone or in non-EUR currencies.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
This fixes an issue where editing or deleting one line in a bank statement could unintentionally change the partner on other lines. The update keeps previously edited lines stable while still recalculating partner information when using the reconcile action, improving consistency for accounting users.
Original PR description
Before this commit, when having multiple lines in a statement line. By default, all the lines have a partner since we compute the partner depending of other lines. But in the case of an edit or a delete we don't want to recompute. What was happening is that the partner keep getting recomputed on the other lines even the one that was previously edited. This commit will add a context key when using the reconcile button to recompute the partners. opw-5179670 Forward-Port-Of: odoo/enterprise#99999
This update fixes a styling issue that could break page assets when the text editor app was not installed. It ensures the color picker keeps working and the interface remains usable in databases without that optional component.
Original PR description
Some scss variables used in color_picker.scss were defined in html_editor, thus breaking assets if html_editor was not installed. Steps to reproduce: - Create a new database - Uninstall html_editor - Scss assets are broken task-5230908 Issue: https://github.com/odoo/odoo/issues/234507
This update corrects how planning weeks are compared when schedules span multiple years. It prevents incorrect calculations in forecasted planning and helps ensure allocated hours are computed accurately.
Original PR description
Steps to reproduce: 1- install project_forecast 2- run test_creating_a_planning_shift_with_flexible_hours_allocated_hours_are_correct => test fail Source: When slots span across multiple years (e.g., 2019 → 2026), https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/resource/models/resource_resource.py#L338 this comparison becomes invalid, it compares week numbers only, ignoring the year. For instance, week 23 of 2019 is considered after week 18 of 2026. Fix: compare year and week
This change prevents the system from sending duplicate and growing numbers of network requests when a POS scale updates its weight over longpolling. It keeps the scale working reliably by ensuring only one request is active per event, which avoids request failures after repeated use.
Original PR description
Steps to reproduce: 1. Setup a scale in a POS. 2. Disable the WebRTC connection so that longpolling is used. 3. Try to weigh with the scale in the POS. Expected behaviour: - There is one HTTP call per weight event, and the scale continues to work no matter how many times the weight changes. Actual behaviour: - The amount of HTTP calls doubles every time the weight changes. Before long, a limit is reached and the requests start to fail. This behaviour was due to the `addListener` method being called again inside the listener callback, calling the poll method. The original poll call would also start to poll again, leading to two polling requests. The fix is to check in the poll method that listening has not restarted during the handling of the callback. If so, we don't try to poll again. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue that could cause the system to run out of memory when registering payments for multiple invoices at once. It improves reliability for large payment batches and helps avoid interruptions during accounting operations.
Original PR description
### Description: When trying to register a payment for multiple invoices, it is possible to trigger an Out Of Memory error. This is caused by the constraint `_validate_taxes_country`, calling the compute `_compute_tax_country_id` on all of the moves. To avoid that, we just retrieve the field we need rather than fetching everything. ### Reference: opw-5152687 Forward-Port-Of: odoo/odoo#235749
The Signature option has been moved to a shared category so it can be used consistently across editors. This fixes an issue where Mass Mailing could no longer access the Signature plugin, improving reliability for email creation.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **enterprise: https://github.com/odoo/enterprise/pull/75612** task-4224624
This fix stops the Bahrain tax reports from generating two identical closing entries when users submit either the full or simplified return. It matters because it prevents duplicate accounting records and reduces the risk of confusion or manual cleanup.
Original PR description
The full and simplified reports will generate 2 identical closing entries. A better solution to choose which return to use will be done in the task 5232715 task-5123564
This fix prevents an error that could happen when users try to create a contract before the employee record has been saved. The New Contract button is now only shown once the employee exists, avoiding a failed action and improving the hiring flow.
Original PR description
Currently, an error occurs when the user clicks the New Contract button. Steps to Reproduce ([Video](https://drive.google.com/file/d/11xSVGvMLJSvEfnHjixquP94wH29eVqMT/view)): - Install the `hr`…
Currently, an error occurs when the user clicks the New Contract button. Steps to Reproduce ([Video](https://drive.google.com/file/d/11xSVGvMLJSvEfnHjixquP94wH29eVqMT/view)): - Install the `hr` module. - Go to `Employees` > click `New` > do not fill in the employee name. - In the `Payroll` section, set the contract `start and end dates`. - Click `New Contract` and select a date outside that date range. `IndexError: tuple index out of range` This error occurs because the user clicks the New Contract button before the employee record is created. Since the employee is not created, the employee ID is False. Then it attempts to create a contract with this False ID [1]. When the system tries to find the employee’s version using this False ID, no version is found, raise the error [2]. This commit ensures that the Add Contract button is visible after the employee record is created. [1]- https://github.com/odoo/odoo/blob/bf0e135d55136dd6f263d281a09b7f4d08d7fc5b/addons/hr/static/src/components/button_new_contract/button_new_contract.js#L45-L48 [2]- https://github.com/odoo/odoo/blob/bf0e135d55136dd6f263d281a09b7f4d08d7fc5b/addons/hr/models/hr_employee.py#L554 sentry-7033637685 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When editing a website, Discuss chat bubbles no longer sit on top of the page content and interfere with selecting snippets. This makes it easier to edit pages while still keeping conversations visible.
Original PR description
Before this commit, discuss bubbles would appear on top of the editor when editing a website. I was therefore be difficult to select some snippets, especially when the user had a lot of conversations at the same time and he wanted to keep the discuss bubbles visible. This commit shift the discuss bubbles on edit to solve the issue. task-4266898 Forward-Port-Of: odoo/odoo#184671
This fix ensures that the new "Other Expenses" account type is included in the Profit and Loss report. As a result, businesses using this account type will now see their expense totals reported correctly and completely.
Original PR description
In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Profit & Loss Report. Since l10n_be is the only CoA which uses this account type, the issue was not uncovered until OXP testing days. Forward-Port-Of: odoo/enterprise#94219
This fix ensures the traceability report shows the right component for each finished serial-numbered product when multiple units are made in one manufacturing order. It prevents components from appearing under every finished product, which could otherwise give a misleading view of what was actually consumed.
Original PR description
Steps to reproduce: ------------------- 1. Create 1 product that is serialized, add a BoM that has one component 2. Create a manufacturing order for multiple units of the finished product, each…
Steps to reproduce: ------------------- 1. Create 1 product that is serialized, add a BoM that has one component 2. Create a manufacturing order for multiple units of the finished product, each consuming one component 3. Generate the serial numbers for the finished products, then validate the manufacturing order 4. Open the traceability report, every component is listed under every finished product, making it seem that every component was used to manufacture each unit Observation: ----------- The traceability use the consume_line_ids to know what element the move_line consumed : https://github.com/odoo/odoo/blob/10e5ac9943a68f03a31c149ff14ade1cf3937e3d/addons/mrp/models/stock_traceability.py#L32 the assigning of the consume_line_ids every finished moves form the order will have inside their consume moves, all the conmponent from all the finished_moves, which create this situation: https://github.com/odoo/odoo/blob/1e8d8b51b2b5b99f6fe9f01b8219441863111763/addons/mrp/models/mrp_production.py#L1852-L1853 This issue appeard on 19.0 since this commit allowed to manufacture several serial number with only one MO: https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e#diff-4ea85ad9b881e3fdcbc31b3674f4c79965fd643e79c1e746c934ad824e4eccceL98 before the issue was not present since all element had different mo orders. Why the fix: ------------ I think is too risky to create new moves lines for each product, it would impact other elements than just the traceability. Could also try to change the values directly inside the tracability files -> working in this. opw-5133629
Annual corporate tax returns now use the actual fiscal year dates when a company has a fiscal period longer than 12 months. This prevents the wrong yearly closing from appearing and ensures the return is scheduled for the correct year and deadline.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432 Forward-Port-Of: odoo/enterprise#100160 Forward-Port-Of: odoo/enterprise#100034
This fix restores automatic printing of receipts for restaurant self-orders paid online. It ensures the system uses the correct order data when preparing the receipt, so the print action works reliably again.
Original PR description
Steps to reproduce: ------------------- 1. For restaurant, enable self order, and set an online payment method 2. From self order, make an order. The receipt should be automatically printed in PoS. Observation -> The receipt is not printed. No warnings or anything. Reasons ------- `sendOrderInPreparation` is called with the online `order`, however, intelally, it was calling the getter `categoryCount` which uses the current active order in PoS which is `undefined`, and not the passed online `order`. Fix --- We introduce a method `getCategoryCount` which is identical to the getter `categoryCount` but it can be passed an `order` argument to compute for an order different than the default order `getOrder()`. Bug discovered while working on ticket 5190993. opw-5263885
This change corrects how Odoo reuses cached replenishment rules so each orderpoint gets the right rule. It prevents the system from showing or applying the wrong default route, such as Buy instead of Manufacture, when users review replenishment items.
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
This update corrects an imbalance in the French Balance Sheet reports caused by a recent update to the French Chart of Accounts. The fix ensures that all income and expense accounts are correctly reflected, particularly when generating reports for the 2024 accounting period, leading to more accurate financial reporting.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well. Forward-Port-Of: odoo/enterprise#100116 Forward-Port-Of: odoo/enterprise#100077
This update resolves an issue where creating invoices after deleting a line on a subscription order would trigger an error related to unit of measure mismatches. The fix ensures that the invoice creation process correctly handles deleted subscription lines by using the invoice line's unit of measure, preventing the error and improving invoice functionality. This improves the reliability of subscription invoicing.
Original PR description
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video:…
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view **Steps to Reproduce** 1. Create and confirm a subscription with a recurring product (e.g., Car Leasing) 2. Generate and post the invoice for the subscription 3. Add a new product line to the subscription (e.g., Office Cleaning Service) 4. Delete the original invoiced line (Car Leasing) 5. Attempt to create an invoice for the new product line → Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category." (https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view) **Root Cause** Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation. **Fix** Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation. Forward-Port-Of: odoo/enterprise#99497 Forward-Port-Of: odoo/enterprise#99231