Daily updates from Odoo
Tuesday, April 7, 2026
41 changes · saas-19.2
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#256415This update automatically checks out employees from attendance records when they are archived. Previously, archived employees remained checked in, which created inconsistencies. This change ensures accurate attendance tracking and simplifies the process of managing archived staff.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256083 Forward-Port-Of: odoo/odoo#255524
This update fixes several issues within the Odoo spreadsheet component, ensuring improved stability and functionality. It includes bug fixes related to date formatting, grid behavior, and error handling, enhancing the user experience. This update is part of the 19.2 release.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/cad5c61d12 [REL] 19.2.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/cad5c61d12 [REL] 19.2.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/964c1b6b61 [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/a58e378577 [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/3183db9d53 [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/2dbe2f6192 [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/245be692e2 [FIX] package: clean o-spreadsheet-engine leftovers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8490ed8d26 [REV] spreadsheet: remove o-spreadsheet-engine package [Task: 6081583](https://www.odoo.com/odoo/2328/tasks/6081583) https://github.com/odoo/o-spreadsheet/commit/af097c3738 [FIX] side panels: fix layout of panels with tabs [Task: 6022696](https://www.odoo.com/odoo/2328/tasks/6022696) https://github.com/odoo/o-spreadsheet/commit/626368f758 [IMP] Errors: Add error origin position for #SPILL errors [Task: 5959985](https://www.odoo.com/odoo/2328/tasks/5959985) https://github.com/odoo/o-spreadsheet/commit/0beafbe5fe [FIX] config: move to ESM release tool [Task: sotg](https://www.odoo.com/odoo/2328/tasks/sotg) https://github.com/odoo/o-spreadsheet/commit/51dce8ceb4 [FIX] DV: Allow use of cellPosition-related functions in rules [Task: 5868662](https://www.odoo.com/odoo/2328/tasks/5868662) https://github.com/odoo/o-spreadsheet/commit/22a7de630a [FIX] CF: Allow use of cell position-related functions in formula [Task: 5868662](https://www.odoo.com/odoo/2328/tasks/5868662) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects an issue in the Slovakian VAT report generation, ensuring accurate reporting of financial data. The fix prevents duplicate information from being included in the XML report, resolving a potential discrepancy in tax calculations. This improves the reliability of financial reporting for Odoo users in Slovakia.
Original PR description
Add missing `sk_29.vat` in row 32 formula and ensure only one of the rows is filled: row 32 for positive amounts, row 33 for negative ones. This prevents both rows from being populated at the same time and fixes the generated XML accordingly. Related: https://github.com/odoo/enterprise/pull/112963 task-6040973 Forward-Port-Of: odoo/odoo#257528
This update corrects a bug where the system automatically adjusted dates on Czech tax documents that had already been processed. This was causing issues with accurate reporting related to late tax deductions, a common requirement in the Czech Republic. Now, users must manually adjust dates for posted documents to ensure correct accounting.
Original PR description
Description of the issue/feature this PR addresses: This automatic date alignment make sense in case of new document, but when you work on document that was posted. User should change it manually. In Czech republic we have something like late tax deduction and in this case there is not alignment of dates. Current behavior before PR: When you change taxable_supply_date it automatically change date Desired behavior after PR is merged: Disable this calculation od moves that hase been posted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257135
This update fixes an issue where a second resupply picking was being created when adding a component to a subcontracting order. The fix ensures that new components are correctly grouped with existing pickings, streamlining the inventory management process for subcontracted manufacturing. This prevents unnecessary stock movements and improves order accuracy.
Original PR description
Steps to reproduce: 1- Install Inventory, Purchase and Manufacturing 2- Enable 'multi-step routes' in the settings 3- Create Product A and create a Bill of Materials (BoM type: subcontracting,…
Steps to reproduce: 1- Install Inventory, Purchase and Manufacturing 2- Enable 'multi-step routes' in the settings 3- Create Product A and create a Bill of Materials (BoM type: subcontracting, Component A) 4- Repeat the same for Products [B,C] with components [B,C] correspondingly. 5- Assign the same subcontractor to all of them 6- Create a Purchase Order for both Product A and Product B with vendor as the subcontractor and confirm it 7- Add a new order line with Product C and save Description of issue: A second resupply picking is created Expected behavior: Should group the new product's component with the existing picking Why this happens: When assigning the resupply picking for the new product's component, the search domain for the existing picking includes production_group_id, which is different for the added product. This prevents merging of components into a single resupply picking despite sharing the same destination and purchase order Fix: We ignore production_group_id since it is not necessary in the resupply stock moves domain. opw-5906451 Forward-Port-Of: odoo/odoo#251713
This update fixes an issue where the cost of a sale order wasn't accurately calculated when using the dropshipping feature. The fix ensures that the cost reflects the purchase order price (e.g., $10) for dropshipped products, resolving a discrepancy where the cost was incorrectly displayed as $0. This improves the accuracy of financial reporting.
Original PR description
**Problem:** The cost is not correctly computed on sale order line when the product is dropshipped. **Steps to reproduce:** - enable "margins" and "dropshipping" settings - create a tracked, fifo…
**Problem:** The cost is not correctly computed on sale order line when the product is dropshipped. **Steps to reproduce:** - enable "margins" and "dropshipping" settings - create a tracked, fifo product with dropship route - add a vendor in the purchase tab - confirm a sale order for 1 unit - set a unit price of 10 in the PO and confirm it - validate the dropship picking - come back to the sale order and unhide de cost column **Current behavior:** the cost is 0 **Expected behavior:** the cost should be 10 based on the unit price of the PO **Cause of the issue:** To compute the purchase price, when there is valued moves linked to the sale order line and the product is fifo/avco, we call _get_price_unit() on the moves. https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/sale_stock_margin/models/sale_order_line.py#L21 Which uses the value of the moves https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/stock_move.py#L237-L243 But for dropshipped move the value on the moves is always 0. So the return value will be 0 and purchase price will be 0. **fix:** - The idea of the fix is to use _get_value() instead of the move value for dropship moves. This approach is already used in the code inside _run_average_batch() https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/product.py#L474-L475 - In case there is not only dropship moves we need to do a weighted average opw-6051004 Forward-Port-Of: odoo/odoo#256089
This update resolves a bug where adding captions to images with a 'display:block' style incorrectly removed surrounding text blocks. The fix ensures captions are added and displayed correctly, preventing multiple captions from being added to the same image and improving the overall image editing experience.
Original PR description
Steps to reproduce: - Go to To-do - Open a demo record (e.g., "Welcome Mitchell Admin") - Click on an image - Click on "Caption" from the toolbar - Click on the image again Description of the issue:…
Steps to reproduce: - Go to To-do - Open a demo record (e.g., "Welcome Mitchell Admin") - Click on an image - Click on "Caption" from the toolbar - Click on the image again Description of the issue: - When adding a caption, the parent paragraph block of sibling nodes is removed, making them direct children of the editable area. - After adding a caption, reopening the powerbox does not show the caption button as active, allowing multiple captions to be added on the same image. Cause: - When the image has `display:block`, `closestBlock` returns the image itself as its closest block. - As a result, when a caption is added to an image, its parent paragraph block is not split around the image even if the image has sibling nodes, and when `unwrapContents` is called, both the image and its siblings get unwrapped, making them direct children of the editable area. - Since `closestBlock` is the image (and not a `<figure>`), the caption button in the toolbar is not marked as active even when a caption already exists, so clicking it again adds another caption instead of removing the existing one. Solution: - Instead of using the image's `closestBlock` directly, find the `closestBlock` of its parent element. - This ensures the correct block is found even when the image has `display:block`. task-6051549 Forward-Port-Of: odoo/odoo#256436 Forward-Port-Of: odoo/odoo#255064
This update fixes a vulnerability in the email marketing editor where users could inadvertently create checklists using a shorthand command. The change prevents pasting checklist content, ensuring that checklist creation is fully disabled as intended and improving email marketing security.
Original PR description
In email marketing, checklist creation is disabled via powerbox, toolbar, and shortcut (Ctrl+Shift+9), but it can still be created using the shorthand command ('[] ').
Disable the checklist shorthand command to ensure checklist creation is fully restricted in email marketing.
task-6048027
Forward-Port-Of: odoo/odoo#257143
Forward-Port-Of: odoo/odoo#254816This update fixes an issue where the website header padding would disappear under certain background color conditions, causing visual inconsistencies. The change ensures the header boundaries are always visible, regardless of the page's background color or image, improving the overall website appearance and user experience. This resolves a minor visual bug.
Original PR description
Before this PR, the left/right padding of the header would be removed when the header had no background color or when its background color matches the pages color. In these cases, the header boundaries were not visible and so we allowed the header to take more space. However, the previous condition would not check if the page had a background image, or if the header had a shadow defined. The header would have visible boundaries and the element on the extremities would be stuck to the boundaries. This commit updates the condition to include any possible option that would make the header boundaries visible. task-5367502 Forward-Port-Of: odoo/odoo#244413
This update fixes alignment issues and removes distracting lines within the attendance system tray, improving its visual clarity. Additionally, it allows certain attendance components to retain the system tray open after check-in or check-out, providing greater flexibility for users. This addresses a previous usability concern.
Original PR description
# [FIX] hr_attendance: alignment This commits revamps the attendance systray by aligning items and removing horizontal lines between attendance entries. # [FIX] hr_attendance: allow not to close systray based on condition This commits allows components inheriting from the attendance menu to conditionally close the systray. By default, the dropdown will be closed on check-in and check-out to preserve the original behaviour. See odoo/enterprise#113189 task-6088779
This update resolves an issue where leave scheduling calculations were incorrectly skipping employee availability, leading to potential scheduling conflicts. The fix ensures that all employee work intervals are considered when determining the earliest available time for leave, resulting in more accurate and reliable leave scheduling. This improves the overall accuracy of the HR system.
Original PR description
Before this commit, in `_get_first_working_interval_batch` the `collect_employees` helper only inspected the first item of each employee's work interval. The batch calendar query starts from the global `min_dt` which is the earliest leave end across all employees in the batch. For an employee whose leave ends later, the first returned interval can therefore still fall before that employee's own threshold (`min_dts[employee_id]`). The old code would discard that interval and, since it never examined subsequent ones, silently skip the employee with no result. This commit fixes the issue by replacing the single-item check with a loop that iterates over all of the employee's intervals and picks the first start time strictly after `min_dts[employee_id]`. Forward-Port-Of: odoo/odoo#257310
This update fixes a potential inconsistency issue in the Point of Sale (POS) system. Previously, users could modify tax settings while a POS session was open, leading to discrepancies between receipts and invoices. Now, a safeguard prevents these changes, ensuring accurate financial reporting.
Original PR description
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in…
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in account_tax.py. After 18.0, the tax-included behavior is controlled through the `price_include_override` field instead of `price_include`. However, this field was not added in the forbidden fields, allowing users to modify tax inclusion while a POS session is open. This bypasses the safeguard and can lead to inconsistencies, as the POS caches tax configuration at session start. For example, changing this setting mid-session may differences between POS receipts and backend invoices. By adding `price_include_override` to the forbidden fields, the UserError can properly be raised. Additional note: test_fiscal_position_between_frontend_and_backend was updated to close the POS session before changing taxes since the safeguard now correctly blocks this. Related ticket: opw-6042367 Forward-Port-Of: odoo/odoo#257035 Forward-Port-Of: odoo/odoo#254487
This update fixes an issue where Chrome logs weren't reliably captured during shutdown, particularly when errors occurred. The changes also address Chrome's log buffering behavior and add resilience to Chrome shutdown attempts, ensuring more complete and accurate log data for troubleshooting.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256656 Forward-Port-Of: odoo/odoo#256061
This update corrects a bug where the 'Track Inventory' field was incorrectly displayed for service and combo products. The fix restores the intended restriction, ensuring this field only appears for products that can be physically stored (like goods).
Original PR description
Issue before this commit: ========================= The 'Track Inventory' (is_storable) field is visible for products of type service or combo, where it should not be applicable. Steps to Reproduce:…
Issue before this commit: ========================= The 'Track Inventory' (is_storable) field is visible for products of type service or combo, where it should not be applicable. Steps to Reproduce: ========================= - Install the Inventory module without demo data. - Ensure **'Lots & Serial Numbers'** is disabled in the configuration. - Go to Inventory > Products > Create a new product. - Change the product type from 'Goods' to 'Service' (or Combo). Result: The 'Track Inventory' field remains visible. Cause of the issue: ========================= The invisible condition on the field was unintentionally removed in this [PR](https://github.com/odoo/odoo/pull/242834), [here](https://github.com/odoo/odoo/pull/242834/changes#diff-9afa40fdafcf103e7456e139c259f78469ea7e675c79f6d13dfe7db2d43c38d6R188). Previously, it was restricted using: **invisible="type != 'consu'".** With This Commit: ========================= Restore the invisible condition on the 'is_storable' field, ensuring it is only visible for storable (goods) products and hidden for service and combo products.
This update resolves a visual problem in the website editor previews, specifically with the filmstrip layout. An undefined variable was causing placeholder rectangles to disappear, resulting in a broken design. The fix removes an unused template and ensures the correct styling is applied.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257029 Forward-Port-Of: odoo/odoo#255339
This update resolves an issue related to the way receipts are generated in Point of Sale. The change removes an outdated function used for image processing, ensuring better stability and compatibility with newer versions of Odoo. This improves the reliability of the receipt generation process.
Original PR description
This commit simplifies the qrcode generation and background color handling while removing reliance on deprecated (since v12.1.0) Pillow Image getdata() function. Reference: - https://pillow.readthedocs.io/en/stable/deprecations.html#image-getdata
This update resolves a bug where the bold formatting action wasn't consistently removing bolding from selected text, particularly when `/file` components were present. The fix ensures that bolding is correctly applied or removed based on editable text nodes, improving the functionality of the HTML editor.
Original PR description
When determining whether the "bold" action is about adding bold or removing bold, non-editable text nodes are also taken into account. Because of this, if the selection contains an embedded component such as `/file`, it always considers bold was not applied on all nodes, and should therefore be applied. The action thus never removes bold. This commit fixes this by only taking into account the editable nodes. Steps to reproduce: - Go to a "To do" note - Add a few lines of text - Add a `/file` in the middle - Select all - Press Ctrl+B: bold is applied on the surrounding text - Press Ctrl+B again => Bold was not removed from the surrounding text task-5955977 Forward-Port-Of: odoo/odoo#257550 Forward-Port-Of: odoo/odoo#249816
This update addresses a warning related to the Docutils library, a key component of our API documentation. The change ensures compatibility with a newer version of Docutils, preventing potential issues with our documentation generation process. This ensures our API documentation remains reliable and up-to-date.
Original PR description
Argument "writer_name" will be removed in Docutils 2.0. Specify writer name in the "writer" argument. Reference: - https://docutils.sourceforge.io/0.22/RELEASE-NOTES.html#writers Forward-Port-Of: odoo/odoo#257348
This update fixes an issue where a browser tab change 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 for complex product configurations.
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#257846
Forward-Port-Of: odoo/odoo#247797