Daily updates from Odoo
Tuesday, April 7, 2026
157 changes
22 changes
Resolved issues and error corrections
This update corrects a discrepancy in the calculation of employment bonuses for Odoo Enterprise users in Belgium. The change reflects the latest regulations from Partena Professional, ensuring accurate bonus payments up to April 2026. This update maintains compliance with Belgian tax laws and avoids potential financial discrepancies.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
This update addresses a warning displayed on payslips when GOSI (Saudi Government Social Insurance) contributions are zero. This change ensures compliance with version 19.2 and above, preventing issues with WPS report generation. The fix adds a minimum GOSI contribution percentage to trigger the correct reporting.
Original PR description
[IMP] l10n_sa_payroll: GOSI integration warning
When all of the GOSI contributions are 0, I showed warning in payslip
This is for version 19.2 and above.
task - 6032714This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML adheres to current Swiss banking standards, specifically the pain.001.001.09 format, and adds necessary validation attributes. This improves payment processing accuracy and compliance.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#112273 Forward-Port-Of: odoo/enterprise#107025
This update fixes a restriction in the bank reconciliation process. Previously, tax lines set to 'reconcilable' could not be manually unmatched, even when necessary. Now, users can unmatch these tax lines when reconciling transactions, ensuring accurate accounting and streamlining the bank reconciliation workflow.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#112540 Forward-Port-Of: odoo/enterprise#110186
This update fixes a technical error that prevented users from correctly updating lot numbers on stock move lines. The change ensures that lot IDs are properly linked within the Odoo system, resolving a previous bug that caused errors during inventory adjustments. This improves the reliability of stock tracking.
Original PR description
Since ce2a8f9c929, quality.check.lot_id (Many2one) was changed to lot_ids (Many2many), but the write() override in stock.move.line still assigns a raw integer to the field. This causes a ValueError when changing the lot on an MO move line. With this commit, use Command.link() to properly link the record to the Many2many field. Forward-Port-Of: odoo/enterprise#110180
This update fixes an issue where the barcode scanner was incorrectly identifying products based on the user's company settings instead of the current business context. Now, the barcode scanner accurately recognizes products based on their defined nomenclature, ensuring correct product identification and picking processes. This resolves a situation where products weren't found when scanned.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#112783 Forward-Port-Of: odoo/enterprise#111662
A bug was preventing users with access rights from successfully checking out visitors in the Frontdesk module. This update corrects a filtering issue within user groups, ensuring the 'Check Out Visitor' button now redirects to the correct confirmation page. This resolves a frustrating user experience.
Original PR description
## Short functional explanation of the error When a user checks in, a mail is sent in the chatter, containing a button 'Check out Visitor'. When a user who should have access to the Check Out feature clicks on the button, we are redirected to a 'Not Found' page. ## Reproduction Steps 1. Go to Frontdesk. Click on Open Desk and check in a visitor. 2. Go back to the Frontdesk app. Click on visitors. 3. Click on the visitor you just checked in. 4. Click on the 'Check Out Visitor' button in the chatter. ### Expected behavior A page should appear with the text: 'The visitor has been successfully checked out'. ### Unexpected behavior A 'Not found' page pops up. ## Origin of the issue We filter users who can benefit from the check-out feature using groups. However, the group used to perform this filter is written incorrectly, leading to a condition that is always True, and always returning a request not found. __ opw-5937326 Forward-Port-Of: odoo/enterprise#108331
This update fixes a problem where invoices sent to the Colombian DIAN tax authority would incorrectly be marked as duplicates and rejected. The fix prevents a rollback process when the DIAN GetStatus endpoint fails, ensuring invoices are correctly accepted by DIAN and the system state is accurately updated.
Original PR description
Steps to reproduce:
- Send a Colombian DIAN invoice (SendBillSync flow)
- Simulate a non-200 response from the DIAN GetStatus endpoint during the call of _get_attached_document (see ticket)
Issue:
The invoice is accepted by DIAN but the state is never written. When trying to send the invoice a second time DIAN rejects the invoice as a duplicate (already submitted).
Cause:
`_get_response_history` returns `("", error_msg)` on non-200 status_code and when calling `_get_attached_document`
-> error and rollback and `invoice_accepted` is not written correctly
opw-5919395
Forward-Port-Of: odoo/enterprise#111349
Forward-Port-Of: odoo/enterprise#111186This update ensures that when creating a planning slot for a service product, the system now correctly utilizes the worksheet template assigned to that specific product, rather than a default template. This resolves an issue where the planning slot wasn't reflecting the intended worksheet, leading to inaccurate planning data.
Original PR description
Steps to reproduce: - Assign a worksheet template to a service product. - Create and confirm a Sale Order with that product. - Click “To Plan” smart button and add a planning slot. Current behavior: The slot receives the first worksheet template, ignoring the product's template. Expected behavior: The slot uses the worksheet template defined on the product. task-5966786
This update resolves a potential issue where the Autopay feature incorrectly assigned bank accounts. The change adds a check for valid account numbers before assigning sanitized account numbers, ensuring accurate and reliable Autopay setup. This improves the stability and accuracy of the HK Autopay integration.
Original PR description
. Add account_number check before assign sanitized_account_number task-6049640
This update corrects a restriction on a key field used in Belgian payroll reporting, allowing proper access to necessary data. Previously, access was limited, causing errors when retrieving payroll information. This change ensures accurate reporting and functionality for users in the l10n_be_hr_payroll module.
Original PR description
onss_expeditor_number is used to fetch dimonas and other operations on hr.version, leading to access errors since this field is restricted to base.group_system This commit changes the access rights on the field from `base.group_system` to `hr_payroll.group_hr_payroll_user` task-6094854
This update addresses an issue where the Master Production Schedule (MPS) wasn't correctly accounting for safety stock levels, leading to inaccurate demand forecasts for dependent components. The fix ensures that safety stock is considered when calculating indirect demand, resulting in more reliable production planning and reduced stockouts. This improves the accuracy of the MPS and optimizes inventory levels.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838 Forward-Port-Of: odoo/enterprise#112811 Forward-Port-Of: odoo/enterprise#107671
This update resolves an issue where intercompany purchase orders weren't correctly transferring product variant information, leading to missing components in manufacturing orders. The fix ensures that variant data is properly retrieved from the purchase order, enabling accurate production scheduling within the intercompany process. This improves the reliability of intercompany transactions.
Original PR description
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost. Steps to reproduce: ------------------- * Enable intercompany transaction * Enable variant…
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.
Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
- Never variant with at least two values
- MTO and manufacture
* Create a bom,
- Company : company B
- Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant
Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.
opw-5438723
Forward-Port-Of: odoo/enterprise#107122This update corrects a calculation error within the Belgian HR contract salary module that was impacting the accurate reporting of yearly cost sacrifices. The fix ensures that the system now correctly calculates this key financial metric, improving the reliability of HR reporting. This change primarily affects payroll and financial reporting processes.
Original PR description
Forward-Port-Of: odoo/enterprise#112723
This update corrects a bug that caused the 'Replace by Attendance' button to fail when multiple attendance work entries of the same type were created. The fix eliminates duplicate entries from a data processing step, preventing the application from crashing and ensuring the button functionality works correctly.
Original PR description
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on…
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB) - Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated > If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError** ### Cause of issue: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17 ### Fix: Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`. opw-5953671 Forward-Port-Of: odoo/enterprise#109986 Forward-Port-Of: odoo/enterprise#109823
This update fixes a misleading chart in the Purchase & Vendor Analysis dashboard. The chart title was previously inaccurate, suggesting supplier dependency instead of showing purchase orders by buyer. The title has been corrected to accurately reflect the data displayed, improving clarity for users.
Original PR description
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it…
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it suggests that the chart represents dependency on each supplier. However, the chart actually shows how many purchase orders are created by each buyer. Additionally, when there are no purchase orders, the sample pie chart displayed uses the title `Purchase Order by Buyer`, which creates inconsistency between the actual chart title and the sample chart title. Steps to Reproduce: ================= - Install the **purchase_stock** module with demo data. - Go to the **Dashboard** app. - Open the **Purchase & Vendor Analysis under the Logistics** section. - Scroll down to locate the pie chart titled **Supplier Dependency Chart**. Cause of the Issue: ================ In this [PR](https://github.com/odoo/enterprise/pull/93921), at [this line](https://github.com/odoo/enterprise/pull/93921/changes#diff-61d19b77200011a8808542c134a675631e6d4b4dbc88ca99353cacfe3448b396), The pie chart title was incorrectly set to `Supplier Dependency Chart`, which does not reflect the underlying data, as the chart displays purchase orders grouped by buyer. After This Commit: ================ The pie chart title is corrected from `Supplier Dependency Chart` to `Purchase Order by Buyer`, ensuring it accurately repersent the underlying data and avoids misleading users. TaskID-5891759 Forward-Port-Of: odoo/enterprise#110434
This update fixes a discrepancy in the way tax report amounts are displayed for TDS (Tax Deduction at Source) and TCS (Tax Collected at Source) reports in the Odoo system for the Russian market (l10n_in). The change ensures accurate reporting of these amounts, aligning with recent system updates. This improves the reliability of financial data for Russian businesses using Odoo.
Original PR description
In https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the automatic +/- sign handling was removed from the tax grid logic. To stay consistent with this change, the newly added TDS Report 2025 has been updated accordingly. task-6097997 Forward-Port-Of: odoo/odoo#257775
This update fixes an issue where proforma invoices were incorrectly displaying 'Order' as the document title instead of 'Pro Forma'. The fix ensures the correct title is generated when printing proforma invoices, improving the accuracy of sales documentation. This change was triggered by a previous update and resolves a discrepancy in how the document title is set.
Original PR description
Issue: --- `layout_document_title` is not correctly set in proforma document. Steps to reproduce: 1- Create a SO and confirm. 2- Print the Pro forma invoice. The title is Order while it should be Pro Forma. Cause: --- This issue is introduced after #232539. `is_proforma` is not set before setting `layout_document_title`. opw-6043669
The automated testing process for Odoo has been updated to more accurately manage timeout settings. Previously, a single, lengthy timeout was used regardless of whether tests were running on a small or large set of modules. This change adjusts the timeout based on the scope of the tests, preventing unnecessary delays and ensuring faster test execution. This improves the stability and speed of our automated testing.
Original PR description
Hoot suites (test_unit_desktop and test_unit_mobile) are now split and run in each sub builds on runbot [1]. As a consequence, the historical timeout isn't accurate anymore (we don't need a 1h…
Hoot suites (test_unit_desktop and test_unit_mobile) are now split and run in each sub builds on runbot [1]. As a consequence, the historical timeout isn't accurate anymore (we don't need a 1h timeout when only a part of the suite is run in a sub build). On the other hand, the whole suite is also run at once in nightly builds. There, the 1h timeout is sometimes not enough, as the suite keeps growing. This commit makes the timeout more accurate by taking into account 2 different cases: if the suite is run for a subset of modules, or if it is run for the whole codebase. This allows it to timeout earlier on regular builds if it is deadlocked, and it doesn't timeout anymore on nightly builds. [1] https://github.com/odoo/odoo/pull/234132 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 Forward-Port-Of: odoo/odoo#257478
This update ensures that only invoices can be grouped within the account_edi_ubl_cii module. Previously, other document types like journal entries could be grouped, which has now been corrected. This change improves data accuracy and consistency within the invoicing process.
Original PR description
[FIX] account_edi_ubl_cii: Allow only invoices can be grouped Before this commit, no check was done on the document type at line grouping. This commit adds the check `is_invoice` so that we cannot group (e.g.) a journal entry type move no-task Forward-Port-Of: odoo/odoo#257314 Forward-Port-Of: odoo/odoo#255359
This update fixes an issue where tracking references weren't consistently passed through multi-step delivery processes. Now, when 'Propagate carrier' is enabled on a delivery rule, the tracking reference will automatically update to the next picking, ensuring better shipment visibility and traceability for sales orders. This enhancement improves order tracking accuracy and efficiency.
Original PR description
Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Go to Warehouse Management → Operation Types
- Set Delivery to 3 steps
- Open the 3-step delivery routes and enable “Propagate carrier” on any rule
- Create a storable product P1
- Create a sales order with 1 unit of P1
- Confirm the sales order
- Open the generated picking
- Go to the Additional Info tab
- Set Tracking Reference = 123
- Confirm the picking
- Open the next picking (Pack operation)
Problem:
The tracking reference is not propagated to the next picking, even though the rule has “Propagate carrier” enabled.
Expected behavior:
The tracking reference should be propagated to the subsequent picking when carrier propagation is enabled on the rule. Even if no carrier set.
opw-6052930
Forward-Port-Of: odoo/odoo#256851This update resolves an issue impacting website performance by optimizing how product categories are checked for published products. The previous method caused excessive database queries, but this fix restores efficient performance and ensures faster website loading times. This change improves the overall user experience.
Original PR description
`has_published_products` was previously computed recursively. For recursive fields, the ORM disables prefetch optimizations. In 3ffca1961cb1671e7028dd4dceca82d2e74a2e21, the computation switched to…
`has_published_products` was previously computed recursively. For recursive fields, the ORM disables prefetch optimizations.
In 3ffca1961cb1671e7028dd4dceca82d2e74a2e21, the computation switched to `_read_group` to avoid loading all published products into cache and prevent memory issues. However, this introduced an N+1 pattern when evaluating:
```python
categories.filtered(lambda categ: categ.has_published_products)
```
As a result, query count became dependent on the number of active categories, which broke SQL performance tests when demo data were installed.
This commit updates the computation again to avoid recursion and restore ORM prefetch optimizations, making the number of queries independent of the number of active categories.
This commit also removes redundant checks already enforced by ORM `ir.rule`. For example, the following pattern evaluates `has_published_products` three times: once in the user domain, once in the access rule domain added by `search`, and once in the filter.
```python
domain = [("has_published_products", "=", True)]
categs = self.env["product.public.category"].search(domain)
categs.filtered("has_published_products")
```
runbot-234948
Forward-Port-Of: odoo/odoo#257071
Forward-Port-Of: odoo/odoo#25641511 changes
Resolved issues and error corrections
This update resolves a technical issue that caused Odoo to crash when calculating annual leave days for newly created employees. The fix prevents the system from attempting direct database queries when a record is in its initial 'New' state, ensuring smoother operation and preventing errors.
Original PR description
This commit will add a guard condition to the `l10n_ae_annual_leave_days_total`'s compute method to skip SQL execution when the record has no database ID. Why: Users experienced a server-side traceback when opening Odoo Studio on the employee form and enabling the 'Annual Leave Days Total' field. The traceback occurred because the field's compute method attempted to execute a direct SQL query using `self.ids`. What: - Added a check for `self.ids` at the beginning of the compute method. - Ensured the field defaults to `0` or a neutral value if the record is still in the "New" state. task-5940225 Forward-Port-Of: odoo/enterprise#112867
This update resolves an issue where spreadsheet names weren't correctly reflected after renaming. By removing the outdated caching mechanism and using 'no-cache' headers, the system now always fetches the latest spreadsheet data, ensuring users always see the correct version.
Original PR description
This reverts commit 8f3e242e197b2f269827499b0d89b2e9080f5d09. Etag was computed from the spreadsheet content, but we forget to take spreadsheet metadata (like the name, ...) into account. So when user renames a spreadsheet, the browser still has the old version in cache and does not fetch the new name. This commit removes the ETag and use no-cache headers to ensure browsers always fetch the latest version of the spreadsheet data. Task: 5441251
This update corrects a calculation error within the Belgian HR contract salary module that was impacting the accurate determination of yearly cost sacrifice figures. The fix ensures that these figures are now calculated correctly, improving the reliability of financial reporting related to employee contracts. This change primarily affects payroll processing for Belgian entities.
This update resolves an issue preventing the launch of a Web Studio tour due to a problem with how the editor tracked changes. Additionally, a crash in the report processing system was fixed by using a more reliable architecture copy. This ensures the Web Studio functionality continues to operate smoothly.
Original PR description
These changes were made because the diff in https://github.com/odoo/odoo/pull/252844 caused a tour in *web_studio_test_ui_unit_report_tours.js* to fail Cause of issue: =============== For the tour, the powerbox wasn't opening because DOM changes weren't registered with the editor's state system. For *report.py*, after changes to the tour, the system tried loading from file using the backup key as an XML ID. Since backup keys contain dots https://github.com/odoo/enterprise/blob/7ca23bee6f84ccd0cd9c1cd747f434f3cc37861e/web_studio/controllers/report.py#L354 the XML ID parser crashed. Fix: ==== For the tour, registered the DOM mutation (span insertion in the other PR) with the editor's history, since the editor uses a MutationObserver that only processes changes it's aware of. For *report.py*, clearing arch_fs uses the already-copied architecture from arch_db instead.
This update fixes an issue where clicking links within charts directed users to the wrong view for data sources. Now, links correctly navigate users to the appropriate view type (e.g., a list view for a list datasource), improving the user experience and ensuring accurate data access.
Original PR description
Currently, if the user clicks on a datasource link (inside a chart) they will be directed to the default view of the action realted to the datasource model but it will not go to the corresponding type of view (e.g. a list datasource should direct to a list view). Task-5957004
This update resolves a technical issue that could cause errors when generating sales achievement reports, specifically when filtering by the current period. The fix ensures the system correctly handles date formatting, preventing a ValueError and ensuring reports run smoothly. This improves the reliability of sales reporting.
Original PR description
Before this commit, the following traceback could occurs when filtering the current period in achievements.
File "/home/arj/PycharmProjects/worktree/saas-19.1/enterprise/sale_commission/report/achievement_report.py", line 79, in _search
date_to_list = date_to_domain and [datetime.strptime(d[2], '%Y-%m-%d') for d in date_to_domain if len(d) == 3 and d[2]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 554, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 333, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data 'today' does not match format '%Y-%m-%d'This update resolves an issue where the system incorrectly identified late hours for employees without a recorded check-in time. The fix ensures that late hours visibility is only calculated when an employee has a valid check-in record, preventing errors and improving the accuracy of time tracking reporting.
Original PR description
_compute_l10n_sa_late_hours_visible, calling min() on the mapped check_in values and then .date() would crash with an AttributeError when check_in is False (e.g. during an onchange triggered by clearing the check_in field in the form view). Filter out records without a check_in before computing the date range, and mark them as not visible since late hours cannot apply without a check-in time. task-6067640
This update addresses an issue where the Master Production Schedule (MPS) wasn't correctly accounting for safety stock levels when calculating indirect demand. The fix ensures that safety stock is considered, leading to more accurate production forecasts and reduced stockouts. This improves the reliability of the MPS planning process.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838 Forward-Port-Of: odoo/enterprise#112811 Forward-Port-Of: odoo/enterprise#107671
This update fixes a misleading chart in the Purchase & Vendor Analysis dashboard. The chart title was previously inaccurate, suggesting supplier dependency instead of showing purchase orders by buyer. The title has been corrected to accurately reflect the data displayed, improving clarity and preventing user confusion.
Original PR description
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it…
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it suggests that the chart represents dependency on each supplier. However, the chart actually shows how many purchase orders are created by each buyer. Additionally, when there are no purchase orders, the sample pie chart displayed uses the title `Purchase Order by Buyer`, which creates inconsistency between the actual chart title and the sample chart title. Steps to Reproduce: ================= - Install the **purchase_stock** module with demo data. - Go to the **Dashboard** app. - Open the **Purchase & Vendor Analysis under the Logistics** section. - Scroll down to locate the pie chart titled **Supplier Dependency Chart**. Cause of the Issue: ================ In this [PR](https://github.com/odoo/enterprise/pull/93921), at [this line](https://github.com/odoo/enterprise/pull/93921/changes#diff-61d19b77200011a8808542c134a675631e6d4b4dbc88ca99353cacfe3448b396), The pie chart title was incorrectly set to `Supplier Dependency Chart`, which does not reflect the underlying data, as the chart displays purchase orders grouped by buyer. After This Commit: ================ The pie chart title is corrected from `Supplier Dependency Chart` to `Purchase Order by Buyer`, ensuring it accurately repersent the underlying data and avoids misleading users. TaskID-5891759 Forward-Port-Of: odoo/enterprise#110434
This update fixes a minor issue with the TDS/TCS report amounts in the Odoo accounting module for Russia (l10n_in). The automatic +/- sign handling was previously removed, and this change ensures the correct positive or negative sign is displayed for these report amounts, aligning with current tax regulations. This ensures accurate reporting for tax compliance.
Original PR description
In https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the automatic +/- sign handling was removed from the tax grid logic. To stay consistent with this change, the newly added TDS Report 2025 has been updated accordingly. task-6097997 Forward-Port-Of: odoo/odoo#257775
This update ensures that only invoices can be grouped within the account_edi_ubl_cii module. Previously, grouping was allowed for various document types, which could lead to inconsistencies. This change improves data accuracy and compliance by limiting grouping to invoices, the intended use case.
Original PR description
[FIX] account_edi_ubl_cii: Allow only invoices can be grouped Before this commit, no check was done on the document type at line grouping. This commit adds the check `is_invoice` so that we cannot group (e.g.) a journal entry type move no-task Forward-Port-Of: odoo/odoo#257314 Forward-Port-Of: odoo/odoo#255359
1 change
Resolved issues and error corrections
This update corrects the calculation of employment bonuses in the Odoo Enterprise system for Belgium, aligning with new regulations announced by Partena Professional as of April 1, 2026. The change ensures accurate reporting of bonus amounts for Belgian HR and payroll processes. This update addresses a discrepancy in the previously calculated bonus figures.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
15 changes
Resolved issues and error corrections
This update corrects a discrepancy in the calculation of employment bonuses for Odoo Enterprise users in Belgium. The change reflects the latest regulations from Partena Professional, ensuring accurate bonus payments up to April 2026. This update maintains compliance with Belgian tax laws and avoids potential financial discrepancies.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
A recent update to Odoo inadvertently created a problem with purchase order confirmations. This fix corrects a field name change that was causing errors, ensuring purchase orders can be processed correctly. This resolves a rare but impactful issue that could block order confirmations.
Original PR description
A big refactor of UOM in saas-18.1 (https://github.com/odoo/odoo/pull/184131) accidentally left a reference to the `product_uom` field on `purchase.order.line`. But that field was renamed to `product_uom_id` in https://github.com/odoo/odoo/pull/186250. In rare edge-cases, if we it `supplierinfo['product_uom_id'] = line.product_uom.id` while confirming a purchase order, it will block it because of a traceback: ``` supplierinfo['product_uom_id'] = line.product_uom.id ^^^^^^^^^^^^^^^^ AttributeError: 'purchase.order.line' object has no attribute 'product_uom'. Did you mean: 'product_id'? ``` This PR fixes the issues by accounting for the field rename. OPW-6068125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256416
This update fixes an issue where the table toolbar wasn't appearing correctly when selecting columns in a table. Specifically, it ensures the toolbar aligns with the actively selected cells, providing a more intuitive user experience. This enhancement improves the usability of the HTML editor within Odoo.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a 3 x 3 table. - Select 3rd column and wait for toolbar. Currently, the toolbar is positioned at the start of the table even when the last column is selected. This happens because selecting cells in the 3rd column creates a DOM selection range that starts at the first cell and ends at the last cell of the column, traversing all intermediate elements. As a result, browser's range rectangle does not match the actual custom-selection rect. **Desired behavior after PR is merged:** Now, Toolbar is positioned correctly above the custom selected cells. task-5935587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257608 Forward-Port-Of: odoo/odoo#248964
This update fixes a misleading error message users saw when trying to edit property fields without a parent category. The message has been changed to a clearer instruction: "Oops! A <parentFieldLabel> is needed to add property fields." This improves usability and guides users correctly.
Original PR description
Issue: ------------------------------------------ - When using property fields (e.g., products where categories are optional), users trying to edit properties without a parent document receive a…
Issue: ------------------------------------------ - When using property fields (e.g., products where categories are optional), users trying to edit properties without a parent document receive a broken warning: "Oops! You cannot edit the Category 'undefined'." - This message is misleading and does not explain the actual dependency. How to reproduce: ------------------------------------------ 1. Create or edit a record (e.g., product) without setting its parent (e.g., category). 2. Click the cog menu and select "Edit Properties". Cause of the issue: ------------------------------------------ - In the `PROPERTY_FIELD:EDIT` bus handler, when `definitionRecordId` is missing, `checkDefinitionWriteAccess` returns `false`, which then calls `_getPropertyEditWarningText`. That method accesses `false[1]` on the unset field, resulting in "undefined" in the warning message. Solution: ------------------------------------------ - Added a check in `_getPropertyEditWarningText` to return an appropriate message when `definitionRecordId` is missing: "Oops! A `<parentFieldLabel>` is needed to add property fields." task-4589393 Forward-Port-Of: odoo/odoo#205107
This update resolves an issue where the width of avatar names was incorrectly set to zero, causing display problems. The fix ensures that avatar names are displayed at their intended size, improving the visual consistency of user profiles and communications within Odoo.
Original PR description
This commit fix the width of the displayName option of the Avatar component which was fixed to zero (bootstrap class 'w-0') Task-5122979
This update fixes several issues within the odoo spreadsheet library, improving its reliability and functionality. Specifically, it addresses date formatting problems, enhances error handling, and modernizes the testing environment. These changes ensure a smoother and more accurate spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b5e1d35c57 [REL] 18.3.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b5e1d35c57 [REL] 18.3.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c8e3f24c0a [FIX] Grid: hide the table resizer in readonly mode [Task: 6054035](https://www.odoo.com/odoo/2328/tasks/6054035) https://github.com/odoo/o-spreadsheet/commit/5911d26f6c [FIX] formats: bypass date format for invalid dates [Task: 6032998](https://www.odoo.com/odoo/2328/tasks/6032998) https://github.com/odoo/o-spreadsheet/commit/b863739c61 [FIX] Formats: properly format dates with 3 year digits [Task: 6032998](https://www.odoo.com/odoo/2328/tasks/6032998) https://github.com/odoo/o-spreadsheet/commit/d0bf86df89 [FIX] package: update types/jest to match jest version [Task: 6092447](https://www.odoo.com/odoo/2328/tasks/6092447) https://github.com/odoo/o-spreadsheet/commit/cb4d3a2177 [FIX] tests: add missing tsconfig.json [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/49ee6ba090 [FIX] config: move to ESM release tool [Task: sotg](https://www.odoo.com/odoo/2328/tasks/sotg) https://github.com/odoo/o-spreadsheet/commit/f08865bf8e [IMP] Errors: Add error origin position for #SPILL errors [Task: 5959985](https://www.odoo.com/odoo/2328/tasks/5959985) 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 where browser tab changes while the product configurator dialog is open would reset sales orders to their previous state. Now, changes made within the dialog are correctly saved, ensuring data integrity when switching between tabs. This improves the user experience and prevents data loss.
Original PR description
## Versions 18.0+ ## Issue When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been…
## Versions
18.0+
## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.
## Steps to reproduce
- Create a new SO for any customer:
- Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
- Save manually;
- Change the product for a combo or variant one (e.g. "Customizable Desk");
- With the opened dialog, change from browser tab then come back;
- The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).
## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.
## Test
No test as we cannot simulate a browser tab change then come back to the first tab.
opw-5494089
Forward-Port-Of: odoo/odoo#257482
Forward-Port-Of: odoo/odoo#247797This update corrects a bug in the Point of Sale order report that incorrectly displayed margin values when orders were placed in different currencies. The fix ensures that the margin calculation and reporting now accurately reflect the currency used in the order, providing more reliable financial reporting for sales transactions. This improves the accuracy of sales analysis and reporting.
Original PR description
When making a pos order in a PoS that uses a different currency, the margin in the pos order report would not take the currency into account Steps to reproduce: ------------------- * Create a product with a price of 100€ and cost 0€ (margin = 100€) * Setup a PoS to use a different currency with a rate of 2 (so 1€=>0.5) * Create a PoS order for this product and validate it * Go to the pos order report and select the order you just made > Observation: The value of the margin is 200 expressed in the different currency, when the rest of the report is using the company currency. Why the fix: ------------ The currency was only applied on the product cost, we now apply it on the whole margin. opw-5927473 Forward-Port-Of: odoo/odoo#255344
The session reports generated from Point of Sale orders with decimal quantities were displaying excessive decimal places. This update rounds the final totals to two decimal places, ensuring accurate reporting of sales data. This improves the clarity and reliability of sales reports.
Original PR description
When selling a lot of product with different quantities (quantities with decimals) the session report total by category might have a lot of decimals instead of 2. Steps to reproduce: ------------------- * Open PoS * Make an order with a lot of product and modify the quantities to have random values with decimals * Close the session * Generate the session report > Observation: The total qty by category has a lot of decimals instead of the 2 expected. The same error also happens for the total price Why the fix: ------------ We round each value with their respective precision to make sure we don't have 15 decimals. opw-6039016 Forward-Port-Of: odoo/odoo#256038
This update resolves an issue where the 'Export XML' button for EU Standard (Peppol Bis 3.0) invoices wasn't functioning correctly. Now, users can download invoices in the expected XML format when creating invoices with this eInvoice type, ensuring proper compliance with Peppol regulations. This improves the ability to integrate with external systems.
Original PR description
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice…
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice Type as "EU Standard (Peppol Bis 3.0)" - Create an invoice - Confirm it - Click on the Wheel -> Download Current behavior: - without l10n_hr_edi: only "PDF" and "PDF without Payment" - with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file Cause: "Export XML" button appear only if: - there is a default ubl option for the partner country - there is an XML attached to the invoice when clicked it exports the corresponding one. Whereas, the 'send' button rely on: 1) the partner defined edi format, 2) the default ubl option for the partner country 3) "ubl_bis3" To be noted: The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice. opw-5943500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues causing unreliable test results in the HTML editor's testing framework. By ensuring tests wait for the editor's full initialization, the tests are now more consistent and predictable, reducing the risk of false failures. This improves the overall stability of the HTML editor module.
Original PR description
See individual commits.
This update fixes an issue where Odoo incorrectly consumed stock from the wrong location when scanning serial numbers on manufacturing orders. The fix ensures the correct warehouse location is used, preventing errors in inventory tracking and improving order fulfillment accuracy. This resolves a potential problem with stock discrepancies.
Original PR description
Steps to reproduce: - Create a Manufacturing Order with a serial-tracked component. - Open the Shop Floor. - Scan the serial number barcode to register the component. - Observe which location the component was consumed from. Issue: When a product is received from a vendor, Odoo creates two quants for the same serial number — one at Partners/Vendors location and one at WH/Stock location. Because get_quant_from_barcode searched for a matching serial number with no location filter, it returned whichever quant had the lowest database ID — which was always the Partners/Vendors or Production quant created first — instead of the correct WH/Stock quant. Solution: Prevent selecting a quant from an incorrect location when multiple quants exist for the same serial number, as this can lead to consuming stock from the wrong location. opw-5974474
This update adds a required field to Milestone actions to ensure the Odoo database remains stable during upgrades. The change addresses a technical constraint within the Odoo database structure that prevents both an action ID and a custom Python method from being defined simultaneously. This ensures smooth database updates and prevents potential issues.
Original PR description
Add an empty `python_method` field to the Milestones embedded actions. This is necessary to satisfy the `_check_only_one_action_defined` constraint during database upgrades. The `ir.embedded.actions` model enforces an XOR constraint between `action_id` and `python_method`, preventing both fields from being set simultaneously. Related PR: https://github.com/odoo/odoo/pull/254102 task-5993183
This update corrects errors related to Spanish Value Added Tax (IGIC) calculations, specifically for the 5% rate. It adds the necessary tax codes and fiscal positions, ensuring accurate reporting of IGIC for Spanish businesses using Odoo. This improves compliance with Spanish tax regulations.
Original PR description
- Fix also some errors on the 5% taxes, where a 3 percent was applied or the group was not the right onw @jco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231836
This update corrects a previous issue where the Amazon fulfillment channel within the sales module was incorrectly displayed as read-only. The change ensures users can now modify their Amazon channel settings, streamlining the process for managing Amazon sales fulfillment. This improves operational efficiency.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#112866
3 changes
Resolved issues and error corrections
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The fix skips PDF extraction when raw data is missing, ensuring consistent document processing and preventing errors. This improves the reliability of document generation.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update fixes an issue where refund orders weren't correctly included when calculating outstanding customer dues. Now, the system accurately reflects all outstanding amounts, including refunds, ensuring accurate reporting and settlement processes for customer payments. This improves the reliability of our financial data.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313
This update corrects a discrepancy in the calculation of employment bonuses for Odoo Enterprise users in Belgium. The change reflects the latest regulations from Partena Professional, ensuring accurate bonus payments up to April 2026. This update maintains compliance with Belgian tax laws and avoids potential financial discrepancies.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
20 changes
Resolved issues and error corrections
This update fixes a calculation error in the payroll system related to minimum hourly wages for Belgium (CP200). Previously, the system incorrectly displayed monthly wages as the minimum hourly wage. Now, the system accurately calculates the minimum hourly wage based on the employee's wage type, ensuring accurate payroll reporting.
Original PR description
Before this commit, we don't consider calculating the minimum hourly wage in CP200. Related warning was showing a wrong value (the monthly wage). After this commit, we calculate the value of the min wage depending on the wage_type Hourly wage is calculated like this: (monthly_min_wage * 3) / 13 / hours_per_week task-6074973
This update resolves a visual issue in the Belgian localization's return checks reports. Empty line breaks were disrupting the styling, leading to inconsistent formatting. Removing these unnecessary lines restores the correct styling and ensures a professional appearance.
Original PR description
Description of the issue this commit addresses: The return checks templates in the belgian localization have empty line breaks in their message causing the continuity of the styling of the return checks to break. --- Desired behavior after this commit is merged: This commit removes all the unnecessary blank lines from the return checks messages so the styling is restored and accurate according to the defined style --- task-6050886
This update resolves an issue impacting product exports within the Web Studio module. The team has decoupled export logic, requiring a second context key to be added. This change ensures product exports function correctly and reliably, maintaining data integrity.
Original PR description
This commit https://github.com/odoo/odoo/pull/254323 changed the way product( template)s are created, which now decouples the logic into two context attributes instead of one. This commit fixes this by adding the second one. Forward-Port-Of: odoo/enterprise#112903 Forward-Port-Of: odoo/enterprise#112753
This update fixes a restriction in the bank reconciliation process that prevented users from manually unmatching tax lines when the related tax account was set to 'reconcilable'. Previously, tax lines were protected to maintain tax integrity, but this now allows for greater flexibility in reconciling transactions, particularly when tax accounts are configured for reconciliation. This improves the user experience and accuracy of bank reconciliation.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#112540 Forward-Port-Of: odoo/enterprise#110186
This update resolves an error that prevented the General Ledger consolidation feature from functioning correctly when multiple companies were selected. The fix ensures the consolidation process now handles multi-company scenarios without crashing, improving the reliability of financial reporting.
Original PR description
### Issue before this commit: When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'. ### Steps to reproduce the…
### Issue before this commit: When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'. ### Steps to reproduce the issue: 1. Select two or more companies from multi company menu 2. Accounting / Reporting / Ledgers / General Ledger 3. Posted Entries, Accrual Basis button 4. Pick Consolidation 5. Error ### Cause of the issue: When more than one company is selected, the General Ledger consolidation groups journal entries by multiple parameters in an increasingly strict hierarchy. One of these parameters is account_code, which is required only in a multi-company context (as account_id alone is sufficient when a single company is selected). However, the SQL query was not properly adapted to handle this case. The account_code field was used as a grouping key but was not retrieved from the database, resulting in a KeyError. ### Reason to introduce the fix: To ensure that the General Ledger consolidation can be correctly displayed in a multi-company context and to prevent runtime errors. opw-5933074 Forward-Port-Of: odoo/enterprise#112738 Forward-Port-Of: odoo/enterprise#109036
This update resolves a problem where the Kanban view for work orders wasn't correctly displaying colors. The change utilizes a new color field introduced in a recent update, ensuring work orders are properly categorized and visible within the Kanban interface. This improves the user experience and accuracy of work order management.
Original PR description
Forward-Port-Of: odoo/enterprise#107702
This update fixes an issue where search filters in the MRP Planning view would reset when users navigated away and returned. The fix ensures that search filters are retained, providing a more consistent and efficient user experience for planning and reporting.
Original PR description
Issue: In the MPS view, when the user sets a search filter, navigates away and then returns via the breadcrumb, the search filters that were applied are gone. This happened because the MPS client action was not passing `globalState` to the `WithSearch` component. Fix by passing `globalState` in `withSearchProps`. task-5368078
This pull request reverts recent changes to the Odoo template architecture, bringing back the previous design style (M3.1). This ensures continued functionality and stability while allowing for necessary adaptations. The change addresses an issue related to existing code present in the M3 implementation.
Original PR description
This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * M3: some class are still present task-6054024 Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
This update fixes a bug where flexible schedules with different time zones were incorrectly displaying an inflated number of expected hours (48 instead of 40). The change ensures accurate hour calculations by properly accounting for time zone differences, preventing inaccurate attendance reporting.
Original PR description
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of…
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang. 2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time. 3. Open Attendances. ### Expected behavior When we hover the name of our employee, we can see in white on green background 0/40h. ### Unexpected behavior Instead, we see 0/48h. ## Origin of the issue This line: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419 is used to retrieve the correct date. We assume that `end_datetime` will be set at midnight, so subtracting one second gives us the day before, allowing us to ignore the date of `end_dt`, for which we don't need to compute the intervals. However, this doesn't take into account different time zones. Indeed, we compute `end_datetime_adjusted` from `end_datetime`, which has the user timezone, and not UTC, as defined here: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402 As a result, if we set the user timezone to Pyongyang, `end_datetime` will be set at 8am, and `end_datetime_adjusted` will lead to the same date, instead of a day before. Hence, we would compute an additional interval for an additional day, which would in the end give us 48 hours expected instead of the 40 hours indicated in the contract. Therefore, we have to take into account the time zones, hours, minutes and seconds when checking the start and end dates. __ opw-5937298 Forward-Port-Of: odoo/enterprise#111332 Forward-Port-Of: odoo/enterprise#110011
This update fixes an issue where the barcode scanner was incorrectly using the user's company instead of the current business context. This resulted in incorrect barcode lookups. The fix ensures the scanner uses the correct company information, resolving the problem of incorrect product identification and enabling accurate barcode scanning across different company setups.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#112783 Forward-Port-Of: odoo/enterprise#111662
This update enhances the Gantt view by adding a visual warning – a danger icon – to shifts that were created to fulfill cancelled Sales Orders. This immediately highlights potential issues and ensures that team members are aware of orders that are no longer active, improving workflow efficiency. The warning remains visible in the shift's form view for additional detail.
Original PR description
Adding warnings on the Gantt view to make it more clear at a glance when a shift had it SO cancelled. ### Before Commit Behavior : 1. A Sales Order (SO) is created for a plannable service. 2. A shift is scheduled to fulfill the SO. 3. The SO is cancelled before the shift is completed. 4. No warning or icon is displayed on the shift in the Gantt view. 5. A warning is only visible in the shift's form view. ### After Commit Expected Behavior : When a shift is created to fulfill a Sales Order, and that SO is later cancelled: - A danger icon is displayed directly on the shift in the Gantt view. - A danger message is also shown in the shift preview within the Gantt view. - A warning in the shift's form view is still showed. #### Task : [4844848](https://www.odoo.com/odoo/project/4105/tasks/4844848)
This update corrects an issue preventing the generation of XML reports for Profit & Loss statements when footnotes were included. The fix addresses a dependency on an outdated model, ensuring the export functionality now works correctly. This resolves a technical problem impacting report generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#112917 Forward-Port-Of: odoo/enterprise#107765
This update fixes an issue where the correct fields (employee or applicant) weren't consistently displayed when creating a contract offer. The change ensures that the appropriate field – employee ID or applicant ID – is shown based on whether the offer is for an existing employee or a new applicant, improving the user experience and data accuracy.
Original PR description
Ensure the correct field (employee or applicant) is visible when creating a contract offer, whether for an existing employee or a new applicant. Visibility truth table: | employee_id | applicant_id | Visible Field | |-------------|--------------|---------------| | False | False | applicant_id | | False | True | applicant_id | | True | False | employee_id | | True | True | applicant_id | Task: 6094737
This update enhances the functionality of French financial reports by transitioning from a 'hard reload' to a 'soft reload' process. This change improves the dynamic updating of report lines, leading to a smoother and more responsive user experience. It addresses a usability issue within the l10n_fr_reports module.
Original PR description
This commit will change the hard reload for a soft one, to make the usability of dynamic lines better no task id
This update fixes a warning displayed in payslips when all GOSI contributions are zero, a problem identified in versions 19.2 and above. The change ensures the WPS report can be generated correctly by adding a minimum GOSI contribution percentage, preventing the warning and maintaining accurate payroll reporting.
Original PR description
[IMP] l10n_sa_payroll: GOSI integration warning
When all of the GOSI contributions are 0, I showed warning in payslip
This is for version 19.2 and above.
task - 6032714
Forward-Port-Of: odoo/enterprise#112888This update fixes inconsistencies in how the Odoo editor creates empty blocks. The system now automatically inserts a line break when a container is empty, simplifying the process for developers and ensuring a more reliable editing experience. This change improves the editor's stability and ease of use.
Original PR description
*: accountant_knowledge, ai, knowledge, web_studio ### Purpose of this commit: - Previously, `createBaseContainer` returned an empty container and callers were responsible for ensuring it remained editable. In practice, some code paths manually inserted a `<br>` while others relied on `fillEmpty()`, leading to inconsistent handling of empty blocks. - This commit updates `createBaseContainer` to handle empty containers directly by inserting a `<br>` when no children are provided. - The function now also accepts optional `children`, allowing callers to create a populated container. community - https://github.com/odoo/odoo/pull/254081 task-6014415
This update simplifies the installation process for the ActivityWatch timesheet grid by adapting instructions and adding better troubleshooting tools. It also enhances the assistant's functionality with improved rule data and clearer display of activity information, ultimately making setup and usage more straightforward.
Original PR description
This PR revamps the ActivityWatch installation wizard to adapt the instructions to the new installers, as well as providing more ways to check that the server is successfully installed and running. It also provides a few other fixes related to the assistant in general. Task-6042434 Forward-Port-Of: odoo/enterprise#113098 Forward-Port-Of: odoo/enterprise#112127
This update corrects inconsistencies in how Odoo calculates certain fields, specifically related to employee data. By switching from `@api.onchange` to `@api.depends`, the system now accurately reflects changes in related data within the same transaction, preventing potential data errors. This ensures data integrity across multiple modules.
Original PR description
https://github.com/odoo/odoo/pull/257758
This update corrects a restriction on a key field used in payroll reporting, preventing access errors when generating reports. The change expands access rights to allow necessary operations related to HR versioning, ensuring accurate and reliable payroll processing. This resolves a technical issue impacting report generation.
Original PR description
onss_expeditor_number is used to fetch dimonas and other operations on hr.version, leading to access errors since this field is restricted to base.group_system This commit changes the access rights on the field from `base.group_system` to `hr_payroll.group_hr_payroll_user` task-6094854 Forward-Port-Of: odoo/enterprise#112944
This update eliminates a technical issue causing errors when adding multiple attendance work entries, specifically within the Payroll app. The fix removes duplicate entries created through the work entry calendar, preventing a crash in the user interface. This ensures a smoother experience for users managing their work schedules.
Original PR description
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on…
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB) - Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated > If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError** ### Cause of issue: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17 ### Fix: Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`. opw-5953671 Forward-Port-Of: odoo/enterprise#110245 Forward-Port-Of: odoo/enterprise#109823
8 changes
Resolved issues and error corrections
This update ensures the sample dashboards within Odoo Enterprise accurately reflect the latest changes to the core dashboard functionality. These updated dashboards provide more current and relevant data for users exploring the system's capabilities. This is a routine maintenance fix.
Original PR description
This commit updates the sample dashboards to reflect the recent changes made in the dashboards. Task: 5076188
This update fixes a misleading chart in the Odoo dashboard. The pie chart previously incorrectly suggested supplier dependency, when it actually displayed purchase orders by buyer. The title has been corrected to accurately reflect the chart's data, ensuring users receive correct insights into their purchasing activity.
Original PR description
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it…
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it suggests that the chart represents dependency on each supplier. However, the chart actually shows how many purchase orders are created by each buyer. Additionally, when there are no purchase orders, the sample pie chart displayed uses the title `Purchase Order by Buyer`, which creates inconsistency between the actual chart title and the sample chart title. Steps to Reproduce: ================= - Install the **purchase_stock** module with demo data. - Go to the **Dashboard** app. - Open the **Purchase & Vendor Analysis under the Logistics** section. - Scroll down to locate the pie chart titled **Supplier Dependency Chart**. Cause of the Issue: ================ In this [PR](https://github.com/odoo/enterprise/pull/93921), at [this line](https://github.com/odoo/enterprise/pull/93921/changes#diff-61d19b77200011a8808542c134a675631e6d4b4dbc88ca99353cacfe3448b396), The pie chart title was incorrectly set to `Supplier Dependency Chart`, which does not reflect the underlying data, as the chart displays purchase orders grouped by buyer. After This Commit: ================ The pie chart title is corrected from `Supplier Dependency Chart` to `Purchase Order by Buyer`, ensuring it accurately repersent the underlying data and avoids misleading users. TaskID-5891759
This update fixes an issue where the filter for unfinished workorders would disappear after marking an operation as complete. The fix prevents the filter from being erased during the validation process, ensuring users can accurately track remaining operations. This improves the usability of the shopfloor operations module.
Original PR description
While working on a workorder from the shopfloor, if there is several operation when closing the first one, the filter will disapear Steps to reproduce: ------------------- * Create a Product * Create a BoM for that product with two operation * Create a MO for this product * Click on the smart button "Shop Floor" * Open the Operations * Mark as Done one of the operation -> the filter disappears Observation: ------------- When cliking on "mark as done" or "closing production" both goes through validate(), At the end of this function the filter is erased: https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L384 opw-5959166
This update corrects a technical issue preventing accurate recording of super payments in the Australian HR Payroll module. By initializing an error message to an empty string, the system now correctly handles payment registration, ensuring data integrity. Associated tests have been added to verify the fix.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444
This update resolves a technical error that prevented label printing when validating receipts through the barcode app. The fix utilizes an optional operator to handle situations where receipt data isn't available, ensuring the label printing function now works correctly and reliably.
Original PR description
Given a printer is configured to print a label for product receipts, when the receipt is validated from the barcode app, then a traceback appears. A filter on action.context.active_ids was introduced in https://github.com/odoo/enterprise/pull/106277. When validating the receipt from the purchase app, active_ids is set to the id of the purchase order and the behavior is as expected. When validating the receipt in the barcode app , it is not set (nor was it set in 17.0). The filter therefore crashes because it cannot work on undefined. An optional chaining operator is added to apply the filter only if active_ids is set. The barcode app does not raise a traceback anymore when validating a receipt and the label can be printed.
This update resolves an issue preventing the download of Intrastat reports for languages that use commas as decimal separators. The fix addresses a previous error where simply converting strings to numbers wasn't sufficient, and also handles cases with missing product weights. A more informative error message has been added for improved troubleshooting.
Original PR description
Before this commit, in 19.0+, languages that use commas instead of periods for decimals could not download the intrastat report. Simply attempting to change a string to a float was not enough. Also, when a product had a NoneType weight assigned to it another trace back would occur. This also adds a more descriptive and helpful error message. opw-6026730
This update resolves an issue where users couldn't validate delivery orders through the 'To Pickup' button. The fix removes a technical restriction that prevented the form view from opening, now enabling users to correctly process and validate delivery orders within the industry_fsm_stock module.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303
This update dramatically speeds up the generation of the Swedish SIE4 verification export, particularly for large datasets of journal entries. The change optimizes the data processing method to avoid memory issues and crashes, resulting in significantly faster execution times.
Original PR description
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999
13 changes
Resolved issues and error corrections
This update ensures that the expiration date from a GS1 barcode on a packaging is correctly applied when creating a new lot in Odoo. Previously, the system ignored this date, leading to inaccurate inventory tracking. This fix improves data accuracy and helps manage product shelf life effectively.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489This update resolves an issue where the click and collect widget didn't correctly display rental product availability. The fix ensures that rental periods are properly accounted for when calculating available quantities on the website, improving the rental experience for customers. This change impacts the website's shopping functionality.
Original PR description
Click and collect widget is not supported for rental products Steps to reproduce: ------------------- * Enable "Click and collect" in setting and set up warehouses * Create a rental product * Add a…
Click and collect widget is not supported for rental products Steps to reproduce: ------------------- * Enable "Click and collect" in setting and set up warehouses * Create a rental product * Add a unit of the product in one of the warehouses * Rent that product for a period * Go on the website>shop>the product * The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page Observation: ------------- The implementation of click and collect does not include a sale_renting module, this entails that [click and collect](https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36) and [openLocationSelector](https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54) don't have any information about the rental periode The rental date range is shown when the product is possible to rent and the rental period is only set in the xml file: https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90 Since openLocationSelector don't have access to the rental period, it can't update the necessary information to work with rental products. For example, the free_qty should change depending on the rental period. opw-5365564
This update fixes an issue where the lot number was not correctly displayed in rental incoming stock movements. The fix ensures that the correct lot name is shown, improving the accuracy of rental tracking and reporting. This resolves a previous bug impacting rental order management.
Original PR description
### Issue Lot name is shown empty in rental incoming move. #### To reproduce: 1- Create a rental product tracked by lot and add a quantity with lot number. 2- Create a rental order with the created product and confirm it. 3- Validate the outgoing transfer. 4- In the incoming transfer, open stock move using the small button(the button with 4 vertical lines). 5- As you see Lot/Serial Number is shown empty. ### Cause: This is because `lot_name` is not reflecting the `lot_id.name`. Even though `lot_id` is set, we are showing the `lot_name` on return move due to: https://github.com/odoo/odoo/blob/edc56ff496059c8d38557227699d52e2034619b2/addons/stock/views/stock_move_views.xml#L192-L203 We could fix that by setting `lot_name` in rental move lines vals. opw-5435865
This update resolves an issue where Swiss bank account details were incorrectly formatted in outgoing payment XML files, leading to rejection by banks like UBS. The fix ensures all IBAN creditor accounts are consistently formatted with the `<IBAN>` tag, aligning with Swiss ISO20022 standards and preventing payment processing errors.
Original PR description
**Steps to reproduce:** * install `account_iso20022` and `l10n_ch`. * Set Swiss ISO20022 in outbound payments in the Bank journal. * Create two vendor payments: one with a Swiss QR_iban bank account…
**Steps to reproduce:** * install `account_iso20022` and `l10n_ch`. * Set Swiss ISO20022 in outbound payments in the Bank journal. * Create two vendor payments: one with a Swiss QR_iban bank account (CH...) and one with a foreign bank account (DE...). * Group them into a batch payment and download the XML. **Observed behavior:** * Swiss IBAN creditor accounts are rendered as `<CdtrAcct><Id><Othr><Id>` instead of `<CdtrAcct><Id><IBAN>`. * Foreign IBAN creditor accounts (e.g. DE) correctly use `<IBAN>`. * UBS and other Swiss banks reject the XML file due to the inconsistency. **Cause:** * `_get_CdtrAcct()` delegates to `_is_bank_account_qr_iban()` to decide between `<IBAN>` and `<Othr><Id>`. * Swiss IBANs with an IID in the range 30000–31999 are classified as QR-IBANs, causing them to fall into the `<Othr><Id>` path even when they are standard IBAN accounts eligible for the `<IBAN>` tag. **Fix:** * Override `_get_CdtrAcct()` in the Swiss ISO20022 journal model to always emit `<CdtrAcct><Id><IBAN>` for any IBAN-type account when `payment_method_code == 'iso20022_ch'`, regardless of QR-IBAN classification. * Non-IBAN accounts (e.g. postal accounts) still fall through to the base implementation using `<Othr><Id>`. Ref: https://www.bib.eu/uploads/2020/04/Payment_import.pdf opw-6061266
This update resolves a crash issue that occurred when opening Gantt charts on days with Daylight Saving Time transitions. Specifically, the change addresses a calculation error related to time zones, preventing the Gantt view from freezing during these transitions. This ensures a more stable and reliable experience for users.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view.
This update resolves a bug where only the last employee to clock in at a Point of Sale (PoS) session was successfully recorded. Previously, multiple employees attempting to clock in simultaneously would result in errors. This fix ensures all employees are correctly clocked in, improving PoS session management.
Original PR description
If you have multiple employee trying to clock in at the same time in a PoS session, only the last one will actually be clocked in. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Activate the multi employee on the PoS * Open the PoS with employee A * Open the PoS on another device/browser with employee B * Try to add a product with employee A > Observation: You get an error saying you are not clocked in Why the fix: ------------ The `employees_clocked_ids` was used as a list of ids and not a list of employees/user. But when a session synchronisation was triggered the `employees_clocked_ids` would become a list of employee/user instead of a list of ids. This would cause `checkIfUserClocked` to fail because it was comparing employee object with ids. opw-6034985
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team the helpdesk was associated with. Now, the website only shows articles linked to the specific helpdesk team or its related teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#109361
This update corrects a display issue where appointment booking descriptions were showing in the user's language instead of the website's language. The fix ensures that appointment booking details are consistently presented in the website's specified language (e.g., French), improving the user experience across different language settings. This resolves a discrepancy in how date/time information is displayed during the booking process.
Original PR description
When booking an appointment, the cart shows the date/time in the partner's language instead of the website's language. `_prepare_order_line_values` uses `self.partner_id.lang`, ignoring the website language and using the user's language instead. Steps to reproduce: 1. Have a website language different than the user's language 2. Go to the website appointment page 3. Book an appointment 4. Check the booking For this case: - Website language: French - User language: English => You will find, "xxx at xx:xx to yyy at yy:yy" instead of "xxx à xx:xx au yyy à yy:yy" Ticket [link](https://www.odoo.com/odoo/action-4043/5931610) opw-5931610
This update corrects a technical issue that prevented users from editing the Amazon fulfillment channel within the Odoo Enterprise system. The fix ensures the channel is displayed correctly and allows for necessary adjustments to be made. This improves operational efficiency for sales teams managing Amazon orders.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#112866
This update fixes a problem where sale orders with SEZ GST treatment incorrectly assigned an 'Export' fiscal position instead of the correct 'Foreign State' position. The change ensures that sale orders with SEZ partners accurately reflect their international trade status, improving tax reporting and compliance. This resolves a previous error impacting sales to SEZ regions.
Original PR description
Before this commit: When creating a sale order, if the GST Treatment of partner is SEZ, then the Fiscal position is set as Export instead of SEZ. Reason: The default `foreign_state` obtained currently is searched on base of state whose country is not India, so any random state is fetched. But in the fiscal position of SEZ, we want "Foreign State", so while selecting fiscal position from `_get_fiscal_position` method, the Export fiscal gets higher ranking and gets selected. This commit fixes this issue by returning the correct Foreign State if fiscal position is set to SEZ. task-5958903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the total sales figures for events using foreign currencies were incorrect. The code has been updated to accurately convert sale prices from the event's currency to the company's currency, ensuring accurate reporting of event sales totals. This improves financial accuracy for event sales transactions.
Original PR description
Steps to reproduce: 1. Create a currency with a non-1 exchange rate with the company's currency (e.g. VEF with a rate of 0.000005 against USD). 2. Create a pricelist in that currency. 3. Create an…
Steps to reproduce: 1. Create a currency with a non-1 exchange rate with the company's currency (e.g. VEF with a rate of 0.000005 against USD). 2. Create a pricelist in that currency. 3. Create an event. 4. Create a sale order with the new pricelist. 5. Add a sale order line with a ticket of the event and confirm the order. 6. Go to the event's page and check the total sales smart button. 7. Check the total sales of the event: it should be equal to the sale order's total price converted to the company's currency, but it is not, because of the wrong conversion (it used the inverse of the correct exchange rate, which is 200000 instead of 0.000005 in our example). Problem: The total sales smart button in an event's page shows wrong totals when sales are in a currency other than the company's currency. Cause: The code converts the sale price from the event's currency (which is the same as the company's currency) to each sale order's currency, while it should be the other way around (from each sale order's currency to the event's currency). https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38 opw-5494790
This change moves the user alert information box from within the user form to outside the form. This improves the user experience by providing a clearer and more prominent display of important alerts, without cluttering the main form interface.
Original PR description
Before this commit: The user alert info box was visible inside the form. After this commit: The user alert info box is now displayed outside the form. Task-4478532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where increasing the quantity of a service product on a sales order incorrectly generated a purchase order with an inflated quantity. The fix ensures the quantity is always calculated in the sales order's unit of measure, preventing double-counting and inaccurate purchase order generation. This improves the reliability of sales order processing for service products.
Original PR description
Steps to reproduce the bug: - Create a service product "P1": - In the Purchase tab: - Vendor: Azure Interior - Subcontract Service: True - UoM: dozen - Purchase UoM: unit - Create a sales order with…
Steps to reproduce the bug:
- Create a service product "P1":
- In the Purchase tab:
- Vendor: Azure Interior
- Subcontract Service: True
- UoM: dozen
- Purchase UoM: unit
- Create a sales order with 1 dozen of P1
- Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
- Update the quantity from 1 to 2 dozen
Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186
Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178
opw-6049106
Forward-Port-Of: odoo/odoo#2554787 changes
Resolved issues and error corrections
A recent issue prevented users from deleting timesheet records when a confirmation dialog was open. This was caused by the timer's key handler incorrectly responding to the Enter key. This update corrects this behavior, ensuring that the delete confirmation dialog functions as expected.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig
This update corrects a bug that prevented users from editing the Amazon fulfillment channel in the Odoo Enterprise system. The issue was due to a read-only display widget. Now, the channel is correctly editable, allowing for accurate management of Amazon sales fulfillment.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended.
This update addresses an issue where delivery confirmations were failing due to missing tracking data from Easypost. The fix prevents errors when the 'tracker' object is null, ensuring picking validation and correct carrier tracking URLs. Easypost support suggested a slight delay between order placement and data retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415
This update resolves a crash that occurred when users attempted to download both spreadsheets and other documents from URLs within Odoo Enterprise. The fix ensures a smoother and more reliable download process for spreadsheet files, improving user experience.
Original PR description
Try to download a url document along with a spreadsheet. `onDownload` crash when trying to download a url document. Task: 5485662
This update fixes an issue where search filters in the MRP Planning view would reset when users navigated away and returned. The fix ensures that search filters are retained, providing a more consistent and efficient user experience for planning and analysis. This improves usability and data accuracy.
Original PR description
Issue: In the MPS view, when the user sets a search filter, navigates away and then returns via the breadcrumb, the search filters that were applied are gone. This happened because the MPS client action was not passing `globalState` to the `WithSearch` component. Fix by passing `globalState` in `withSearchProps`. task-5368078
This update resolves an issue where negative values in the Mod 390 tax report were not being properly marked with the 'N' indicator, as required by Spanish tax regulations. The fix adds a necessary parameter to ensure accurate reporting and compliance with official documentation, preventing potential discrepancies with the Agencia Tributaria.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706
This update corrects a flaw in how the digest KPI for connected users is calculated. Previously, it only considered a user's default company, leading to inaccurate counts. Now, the KPI correctly accounts for users working across multiple companies, providing a more reliable measure of user engagement.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940