Tuesday, April 21, 2026
10 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 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-6139450