Daily updates from Odoo
Wednesday, April 8, 2026
29 changes · master
Enhancements to existing features
This update streamlines payroll reporting by tracking and saving deadline dates for key reports. This prevents payroll officers from missing critical submission deadlines, improving accuracy and compliance. The changes include a new system for managing report deadlines and automated recalculations.
Original PR description
Purpose: - A lot of "reports" must be done and submitted monthly, quarterly, yearly... For a payroll officer it can quickly become a mess and he can quickly miss a deadline. - We need the date of warnings to be saved when it should be displayed in order to be able to display it in the Databases application in another database. Current behavior: - Added a field on the warning to store the deadline - Added more ways for warning date computation - Added a scheduled action to recompute warning deadlines - Added warnings for belgian reports (dmfa, 281.xx, 274.xx, 273s) task-id: 5909165
This update improves the accuracy of financial reports for Chinese businesses within Odoo Enterprise. Specifically, the formulas used to categorize assets in balance sheet and profit & loss reports (ASBE & ASSBE) have been revised to align with Chinese accounting standards. This ensures more reliable reporting for our Chinese customers.
Original PR description
- update "account_codes_formula" for assets in ASBE & ASSBE reports [5985488]
This update enhances the Belgian payroll settings within Odoo Enterprise, specifically adding new configurations related to Belgian tax regulations (ONSS, insurance). The changes improve data accuracy and compliance with local requirements, streamlining payroll processing for Belgian companies.
Original PR description
- Remove Benefits and Employee Configuration settings blocks - Add ONSS, Company Information, Accident Insurance, Cash Register, Hospital Insurance and Ambulatory Insurance settings to the Belgian Localization block - Display FFE field as radio buttons instead of a dropdown - Add `l10n_be_has_cp302_employees` and `l10n_be_pos_blackbox_installed` computed fields on res.config.settings - Restrict Cash Register setting visibility to companies with CP302 employees - Make Cash Register fields read-only when pos_blackbox_be is installed task-5979696
This update to Odoo Studio allows users to easily configure lazy-loaded search filters directly within the editor interface. Previously, this required manual XML changes. This simplifies the process of creating dynamic search views, improving user efficiency and flexibility.
Original PR description
This commit exposes the newly introduced lazy-loaded search filters to the Studio interface. When editing a search view, users can now configure the `values` attribute for filters based on `selection`, `many2one`, or `many2many` fields directly from the Studio properties sidebar. This allows users to easily enable dynamic, lazy-loaded filter options without needing to modify the XML manually. task-6047969
This update enhances the automated testing process for leave requests created by officers within Odoo. By adapting the tests, we ensure greater accuracy and reliability in verifying leave calculations and reporting across various payroll modules. This improves data integrity and reduces the risk of errors related to leave management.
Original PR description
Adjusting tests for the implemented changes in https://github.com/odoo/odoo/pull/250142 task-5952413
This update introduces group-based access control for documents, making it easier to manage permissions. Users are now added to groups, and their permissions are automatically applied, streamlining access management. Existing individual permissions will still apply if a user has them, ensuring a layered approach to security.
Original PR description
### PURPOSE
Add group support for documents sharing to ease access management. It will now
be easier to add users to an already existing scheme of permissions... you'll
only have to add the users to the group and that's all.
Here are several things to know with this change:
- If a user belongs to multiple groups or has individual rights on a document,
their final permission will be the highest level granted by any of those
sources.
- When adding permission to a group, all users belonging to this group will
be notified. Users added later to the group won't be notified.
### TECHNICAL
A new model has been created to handle these groups: 'res.group.functional'
which contains 'res.users'. It also has some responsible users to avoid being
updated/deleted by everyone.
Task-5122979This update adjusts how the 13th month payment is calculated for sales representatives. It ensures the payment never falls below the minimum salary for their category based on seniority, aligning with legal requirements. This change improves payroll accuracy and compliance for this specific employee group.
Original PR description
The 13th month is computed based on fixed wage and the average of variable salaries but for Sales representatives there is a limit which is the maximum between: - the fixed salary of the employee - the minimum salary of the category D based on seniority task-6072379
Resolved issues and error corrections
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 Orders 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 Orders by Buyer`, ensuring it accurately repersent the underlying data and avoids misleading users. TaskID-5891759 Forward-Port-Of: odoo/enterprise#110434
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which helpdesk team was viewing them. Now, the website only shows articles linked to the specific team or its associated 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#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a crash in the Gantt chart view that occurred when opening the chart on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, preventing users from accessing the Gantt chart. This ensures the Gantt chart remains stable across different time zones.
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. Forward-Port-Of: odoo/enterprise#112840
This update fixes misleading low wage warnings in Odoo's Belgian payroll module (l10n_be_hr_payroll). Previously, warnings appeared regardless of contract start dates, causing confusion. Now, warnings only appear if the contract starts in the past or if the wage is zero and the contract starts in the future, ensuring accurate and relevant alerts for HR users.
Original PR description
Before this change, if you created an employee from scratch in a belgian company with l10n_be_hr_payroll installed, you would automatically get a warning saying that you were below minumum wage. This would happen even if there was no contract defined on the version which doesn't make sense. Here, we add the showing condition that the contract date start on the version should be in the past. Another warning that was showing inappropriately is the one saying that the annual salary is below a certain amount and to add transport benefits. This was, for example, showing even if the contract was starting in the future. The new conditions are: - If contract starts in the future and the wage is 0 we don't show it. - If the contract starts in the future, the wage is != 0 but still insufficient, we show. - If the contract starts in the past, we show even if the wage is 0. Task: 6064262
This update restores the previous template structure used in the M3 project, incorporating necessary adaptations. It addresses a technical issue related to existing code and ensures compatibility with current functionality. This change focuses on stability and aligns with previous design standards.
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 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 the required Swiss banking standards, specifically the pain.001.001.09 format, improving payment processing accuracy and compliance. It also includes enhancements for validator schema and QR-IBAN handling.
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#112526 Forward-Port-Of: odoo/enterprise#107025
A bug was preventing users with access rights from 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 and ensures proper functionality.
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…
## 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#110022 Forward-Port-Of: odoo/enterprise#108331
This update fixes an issue related to how dates and times are displayed in Odoo. The system now correctly shows seconds when requested, and previously hidden formatting options have been removed to avoid confusion. This ensures consistent and accurate time representation across the application.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This pull request addresses a small typographical error within the l10n_be_hr_payroll module. The fix ensures accurate calculations related to employee payroll in Belgium. This update improves the overall reliability of the payroll processing system.
Original PR description
typo in https://github.com/odoo/enterprise/pull/113076
This update improves the Master Production Schedule (MPS) by accurately incorporating safety stock levels for indirect demand. Previously, the system didn't properly account for this, leading to inaccurate demand forecasts. This change ensures more reliable production planning and reduces the risk of stockouts.
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#113023 Forward-Port-Of: odoo/enterprise#107671
This update resolves an issue where the system incorrectly identified employees without a recorded check-in time as eligible for late hours calculations. The fix ensures that records without a check-in are excluded from late hours visibility, preventing errors and ensuring accurate reporting. This improves the reliability of late hours tracking.
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 Forward-Port-Of: odoo/enterprise#111935
This update resolves a potential error in the l10n_hk_hsbcnet module that could have prevented correct assignment of HSBC bank accounts for autopay. The change adds a check for valid account numbers before assigning sanitized account numbers, ensuring accurate processing of financial data. This improves the reliability of HSBC bank integration.
Original PR description
. Add account_number check before assign sanitized_account_number task-6049640 Forward-Port-Of: odoo/enterprise#112864
This update resolves an issue where users couldn't complete the delivery order validation process when using the 'To Pickup' button. The fix allows users to open the necessary form view directly from the list, ensuring accurate order tracking and fulfillment. This improves the efficiency of the pickup process.
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 Forward-Port-Of: odoo/enterprise#110125
This update ensures that when scanning barcodes in batches, the correct lot is always used, regardless of the initial barcode serial number. Previously, the system incorrectly defaulted to the reserved serial number, leading to inaccurate inventory tracking. This fix guarantees accurate lot updates during batch processing.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112528
Forward-Port-Of: odoo/enterprise#109671This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to paid time off. The change ensures accurate tracking and reporting of employee leave entitlements, aligning with Belgian labor regulations. This update improves payroll accuracy and compliance.
Original PR description
Update belgium paid time off calculation method and related tests. Task-6064503
This update resolves an issue where intercompany purchase orders with 'never' product variants were failing to include the correct components in the subsequent manufacturing order. The fix ensures that the variant information is properly retrieved from the purchase order, allowing for accurate production planning in the intercompany setting.
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#113031
Forward-Port-Of: odoo/enterprise#107122This update resolves an issue related to payroll calculations by ensuring the 'Company Executive' (CP999) category is correctly included in all employer categories. This correction addresses a previous error and ensures accurate payroll processing for businesses using the Odoo Enterprise module.
Original PR description
In this commit, we fixed the issue introduced in allowed JC by employer category, by including the CP999 (company executive) in all employer categories. task-6105431
This update resolves an issue where Italian tax returns weren't automatically marked as 'green' due to a technical dependency. The fix removes a specific keyword ('new') that was causing this behavior, ensuring Italian tax reports are correctly validated and displayed. This improves the accuracy of tax reporting for Italian businesses.
Original PR description
Due to this PR: https://github.com/odoo/enterprise/pull/103149 the tax return on italian l10n is automatically all greened out as the compute_visible_states depends on the 'new' keyword which was removed in the forementionned PR. This fix refacotrs the _compute_record_states_for_it to remove its dependancy on the 'new' keyword. Currently now 'new' keyword exists on the states of the return and the default state is False. task: 6106083
This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's column width expands too much, causing text to shrink and creating unsightly gaps. The fix adds a CSS class to manage the column width, resulting in a cleaner and more professional report layout.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update resolves an issue preventing the download of Intrastat reports for languages that use commas instead of periods as decimal separators. The fix also addresses a previous error related to product weights, improving the overall stability and reliability of the Intrastat reporting process. A more informative error message has been added for better 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 Forward-Port-Of: odoo/enterprise#112627
This update fixes how default customer partners are assigned when creating orders in our point-of-sale system. Previously, each localized version of the system handled this separately. Now, the system uses a central method to determine the default partner, ensuring consistency across all locations and reducing potential errors.
Original PR description
Replace the `createNewOrder()` override with `getDefaultPartnerId()` in l10n_cl_edi_pos, l10n_co_edi_pos, l10n_ec_edi_pos and l10n_gt_edi_pos. The default partner assignment is now handled centrally in `point_of_sale`'s `createNewOrder()`. opw-6077656 Forward-Port-Of: odoo/enterprise#112467
Code cleanup and technical improvements
This update standardizes the styling of the AI logo across Odoo by renaming the CSS class from `ai-logo-icon` to `oi-ai-logo`. This change improves the overall consistency and maintainability of the codebase, making future updates easier to manage.
Original PR description
*=ai,ai_knowledge,ai_website,test_discuss_full_enterprise Rename `ai-logo-icon` class to `oi-ai-logo` to follow Odoo icon naming conventions This change aligns the AI logo CSS class with the standard `oi-*` naming pattern used by Odoo icons, improving consistency and maintainability across the codebase.