Daily updates from Odoo
Tuesday, April 21, 2026
17 changes · 18.0
Resolved issues and error corrections
This fix prevents a manufacturing order from automatically reserving tracked components when the reservation method is set to Manual. It keeps the reservation behavior aligned with the user’s chosen process, avoiding unexpected stock allocation when work begins.
Original PR description
on a MO when we have a component tracked by lot and reservation methode set as manual, when we start an operation, the component is automatically reserved. **Steps to reproduce** * Set Manufacturing…
on a MO when we have a component tracked by lot and reservation methode set as manual, when we start an operation, the component is automatically reserved. **Steps to reproduce** * Set Manufacturing operation type reservation methode to "Manually" * Create a bom with a component tracked by "lot" * Add an operation to this bom * Create an MO with this bom and confirm it * Start the operation -> the component get reserved. **Observation** When starting the operation it will call button_start, where we will set the ```qty_producing```: https://github.com/odoo/odoo/blob/6aa9147eef3212b5a4ebf374e617caba198ad7b5/addons/mrp/models/mrp_workorder.py#L617-L618 When setting ```qty_producing```, we will write it and from the inverse, it will call ```_set_qty_producing``` to synchronizes the value of the linked mo. https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/models/mrp_workorder.py#L52-L53 https://github.com/odoo/odoo/blob/6aa9147eef3212b5a4ebf374e617caba198ad7b5/addons/mrp/models/mrp_workorder.py#L237-L238 In the ```_set_qty_producing``` in the mo, the system assumes that because production has started, the linked stock moves must be updated to reflect consumption: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/models/mrp_production.py#L1338-L1346 When these stock moves are updated, the stock.move logic prepares values by reserving available quants and generating new move lines: https://github.com/odoo/odoo/blob/67df9b5cf4bc277c17b49ef70782a76f5ca6d760/addons/stock/models/stock_move.py#L2328-L2331 https://github.com/odoo/odoo/blob/67df9b5cf4bc277c17b49ef70782a76f5ca6d760/addons/stock/models/stock_move.py#L2337 opw-5938176
This change lets Odoo start even when the configured addons path points to an empty repository with no modules yet. It removes a blocker for users and automation that create new Odoo projects from scratch, so they can begin work without hitting a startup error.
Original PR description
Initialize a new empty git repository where you are going to vide-code some new Odoo modules. Because the repository is empty (no addon yet) the CLI fails with an "option --addons-path: the path <path> is not a valid addons directory". This makes vide-coder sad, and bigrams want vide-coders to be happy, so drop the sanity-check and also accept empty addons. Forward-Port-Of: odoo/odoo#256913
This change fixes a flaky test in the web editor so it behaves more consistently across fast and slow test runs. It better matches how a real user clicks a link, reducing false failures in automated testing.
Original PR description
The popover opening is triggered through click, but there is a selectionchange handler on click that checks if the selection is outside of the link and, if it is, closes the popover. In this case, the click method didn't set the selection inside the link properly because of the presence of \ufeff around the link. The test actually passes by mistake when the runbot was fast, but failed when the runbot was slow, as the selectionchange handler had the time to execute and close the popover. This commit forces the selection to be inside the link after calling click, to be closer to what actually happens when a user click on a link, as opposed to a programmatic click. runbot-161423 Forward-Port-Of: odoo/odoo#259688
This change prevents template tags from overlapping the Template Properties button in the Sign app. It improves the display in wider languages like German so the header stays readable and easier to use.
Original PR description
## Issue In the Sign app, the list of tags of a template can overlap with the *Template Properties* button when using a language that makes those components slightly wider than expected (e.g.…
## Issue
In the Sign app, the list of tags of a template can overlap with the *Template Properties* button when using a language that makes those components slightly wider than expected (e.g. German).
## Steps to reproduce
1. Install Sign (`sign`)
2. Set the language to German
3. Open a template
4. **In the header, the list of tags overlap the _Template Properties_ button**
## Cause
The list of tags uses `col-lg-12`, which is design for Bootstrap's grid system and prevents the div from shrinking properly.
```css
.col-lg-12 {
flex: 0 0 auto; /* flex-shrink set to 0 */
width: 100%;
}
```
## Before
<img width="726" height="67" alt="6023834-1" src="https://github.com/user-attachments/assets/fd49c8d5-4ca0-4de4-8f0c-f03f78f4b7ab" />
<img width="432" height="75" alt="6023834-2" src="https://github.com/user-attachments/assets/d595e8a3-c3ab-4ae2-89dd-652371de9604" />
## After
https://github.com/user-attachments/assets/3a00fc5f-260d-465d-8e12-96d8e6e1aa4c
opw-6023834
Forward-Port-Of: odoo/enterprise#113116This change fixes an issue where already scanned packages could reappear with the wrong quantity when a delivery was reopened in the barcode app. Users will now see the expected quantity of 1 for picked package lines, avoiding confusing or misleading information during warehouse operations.
Original PR description
Issue ----- When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages. Steps to reproduce ----- - Enable packages - Create…
Issue ----- When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages. Steps to reproduce ----- - Enable packages - Create a product with one package in stock - Operation Types > Delivery Orders, set Move Entire Packages to true - Create a delivery for a package - Scan the package barcode - Exit the delivery - Re-enter the delivery > Quantity for the line is 1/false Cause ----- The line is picked, so it is considered as not reserved https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289 when doing https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813 This leads to `qtyDemand` returning false instead of 1 https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18 ----- Ticket: opw-5960629
This update fixes two issues in the Manufacturing Order flow in the Barcode app. It now keeps the unit of measure locked after confirmation, and it preserves any entered quantity when opening and closing the quantity change window, preventing lost edits.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178
Fixed an issue where printed approval requests could lose their translation when no contact was linked to the request. The report now falls back to the request owner’s language, or the system default if needed, so documents print in the expected language more reliably.
Original PR description
Steps to reproduce: ------------------ 1. Install Approvals. 2. Select an approval type from Approvals > Configuration and ensure the 'Contact' field is not required. 3. Install a second language (e.g., Arabic) and switch the user's language. 4. Create a new approval request with this approval type and set user as the request owner. 5. Try to print the approval request. Current behavior: ----------------- The report is only translated when partner is present because it translates using `partner_id.lang`. Since the partner is not required in all cases, `lang` can evaluate to False when it is missing, causing the report to bypass translations. Expected behavior: ------------------ The report should fall back to the request owner's language or the system's default language if the partner is not available. opw-6010222
This fix ensures vendor bills imported from UBL files correctly include negative and positive charges even when the item price is zero. As a result, bill totals are calculated more accurately and avoid being overstated.
Original PR description
# How to reproduce Import in a Vendor Bill an UBL document with InvoiceLines the following properties (the linked ticket has an exemple document) : - The PriceAmount of Item is set to 0 - There are multiple positive and negative AllowanceCharges - The sum of the AllowanceCharges is correctly equal to the LineExtensionAmount # The problem The issue depends on the version, from 18.0 onward it is as follows : The AllowanceCharge are added to the Odoo invoice as invoice lines except the ones that are discount. Theses charges are instead applied as a percentage discount on the base invoice line. But when the price_unit of the invoice line is 0, this discount is not applied, effectively ignoring some charges. This then makes the total of the invoice way bigger than what it should be. Related to : https://github.com/odoo/odoo/pull/250346 opw-5926387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component to a newer version and includes several fixes that improve reliability and reduce unexpected crashes. It also refreshes the build and checking tools behind the scenes, helping keep the spreadsheet feature compatible with newer development standards.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/999e74e453 [REL] 18.0.64 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/999e74e453 [REL] 18.0.64 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3d1cdb71f4 [FIX] spreadsheet_pivot: avoid crash on invalid dimension values [Task: 6111913](https://www.odoo.com/odoo/2328/tasks/6111913) https://github.com/odoo/o-spreadsheet/commit/d7f714d5d1 [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/cc2f54b177 [FIX] package: watch the correct build [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c6fdc6e090 [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/494e2499e6 [FIX] package: add rolldown binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ed233bd731 [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/f9674773af [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659) https://github.com/odoo/o-spreadsheet/commit/c79cef99e3 [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/ac6f91c7d9 [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/2547f06d40 [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/91a9bbd581 [REF] *: apply eslint to entire codebase [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/f0d020979b [IMP] config: Fix eslint to work alongside typescript [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/79efabe926 [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/2d269c30e6 [FIX] side_panel: prevent chart picker layout shift on hover [Task: 6095239](https://www.odoo.com/odoo/2328/tasks/6095239) https://github.com/odoo/o-spreadsheet/commit/cd9b9e9dff [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101) https://github.com/odoo/o-spreadsheet/commit/357ffbba7e [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0e9d22adf3 [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129) 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 fixes an issue in Point of Sale where orders paid with an eWallet could be incorrectly turned into credit notes instead of invoices. The problem was caused by tiny rounding differences, and the fix ensures the system makes the correct document type and keeps quantities accurate.
Original PR description
**Steps to reproduce:** - Make a $10 product, the tax must be tax included - Set up an ewallet - Open the PoS, order the created product and add the ewallet - Ask for an invoice and complete the payment - The generated invoice is a Credit Note **Why the fix:** When chosing the invoice's move_type (invoice or credit note), we check if the total amount is greater or equal to 0, and if it is, we make an invoice, else we make a credit note. This did not work correctly as with the tax included product there was a tiny bit of difference between the product's price and what the ewallet covered. This means that the total was just a tiny bit under zero, and was treated as a refund, so a credit note was then created. The same problem was observed when preparing the invoice lines, the order was treated as a refund, so the lines' qty were inverted. We now use float_compare to avoid such rounding issues. opw-5490407
This fix prevents an error when exporting the General Ledger in the Peru localization, especially when draft invoices or entries are included. Users can now complete the export successfully without the report stopping due to missing entry names.
Original PR description
**Steps to reproduce:** - Install the `l10n_pe_reports_lib` module and switch to a `PE company`. - Create a draft invoice. - Navigate to Reporting > General Ledger. - Click the gear icon and select `Inventory and Balance`. **Error:** AttributeError: 'NoneType' object has no attribute 'replace' **Root Cause:** For draft entries, `move_name` is `None`, and calling `.replace()` on it causes an error at [1]. **Fix:** This commit prevents errors and ensures users can export the general ledger even when draft entries are included. [1]: https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168 opw-6104117
When users create a vendor bill by auto-completing it from a previous bill, the Intrastat transaction information is now kept on the copied lines. This prevents missing reporting data and helps ensure cross-border trade declarations remain complete and accurate.
Original PR description
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to…
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to reproduce:** - Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`. - Create a vendor bill for an `EU partner`, add a product, and set an `Intrastat` (enable from the optional column if needed). - `Confirm` the bill and note its number. - Create a new vendor bill for the `same partner`. - Use the `Auto-complete` feature by selecting the previous bill. - Check the invoice lines. **Observation:** The `Intrastat` is missing from the generated invoice lines. **Root Cause:** - On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] copies invoice lines using `copy_data()`. - However, in `account_intrastat`, `copy_data()` at [2] removes `intrastat_transaction_id`. **Fix:** This commit ensures that `Intrastat` is properly set when creating a vendor bill using the auto-complete feature based on a previously created vendor bill for an EU customer. [1]: https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820 [2]: https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83 opw-5936869 Forward-Port-Of: odoo/enterprise#112857
This update ensures bpost correctly recognizes European Union destinations regardless of the user’s language. As a result, shipments within the EU will no longer be incorrectly treated as non-EU and forced to include customs details such as HS codes.
Original PR description
Since #101476, the EU country group was retrieved by searching on the name field of res.country.group. Because this field has `translate=True`, Odoo resolves it against the current user's language at query time. For non-English users, the search for "European Union" would return no results, causing every destination country to be treated as outside the EU, meaning HS codes were incorrectly required for all bpost shipments, including intra-EU ones.
Replaced occurrences with env.ref("base.europe"), which resolves the record via its external XML ID and is fully language-independent.
opw-6139450This fix makes the kiosk’s online payment page display in the user’s selected language instead of always showing the QR code payment message in English. It improves the customer experience for multilingual setups and helps make the payment flow feel consistent and localized.
Original PR description
Currently if you use an online payment with the kiosk, the payment page with the QR code is not translated. Steps to reproduce: ------------------- * Create an online payment method with demo * Install any language, you don't need to switch * Open kiosk configurations * Set the online pm in the available payment methods * Set the language istalled as the default language * Make an order, go to payment page > "Scan the QR code to pay" is written in english no matter the language opw-6074194
Contact list views now show related contact types in the user’s language instead of always displaying them in English. This makes contact names consistent across views and improves the experience for multilingual users.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987
When a UBL XML invoice is imported into a vendor bill, the chatter now shows the proper import format message instead of an unhelpful "None". This makes the import history clearer for users and ensures the invoice format is always displayed when available.
Original PR description
[FIX] account_edi_ubl_cii: Print right message in chatter at import When a UBL XML invoice is imported in vendor bills and no logs are collected, a message 'None' is printed in the chatter and the message 'Format used to import the invoice: ...' is not printed This commit fixes both issues no-task 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 prevents a test from failing during setup when a related security group module has not been checked for installation yet. It makes the e-invoicing test suite more reliable and avoids an exception during automated runs.
Original PR description
The `get_default_groups` call happens during super.setUpClass(), therefore we have not checked (yet) if the module in which the security group is in is installed, and we end up with an Exception. task-none