Daily updates from Odoo
Navigate
Branch
Tuesday, April 7, 2026
187 changes
18 changes
New functionality added to Odoo
This update introduces the ability to export Slovak VAT reports in XML format, aligning with government regulations. This ensures accurate and compliant reporting for our Slovakian clients, simplifying the process of submitting VAT data to the tax authorities. It's a key improvement for meeting Slovakian tax requirements.
Original PR description
Add XML export for the Slovak VAT report, following the official government format Related: https://github.com/odoo/odoo/pull/257528 task-6040973 Forward-Port-Of: odoo/enterprise#112963
Enhancements to existing features
This update simplifies the process of upselling non-recurring products when the subscription start date aligns with the next invoice date. A technical adjustment was made to prevent errors related to zero prorata ratios, ensuring accurate invoicing and subscription confirmations. This change improves the reliability of the subscription upselling process.
Original PR description
Make easy for module that extend sale subscription to allow for some specific case to upsell subscription with start_date = next_invoice Forward-Port-Of: odoo/enterprise#112730
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
4 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.
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
13 changes
Enhancements to existing features
This update adds labels to cash basis journal entries to clearly identify the original documents that triggered them. This improves traceability and simplifies reconciliation processes within the accounting system. The change enhances clarity and auditability for financial reporting.
Original PR description
To have a more explicit reference from which documents a cash basis base line was created, now we put the name of the two journal entries that triggered the caba. target: 18.0 -> master Task [link](https://www.odoo.com/odoo/project.task/5883344) task-5883344 Forward-Port-Of: odoo/odoo#257019 Forward-Port-Of: odoo/odoo#246610
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
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
37 changes
New functionality added to Odoo
This update adds crucial data for Belgian payroll calculations by incorporating National Insurance (NIS) codes for both countries and cities. This ensures accurate reporting and compliance with Belgian regulations, improving the payroll system's functionality within the Enterprise module.
Original PR description
Add Nis code field to res.city model and add belgian cities data Add Nis code field to res.country model and complete countries nis code data Add countries and belgian cities view in the menu of payroll app. Documentation can be found here: - Countries: https://www.socialsecurity.be/portail/glossaires/dmfa.nsf/153f48bffb0bd3cac125686200574ff3/e3a58e3ddd17115ac1258b34002c5a61/$FILE/AN2023-1-FR5.pdf - Cities: https://statbel.fgov.be/sites/default/files/Over_Statbel_FR/Nomenclaturen/REFNIS_2025.csv Task-5979510
This update introduces core functionality for calculating Belgian payroll under the CP302 scheme. It includes features like seniority tracking, various work entry types with associated premiums, and specific wage reductions for students and work clothes allowances, aligning with Belgian regulations.
This update introduces the ability to generate an XML file for Slovak VAT reports, aligning with the specific requirements of the Slovak government. This ensures accurate and compliant reporting for our Slovakian clients, streamlining their VAT submission process. The change improves reporting capabilities and reduces potential errors.
Original PR description
Add XML export for the Slovak VAT report, following the official government format Related: https://github.com/odoo/odoo/pull/257528 task-6040973 Forward-Port-Of: odoo/enterprise#112963
This update allows businesses to track asset depreciation using different accounting ledgers, providing greater flexibility and accuracy in financial reporting. Previously, assets were limited to a single ledger, which is now expanded to accommodate diverse accounting needs and reporting requirements. This enhancement improves compliance and reporting capabilities.
Original PR description
This commit adds the ability to depreciate assets with multiple depreciation models on different ledgers. task-5961309
This update enables e-invoicing for online orders in Guatemala, ensuring compliance with local regulations. It automatically includes company issuer phrases on invoices and allows customers to select their Guatemalan identification type (NIT, CUI) at checkout. The system now generates personalized DTEs when a NIT/CUI is provided and issues standard invoices for Consumer Final purchases.
Original PR description
**PURPOSE** - Ensure invoices generated from website orders include issuer phrases and Support Guatemalan identification requirements for e-commerce. **SPECIFICATION** - Reuse backend phrase logic so website-generated invoices include company issuer phrases. - Add ID type selection (NIT, CUI, etc.) in the checkout. - If NIT/CUI is provided, issue a personalized DTE. - If empty or 'CF', issue the invoice to the Consumidor Final. task-4393611
Enhancements to existing features
This update clarifies the display of room bookings that span multiple days, making it easier for users to understand the booking duration. Previously, bookings were only shown on the start date, which could be confusing. Now, the booking shows both dates involved, preventing potential issues with editing and ensuring clarity.
Original PR description
Purpose ======= Improve the display of the bookings spanning over multiple days in the room booking sidebar. Specification ============= Currently bookings spanning over multiple days are displayed on their start date. Example: a booking starting on the 1st of January at 2PM and ending on the 2nd of January at 4PM will be displayed: Monday, January 1, 2026 2PM -> 4PM It can be really confusing for users. Improving the display to make it more explicit: Monday, January 1, 2026 - Tuesday, January 2, 2026 2PM -> 4PM Choosing to display the 2 dates instead of spliting the booking into 2 cards (like January 1, 2PM -> Midnight and January 2, Midnight -> 4PM) to make sure users understand it's one single booking and prevent introducing strange behavior when editing the booking start or end (i.e. disappearing cards). Task-5959555
This update improves the spreadsheet edition by introducing dynamic list functions, allowing for more flexible data manipulation within lists. The changes include renaming a key function and generalizing a component for reuse across various spreadsheet data sources, ultimately enhancing user productivity and data analysis capabilities.
This update makes it easier to upsell non-recurring products when the subscription start date aligns with the next invoice date. The change improves the process by separating constraint logic, allowing for greater flexibility and preventing potential errors related to zero prorata ratios during the upsell confirmation.
Original PR description
Make easy for module that extend sale subscription to allow for some specific case to upsell subscription with start_date = next_invoice Forward-Port-Of: odoo/enterprise#112730
This update enhances the payslip search functionality by allowing users to group results by employee type. The search view has been reorganized with a new 'Employee Type' filter and a refined layout for better usability. This change improves reporting and data analysis related to payroll.
Original PR description
Add `employee_type_id` as a stored related field on `hr.payslip` (via `version_id.employee_type_id`) to enable grouping by employee type. Update the payslip search view group by section: - Add "Employee Type" group by filter - Remove "Employee Record" (version_id) group by filter - Rename "Status" to "Payslip Status" - Reorder: Pay Run, Employee, Employee Type, Structure, Payslip Status, Department, Job Position, Company task-6071102
This update enhances the Discuss chat view by displaying the meeting status of participants, indicating if they are currently in a busy or accepted calendar event. This provides clearer context during conversations and helps users understand scheduling availability. Only busy and accepted calendar events are now considered.
Original PR description
Before Changes: - No meeting status was shown in discuss conversations. - Users could not see if the other participant was currently in a meeting. After Changes: - Show 'In a meeting until <time>' with calendar icon in chat view. - Only busy and accepted events are considered. - Private/Confidential and all-day events are ignored. task-3368725
This update enhances the mobile experience by allowing users to quickly access the command palette directly from the home menu. Previously hidden, the search input is now revealed with a swipe, providing a more intuitive and efficient way to find commands on touch devices. This improves usability and productivity for mobile users.
Original PR description
*: web_studio This commit introduces a native-feeling interaction to open the command palette from the home menu on mobile devices. The home menu's search input, which is normally visually hidden, is now rendered on mobile devices but initially hidden underneath the navbar using a scroll offset. Users can intuitively swipe down to reveal the input and tap it to instantly open the command palette. task-5966849
This update simplifies database access management for users within Odoo. Now, a list of databases a user has access to is readily available within the user's profile, eliminating the previous manual search process. This improves efficiency and control over user permissions.
Original PR description
The aim of this commit is to allow db_manager to see the list of databases in which a specific user has access and to allow removing this access in bulk if required. Before this commit: To see the list of db in which a user has access, a db_manager would have to go to the list view and make a search on the login/name of the user, potentially matching other db_user in the process. After this commit: The list of db is available out of the box in a databases tab on the res.user view. Task-id: 5945298 Forward-Port-Of: odoo/enterprise#112645
This update enhances the security and logging around exporting large amounts of data from Odoo spreadsheets. Specifically, it adds logging for common export actions like downloading and printing, and restricts access to frozen/XLSX downloads to authorized users. This improves data tracking and protects sensitive information.
Original PR description
Forward-Port-Of: odoo/enterprise#111405 Forward-Port-Of: odoo/enterprise#85888
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
Code cleanup and technical improvements
This update streamlines the code for Odoo charts by separating the data handling logic from the common chart elements (like titles and axes). This reduces redundancy and makes future chart updates easier and more efficient, improving maintainability.
This update optimizes how Odoo retrieves information about knowledge articles. The change involves clearing a temporary cache, which improves the speed and responsiveness of accessing these articles for users. This results in a smoother user experience and faster access to important documentation.
Original PR description
https://github.com/odoo/odoo/pull/257771
This update streamlines chart creation by separating data management from chart-specific design and generation. By extracting common code, the team reduces redundancy and simplifies future chart development, leading to faster updates and improved maintainability.
Original PR description
The current problem with charts ------------------------------- All chart types (bar, line, pie, etc.) have quite a lot of code in common: mainly to manage ranges (adapt, copy, duplicate sheet, etc.) Odoo charts also brings a bunch of duplicated code: the data part is not, but all the other parts of the code is duplicated, like for design (title, legend, axes, etc.), runtime generation. Much of the code for an odoo bar chart is exactly the same as for a range-based bar chart (except to get the data). Lots of duplicated code is already factorized in helper functions, but the boilerplate remains important and not all code is factorized. When we add a new feature to charts, we usually need to change both o-spreadsheet and odoo. With this refactoring, we extract the data part from all the rest: the data management is specific to each data source (odoo vs range), the rest is specific to the chart type and is agnostic of the data source. Task: 6036223
This update streamlines the website search functionality across multiple Odoo modules (appointment, helpdesk, etc.) by reorganizing how search results are presented. This change improves search speed and efficiency, providing a better user experience for finding information within Odoo.
Original PR description
*: appointment, helpdesk, helpdesk_forum, helpdesk_knowledge, knowledge, sale_renting, sale_subscription This commit refactors the website search across all entry points (header search, snippets, and per-model search) by replacing the previous flat result list with a grouped, model-based architecture. task-5264317 Community: https://github.com/odoo/odoo/pull/238317 Upgrade: https://github.com/odoo/upgrade/pull/9161 Co-authored-by: Divyesh Vyas <divy@odoo.com> Co-authored-by: dtda-odoo <dtda@odoo.com> Co-authored-by: mano-odoo <mano@odoo.com>
10 changes
Enhancements to existing features
This update adds the ability to automatically upload Odoo invoices to FedEx, ensuring accurate export documentation and matching accounting records. It also introduces enhanced shipment tracking with customizable PO numbers, customer references, and invoice numbers for improved visibility. These features are optional and maintain compatibility with existing FedEx shipping configurations.
Original PR description
Add two new configurable options to the FedEx shipping integration: 1. ETD with Odoo Invoice (new documentation_type option): New 'ETD with Odoo Invoice' option in the Generate Invoice setting. When…
Add two new configurable options to the FedEx shipping integration: 1. ETD with Odoo Invoice (new documentation_type option): New 'ETD with Odoo Invoice' option in the Generate Invoice setting. When selected, the module uploads the Odoo-generated invoice PDF to FedEx Documents API (encodedmultiupload endpoint) and references it in the shipment request as an ETD attached document. This replaces the FedEx-generated commercial invoice with the actual Odoo invoice, ensuring export documents match accounting records. Requires a posted invoice on the SO before shipping. Note: FedEx Documents API uses a different base URL (documentapi.prod.fedex.com) than the Ship API. 2. Enhanced References (new Boolean field): When enabled, shipment package references include up to 3 fields: - PO Number: Customer Reference from SO (client_order_ref), or SO number if not set - Customer Reference: SO number - Invoice Number: Odoo posted invoice number When disabled, existing behavior is preserved (PO Number = SO number). Both features are opt-in via carrier configuration fields, preserving full backward compatibility with existing setups.
This update simplifies the user interface by standardizing the term 'Audit Report' to 'Annual Report'. Previously, the inconsistent use of both terms created confusion for users. This change improves clarity and ease of navigation within the accounting knowledge section.
Original PR description
The user interface currently uses both the terms "Audit Report" and "Annual Report", which can be confusing for users. To eliminate this confusion, "Audit Report" will be renamed to "Annual Report". backport of https://github.com/odoo/enterprise/commit/c2fc5a1643f2e005007437f7ae655d2329ac49ad [feeback-6088379](https://www.odoo.com/odoo/project.task/6088379)
This update simplifies user database access management by adding a dedicated 'databases' tab to the res.user view. Previously, administrators had to manually search for user database access, now it's readily available. This improves efficiency and simplifies user permission management.
Original PR description
The aim of this commit is to allow db_manager to see the list of databases in which a specific user has access and to allow removing this access in bulk if required. Before this commit: To see the list of db in which a user has access, a db_manager would have to go to the list view and make a search on the login/name of the user, potentially matching other db_user in the process. After this commit: The list of db is available out of the box in a databases tab on the res.user view. Task-id: 5945298
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
8 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
6 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