Monday, November 24, 2025
35 changes · 18.0
Enhancements to existing features
This change speeds up how product details are loaded during sales product configuration by fetching related data in batches instead of one by one. It reduces waiting time significantly, especially when products have many attributes and values, making the experience smoother for users.
Original PR description
Performing read operations on attributes and values in batch yields a significant performance improvement and is standard practice. Tested with 60 attributes and 8000 values: went from 2.7s to 0.8s (-70%) No task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Importing journal items will now accept lines linked to inactive accounts instead of failing with an unnecessary error. This makes data imports smoother when historical or temporarily disabled accounts are still referenced in the source file.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update changes how Odoo sends messages to IoT Boxes so each device gets its own message instead of a combined one. It helps ensure delivery and reporting features continue to work reliably with stable IoT Box versions.
Original PR description
In order to ensure ws compatibility with stable IoT Boxes versions, we now split websocket messages to send one per IoT identifier, instead of one targeting multiple ones. related: odoo/odoo#234175 Forward-Port-Of: odoo/enterprise#100127
This change lets users import journal items that reference inactive accounts without the import failing. It prevents unnecessary errors and makes data imports more reliable when older or archived accounts are involved.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now uses the newer invoice generation logic by default for more BIS3-based electronic invoice formats. This reduces the risk of inconsistencies across country-specific formats and helps keep maintenance simpler and more reliable.
Original PR description
Since commit 52e984037 we have enabled the new helpers by default for generating BIS3 UBLs. But we didn't enable them in the UBL formats that depend on BIS3 (NLCIUS, XRechnung, Chorus Pro etc). That was to first fix any issues in BIS3 in case the new helpers had broken something. Since the new helpers seem to be working fine for BIS3, we are now making them the default for all the formats that depend on BIS3 as well. We also add comments in the old helper methods to indicate that they are no longer used by default for BIS3 and its extensions. task-none
Resolved issues and error corrections
This change ensures related number fields use the same database type as their source field when they have decimal precision settings. It prevents unnecessary recalculations during upgrades and avoids mismatches that could affect data storage and performance.
Original PR description
**Steps to Reproduce:** 1. create test ``Float`` field in model ``A`` with ``digits`` args 2. create ``Many2One`` field with comodel ``A`` and then create Float Field in ``B Model`` with related…
**Steps to Reproduce:** 1. create test ``Float`` field in model ``A`` with ``digits`` args 2. create ``Many2One`` field with comodel ``A`` and then create Float Field in ``B Model`` with related ``A`` model test and store True **Issue:** 1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric`` **Second issue comes From odoo 18.3**:= during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. Due to ``_auto_init`` it will recompute this related field because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true from ``update_db`` and same reason as above it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to memory of unecessary compute which shouldn't do in first place. **FIX:** Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add. before fix:- ``` SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id'; column_name | data_type --------------+------------------ test_line_id | double precision (1 row) ``` After fix:- ``` SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id'; column_name | data_type --------------+----------- test_line_id | numeric (1 row) ``` opw-5222760 upg-3253635 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a manufacturing order quantity is increased in 3-step production, component replenishment now updates correctly for the pre-production to production flow. This ensures the system requests the right amount of stock, avoiding shortages or stale transfer quantities.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871
This fix ensures that when a delivery is made from a lot with a zero cost, the system keeps that lot’s zero value instead of incorrectly falling back to an average product cost. This prevents stock valuation from showing the wrong amount and keeps inventory accounting accurate.
Original PR description
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in…
**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.
**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button
**Current behavior:**
the value of the stock valuation layer is -5
**Expected behavior:**
it should be 0
**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277
**fix:**
deleting the lot.standard_price condition
is not possible because when the lot is created
at delivery it has no standard_price and in this
case we want to use the standard_price of the
product.
(see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)
opw-5077671This change fixes an issue where clicking the Pack button in purchase catalogs could sometimes appear to do nothing. The quantity is now calculated more reliably so packaging can be added correctly even when decimal values are involved.
Original PR description
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a…
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a product - Set a vendor "Mom" - Add a packaging of some decimal number, eg 22.68 - Create a new purchase from "Mom" - Open the catalog - Click the product once - Click the "pack" button 4 times (# of clicks required depends on the pack amount) > The last click did not increase the product quantity Cause ----- Javascript floats are sometimes an approximation of the value rather than the value itself. This means that when we do https://github.com/odoo/odoo/blob/0611a74cb52ca639b683ef158f8b4f2f347d08ad/addons/purchase/static/src/product_catalog/kanban_record.js#L33-L34 the flooring might sometimes get a close approximation and end up flooring down the packaging quantity. In our example, `this.productCatalogData.quantity` should be `68.04` but is actually `68.03999999999999`. This leads to `this.productCatalogData.quantity / packaging.qty` == `2.9999999999999996` `Math.floor` then rounds it down to 2 so we end up with 2 + 1 = 3, which is the current packaging quantity so nothing changes. ----- Ticket: opw-5130865 Forward-Port-Of: odoo/odoo#235706
This update refreshes the spreadsheet component to its latest version and includes several bug fixes. It improves behavior in read-only sheets, helps editing mode switch correctly when selections change, and prevents side panel data from carrying over incorrectly when the underlying model changes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4ef5b75e [REL] 18.0.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4ef5b75e [REL] 18.0.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/725b0ccc3 [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/e3c5deac2 [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/f76210a1e [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484) 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 prevents an error in the restaurant tip screen when closing a tab after payment lines have been adjusted. If no payment line is currently selected, the system now safely uses the first available one so the flow continues without interruption.
Original PR description
Steps: --- - Enable Tips and "Add tip after payment" in restaurant. - Open a session and add any product(s). - Go to payment and add two card lines (first with full amount, second with 0). - Click on "Close Tab". Issue: --- - After redirecting to the Tip Screen, a traceback appears. Cause: --- - Clicking "Close Tab" clears all 0-amount payment lines. This can leave no selected payment line, but the Tip Screen still tries to access it. Fix: --- - Use the selected payment line if available, otherwise fallback to the first payment line. task-5095825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users sending invoices through Chorus Pro will now see a clear alert if the extra module is not installed. This helps avoid missing validation checks and reduces the risk of submitting documents with incomplete verification.
Original PR description
This commit will add an alert when the customer use Chorus pro but don't have the module installed, and so don't have all the additional checks <img width="982" height="242" alt="image" src="https://github.com/user-attachments/assets/fc35d4ee-9a8b-41b8-8ee3-cbc32b266379" /> task-5223874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Analytic entries now use the company currency when they are created, instead of relying on the currency of the journal item. This prevents small rounding differences from causing mismatched analytic amounts and improves accounting accuracy.
Original PR description
Analytic line values are determined by the balance of a journal item, not their amount_currency. https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/models/account_move_line.py#L3230-L3237 However, the journal item's currency is referenced when creating an analytic line. This can cause discrepancies when the journal item's currency has a different rounding factor (`rounding`). [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5171681) opw-5171681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234797
This change fixes an issue where pressing Backspace at the start of an empty quote could accidentally remove a Table of Contents block. Empty quotes are now handled more safely, helping users edit documents without losing nearby content by mistake.
Original PR description
### Steps to reproduce: - Create a new Project task. - Insert a Table of Contents (e.g., /tableofcontent). - Insert a quote below it (e.g., /blockquote). - Place the cursor at the start of the empty quote and press Backspace. - The Table of Contents is removed. ### Desired behavior after PR is merged: - Empty blockquote is converted into a base container when backspace is pressed. task-5246130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the link between Uruguayan electronic documents and their source records, so the system now keeps the document number in sync when invoices or stock transfers are processed. As a result, the PDF generated by the external service can be found and attached properly after the document is accepted.
Original PR description
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776
This update prevents an error that could occur when creating an annotation in the General Ledger while using Arabic. The date is now saved in a format the system can process reliably, so users can add annotations without interruption.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656
This update fixes two loyalty card issues: archived cards now appear properly in the inactive filter, and they can no longer be used to keep claiming rewards. It helps ensure that deactivated loyalty cards stay deactivated and reduces confusion for users managing promotions and rewards.
Original PR description
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a…
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2: In this bug, earned points on archived loyalty can be used to claim rewards. #### To reproduce: 1- Install `Sale` and `Ecommerce` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Add a rule to grant 10 points per order 5- Apply a reward in exchange of 10 points 6- Create a `Loyalty Card` for the admin with 0 points. 7- In Ecommerce, add a product to your cart 8- Remove the product from the cart 9- Archive the loyalty card created for the admin 10- In Ecommerce, add another product to cart 11- As you see, you still can use the loyalty card ### Cause: When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards. To prevent this, we can unlink points from draft sale order when the card is archived. opw-5166696
This change avoids a memory overload that could happen when users register payments for many invoices at once. It makes the payment process more efficient by only loading the data needed for the check, improving reliability for larger batches.
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
This change ensures that when a filter is enabled on a composite financial report, the same filter is also activated on its underlying sections. As a result, the filter now appears correctly in the user interface and behaves consistently with other report filters.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236893
Users can now add annotations to accounting report lines even when their language uses non-Latin numerals. This prevents an error when saving the message in the chatter, improving reliability for localized environments.
Original PR description
Currently, an error occurs when a user tries to add an annotation on a line in a localization that uses a non-Latin numbering system. **Steps to produce:** - Install accountant with demo data and language ar_001 - Open General Ledger report in accounting - Click Annotate on any line and type a message **Error:** `psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٢٠"` **Solution:** - Change the datetime object to use Latin numbers, as the system expects. *Backport of https://github.com/odoo/enterprise/pull/99270* opw-5250261
This fix prevents outstanding accounts from being cleared when a journal’s currency is changed. It ensures the existing payment method settings remain intact, avoiding missing account information after currency updates or bank synchronization.
Original PR description
Changing the currency on a journal triggers the compute of inbound/outbound method lines, which clears the method lines before reasign the default method lines. This leads to the loss of any outstanding account set on the method lines. Steps: - Have a bank journal with outstanding accounts set on the payment method lines - Change the currency (in our case, this is the bank sync that changed the currency of the journal) -> Outstanding accounts are missing on the payment method lines, even if the accounts currency is the same as the journals or no currency is set on the accounts. opw-5175794
This update fixes a text selection problem inside table cells when users hold Shift and click. It makes selection behave like a normal browser, reducing frustration and preventing incorrect text highlighting while editing tables.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Property imports now handle fields that users cannot access because of access rules or group restrictions. This prevents import failures in those cases and makes the import process more reliable.
Original PR description
…ible https://github.com/odoo/odoo/pull/236037 ignores the properties field if we don't have access to the definition model at all. However, we should also check field groups to avoid crashing if the user cannot access the definition field because of group restrictions.
This change fixes an issue where unregistering a Nemhandel user could leave the account stuck and prevent it from being picked up again. It also avoids an error when someone tries to unregister manually, making the process more reliable for users.
Original PR description
If you unregister a Nemhandel user, it won't ever be picked up by the user db. And trying to unregister by hand will give a traceback. This is due to mismatch between Exception types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
We fixed an issue in Peru electronic invoicing where adding a partner reference could trigger validation errors from the tax operator. The system now sends the correct partner information for the local format, helping invoices process successfully.
Original PR description
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233
Fixed an issue where a filter enabled on a composite report could fail to appear in the interface if its underlying sections were not configured separately. This makes report behavior consistent and helps users see the expected options when working with grouped analytics reports.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100135
This update corrects Spanish Facturae exports so withholding amounts are always sent as positive values. As a result, invoices with withholding taxes are less likely to be rejected by FACE, improving submission reliability for users in Spain.
Original PR description
## Issue: The `TotalTaxesWithhold` field in the exported XML could be negative, causing FACE to reject the document. ## Cause: A previous change (https://github.com/odoo/odoo/pull/229236) added `values['tax_amount_currency']` to `TotalTaxesWithhold` without converting it to a positive value: https://github.com/odoo/odoo/blob/88b7ee6d9d2a7fe96512da0a7eaf8efcf9020ee1/addons/l10n_es_edi_facturae/models/account_move.py#L449 ## Steps to reproduce: - Install `l10n_es_edi_facturae` - With the ES company, create an invoice with a product and a withholding tax (e.g., 15% WHI) - Confirm the invoice and Send (Facturae) - Open the XML attached in the chatter - Observe that `TotalTaxesWithhold` is negative opw-5220205
This fix ensures prices stay accurate when a sales order is settled in Point of Sale using products with units that cannot be grouped together. It prevents incorrect totals caused by a mismatch between the quantity and the unit price during the conversion process.
Original PR description
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If…
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If the UoM in the first step was Kg for intsance, use Gram (g) here. 3. Confirm the order, and settle it in PoS. Notice that the price of that order in PoS is not correct. Why it's happening ------------------ When settling the PoS order, we first convert the sale_order's line UoM (g) to the original product UoM (kg), and we update the quantity accordingly (in this example by dividing by 1000). https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96 So this step updates both the qty and the unit_price. https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161 However, when the UoM is not groupable, we split the lines by taking into consideration the updated qty, but we still use the old price_unit, which creates an inconsitency and wrong calculations. The fix ------- When splitting the lines, we're just supposed to change the qty per line to max 1, but we're not supposed to change the price per unit for this qty. We now use the updated `price_unit` to have a correct math. opw-5232571
Image resizing is now turned off in Studio when editing reports. This prevents users from making changes that would look correct in the editor but not in the final PDF, avoiding confusion and incorrect report output.
Original PR description
Problem: When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`). Solution: Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs. Steps to reproduce: 1. Open Studio → Reports → open any report. 2. Add an image. 3. Resize it to 25%. 4. Save and print the PDF. 5. The image appears at its original size in the PDF. opw-5233052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Public Knowledge articles shared on the website will now open properly for portal users, even when the site uses more than one language. This prevents users from being sent back to the home page and ensures the article remains accessible from the sidebar.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118
This fix stops rental returns from exceeding the quantity that was originally picked up. It helps keep rental records accurate and prevents mismatches in delivered and returned quantities.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100015
Image resizing is now disabled in Studio when editing reports. This prevents a mismatch where resized images looked correct in the editor but did not print properly in the PDF.
Original PR description
Problem: When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`). Solution: Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs. Steps to reproduce: 1. Open Studio → Reports → open any report. 2. Add an image. 3. Resize it to 25%. 4. Save and print the PDF. 5. The image appears at its original size in the PDF. opw-5233052
This change prevents the editor from creating leftover empty link elements when users change text formatting, such as font size, inside linked text. It helps keep the document structure clean and avoids display or editing issues that could build up after repeated formatting changes.
Original PR description
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty <a> tags are created before and after the formatted…
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty <a> tags are created before and after the formatted `<span><a></a></span>` with only FEFF Characters. - Change the font size again (e.g., back to 14). - Multiple empty <a> tags remain in the DOM. Description of the issue this PR addresses: - The empty <a> elements are created during `splitAroundUntil` because of FEFF characters inside links. The existing `removeFeffs` method only replaces FEFF with empty text nodes, so the issue persists and still results in empty anchors with just feffs. - This empty tags lead to the creation of more empty elements during formatting changes. Desired behavior after PR is merged: - Added a new utility method `removeEmptyTextNodes`, which removes empty text nodes and updates the cursor accordingly. This prevents empty anchor elements from being created when formatting links. task-5097770 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where pressing the TAB key while adding notes or sections to sale order lines would clear the input field instead of saving the data. The fix ensures that users can now correctly add and save their notes and sections within the sale order lines, improving data accuracy and usability.
Original PR description
## Versions 18.0 > saas-18.4 Fixed in 19.0 thanks to bc6592a8514d6557037868a0f42265070fa02263 introducing the `parseLabel` method: https://github.com/odoo-dev/odoo/blob/19e03df5d9546d3948c2a184a6f26db7ba3aec71/addons/account/static/src/components/product_label_section_and_note_field/product_label_section_and_note_field.js#L47-L51 ## Issue When adding a section or a note line in the sale order lines list view, pressing TAB key caused the line to be cleared and removed instead of being saved. ## Steps to reproduce - Open an invoice or create one for any customer: - Click either on "Add a section" or "Add a note"; - Write something down; - Press the TAB key. ## Fix Handle the field with the appropriate `useInputField` hook. opw-4967733
This update automatically registers products with eTIMS before invoice sending, resolving issues with incorrect product registration and view displays. It now uses the correct company context for accurate eTIMS product registration, particularly important in multi-company environments. This ensures proper eTIMS compliance for Ke invoices.
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671