Daily updates from Odoo
Friday, January 9, 2026
228 changes
18 changes
Enhancements to existing features
This update translates the error descriptions displayed when interacting with the Nilvera API, making them understandable for Turkish-speaking users. The underlying error details, which are dynamic, remain in Turkish to ensure accurate data transmission. This improves the user experience and reduces confusion.
Original PR description
Before this commit: - Nilvera errors were shown exactly as received from the API, which was in Turkish and could be confusing for non-Turkish users. After this commit: - The error descriptions have been translated. Error details remain in Turkish, as they are dynamic and reliably translated at this stage. task-5003543 Forward-Port-Of: odoo/odoo#231605
Resolved issues and error corrections
This update corrects a formatting issue in Peruvian purchase invoices and credit notes. Previously, the document number was automatically padded with leading zeros, but the related name field wasn't updated. This change ensures consistent and accurate document number formatting across all invoice types, improving data reliability for reporting and vendor management.
Original PR description
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not…
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not synchronized, causing data inconsistencies between these fields. Steps to reproduce: 1. Create a purchase invoice for a Peruvian company 2. Select a document type (Factura, Boleta, or Credit/Debit Note) 3. Enter a document number like "F01-100" 4. Save the record 5. Observe that l10n_latam_document_number shows "F01-00000100" but name field may show a different format This fix ensures that after formatting the document number, the name field is synchronized with the correctly formatted value, preventing inconsistencies in vendor invoices and reports. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241948
This update restores the 'Load More' functionality for custom reports, addressing a recent omission following a core odoo update. A temporary workaround was implemented to accommodate reports without standard report lines, ensuring continued functionality for key reporting features. This change primarily impacts localized reports and doesn't significantly alter core reporting processes.
Original PR description
Since the new Load more which was introduced in odoo/enterprise#96974, the Load more on custom expand function was missing. Since most of the reports dont have report lines, we need to hack a bit the function. This wont support the sum of the load more lines for the columns that would have supported it but this is a compromise we have taken since it would have required to create a fake report line. The following reports dont need a load more since they have a very limited amount of lines (such as accounts or months): - account_fiscal_categories/report/account_fiscal_report_handler.py - account_fiscal_categories_fleet/report/account_fiscal_categories_fleet_report_handler.py - l10n_co_reports/models/l10n_co_reports_fuente.py - l10n_co_reports/models/l10n_co_reports_ica.py - l10n_co_reports/models/l10n_co_reports_iva.py
This update fixes an issue where changing the animation speed of image shapes would reset their colors. The fix ensures that color changes persist when adjusting animation speed, providing a more consistent and expected user experience. This improves the visual quality of the website's interactive elements.
Original PR description
Before this commit, changing the animation speed would reset the colors applied to the image shape. This was due to the code always considering the shape as new because the current shape id wasn't retrieved. Therefore, the colors would be reset to the default ones. Steps to reproduce the issue: - Drop a snippet with an image - Click on the image - Add an image shape. It should be animated. - Change the image shape color - Change the image shape animation speed => The image shape color was reset. task-5375497 Forward-Port-Of: odoo/odoo#242594 Forward-Port-Of: odoo/odoo#239451
This update adjusts how Odoo handles tax exemption reasons on UBL invoices. Previously, a specific reason code was always required; now, it's optional. When a reason code isn't provided, Odoo automatically uses a default reason based on the tax category, ensuring compliance with UBL standards.
Original PR description
According to the ubl documentation the tax exemption reason code is not always required on the document. But when no exemption reason code is given, we have a default exemption reason for the appropriate tax categories. task: 5223145 Forward-Port-Of: odoo/odoo#242769 Forward-Port-Of: odoo/odoo#233770
This update fixes an issue where users wouldn't see signed documents after a request was completed. The change ensures that both the requester and signer automatically receive 'view' access rights to the signed document, resolving the visibility problem. This improves the user experience and ensures proper document access.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#103470 Forward-Port-Of: odoo/enterprise#97132
This update fixes an issue where the "Add" button in the Point of Sale (PoS) interface was cut off when using the German language. The fix increased the button's width to accommodate longer translations, ensuring all buttons are clearly visible and readable for all users.
Original PR description
**Steps to reproduce:** - Make a product that has some optional products - Switch the language to German - Open the PoS and order the product - The "+ Add" button will be cut and not shown correctly **Why the fix:** Whenever the translation for "Add" was too long, it didn't fit in the button anymore and was unreadable. We now changed the width of the button to be flexible as to accept longer words. opw-5385398 Forward-Port-Of: odoo/odoo#240698
This update fixes an issue where email notifications weren't consistently reaching all channels within a category. The change now sends notifications per category, ensuring all channels associated with a category receive updates, improving communication efficiency. This enhancement ensures users receive timely notifications related to their categories.
Original PR description
In the bus_sync_mixin, when comparing old and new values, the key (channels, bus_target) is problematic when having multiple channels. This can lead to KeyError if one of the channels is missing in the new values so that all the channels in the new values might be ignroed. This commit improves the performance of the bus by sending the change notifications per category when a category is modified, instead of sending them per channel. This way, all channels in a category will receive the notification without having to send it per channel. task-5418305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where newly created channels weren't automatically assigned to the user who created them. The fix ensures that the current user is always the owner of a channel, regardless of how it was created. This improves channel management and simplifies collaboration.
Original PR description
Before this commit, when creating a channel from the form view, the current user is not set as the owner of that channel. Since the channel_type is the default one, it is not sent by the form and therefore not in the create_vals. We should apply the default when the channel_type is not in those vals. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a restriction on the length of SEO keywords entered on website pages. Previously, the system limited keywords to 30 characters, which could negatively impact SEO efforts. Now, website users can enter longer, more descriptive keywords to improve search engine visibility.
Original PR description
Steps to reproduce: - Open the SEO dialog on a website page. - Try to enter a keyword longer than 30 characters. - Observe the input stops at 30 characters. Before this commit, the keyword field had a 30 character maxlength and blocked longer keywords. After this commit, the SEO keyword input accepts longer values with no maxlength restriction. task-5423796 Forward-Port-Of: odoo/odoo#241417
This update resolves a problem where changing the display mode or number of columns in Odoo's Image Wall feature caused errors in Google Chrome. The issue stemmed from a browser limitation when decoding multiple images simultaneously. By switching to a different approach that handles potential decoding failures gracefully, the display options are now consistently functional.
Original PR description
Steps to reproduce: ==================== - Go to the website in chrome - Create a Image Wall (gallery) - Add a lot of images. See attachments for a .zip file in task to test it. - Try to change the…
Steps to reproduce: ==================== - Go to the website in chrome - Create a Image Wall (gallery) - Add a lot of images. See attachments for a .zip file in task to test it. - Try to change the display mode or number of column -> An error will appear when the cursor get on the dropdown options. Cause: ====== In Google Chrome, calling img.decode() on a large set of images simultaneously (e.g., in an image wall) can result in `EncodingError: The source image cannot be decoded for some images`. This is a known Chromium issue (See [1]) where the browser's image decoder gets overwhelmed or hits a concurrency limit, causing it to reject valid images. The current implementation uses Promise.all(imgLoaded), which utilizes a "fail-fast" mechanism. Consequently, if a single image fails to decode due to this browser limitation, the entire promise rejects immediately. This unhandled rejection interrupts the execution flow, preventing the display mode or column options from functioning correctly when the user interacts with them. Solution: ======== Replace `Promise.all(imgLoaded)` with `Promise.allSettled(imgLoaded)`. Unlike `Promise.all`, `Promise.allSettled` waits for all promises to finish regardless of whether they succeeded or failed. [1]: https://issues.chromium.org/issues/40261318 opw-5249130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240062
This update resolves a technical issue where the 'Mark as Ready' order completion process for UrbanPiper deliveries was failing due to missing customer information. The fix ensures that the system correctly checks for a valid customer before completing the order, preventing errors related to 'undefined street' and ensuring accurate receipt printing.
Original PR description
Steps to produce: ==== - Place an online delivery order through urbanpiper - Edit the order and remove customer - Complete the order as Marks as Ready - Print Reciept Issue: ==== - TB occurs stating undefined street Fix: ==== - Check whether partner is assigned or not task-5407001 Forward-Port-Of: odoo/enterprise#103633 Forward-Port-Of: odoo/enterprise#102100
This update corrects a visual issue in the upsell subscription quotation preview where section columns were incorrectly aligned. Recent improvements to the core sale module impacted how subscription columns were calculated, leading to this misalignment. The fix ensures that upsell subscription quotation previews display correctly.
Original PR description
Steps to Reproduce: - Create an upsell subscription quotation with sections - Click on the `Preview` button Issue: - Sections colspan is misaligned compared to the rest of the lines Cause: - After recent section improvements in sale, upsell subscription columns were not taken into account while computing the section colspan Solution: - Adjust the colspan when the subscription is an upsell subscription opw-5476669 Affected Version: 19.0 Before: <img width="1920" height="932" alt="image" src="https://github.com/user-attachments/assets/2321d7d7-cb6f-465f-a1af-b143d7a8ccd3" /> After: <img width="1909" height="934" alt="image" src="https://github.com/user-attachments/assets/991eef3f-d3dd-4ee3-8316-b2370009435f" /> Forward-Port-Of: odoo/enterprise#103635
This update corrects a problem with importing WinBooks tax data. Previously, the system incorrectly handled tax tag signs, leading to missing tax information in reports. This change removes the sign from tax tags during import, ensuring accurate tax reporting.
Original PR description
Import a WinBooks file on a fresh database (a sample can be found in the test files of test_winbooks_import). In the imported taxes, we can see that the tax_tags contain signs. However, since https://github.com/odoo/odoo/pull/225252 , tax tags should no longer store a sign. This causes issues with imported entries in the tax reports: they are not included. This commit adapts the import for WinBooks tax_tags to remove their sign before importing them. opw-5345933 Forward-Port-Of: odoo/enterprise#101459
This update resolves a problem that prevented users from installing the ‘stock_account’ module. The issue stemmed from an attempt to create accounts for branches within the system, which weren’t properly configured. The fix utilizes existing company accounts to ensure smooth module installation.
Original PR description
**Repro steps:** 1. Install a localization module with defined account_stock_expense_id or account_stock_variation_id 2. Add a branch to that localization company 3. Attempt to install stock_account **Problem:** A traceback shows preventing the user from installing stock_account ERROR: null value in column "account_type" of relation "account_account" violates not-null constraint **Root cause:** In stock_account post init hook, stock related fields data are attempted to be added from localizations. The problem is that branches don't have accounts by default, they own their parent company accounts. **Solution:** This commit fixes this issue by using AccountChartTemplate.ref in _load_data. This ref would find the record (i.e., account.account record) instead of attempting to create a new one for child companies. Ticket [link](https://www.odoo.com/odoo/project.task/5391764) opw-5391764 Forward-Port-Of: odoo/odoo#239104
This update resolves an issue with the demo data for the account_transfer module. Previously, the demo data wasn't correctly configured, leading to inaccurate results. This change ensures the demo data accurately reflects the module's functionality, providing a reliable demonstration for users.
Original PR description
This commit fixes demo data of account_transfer module by using company_xmlid to create account.transfer.model records. opw-5391764 Forward-Port-Of: odoo/enterprise#103640
This update improves the speed of the bank reconciliation feature in the Enterprise version of Odoo. Previously, the system fetched all sales orders for a partner each time a reconciliation was opened. Now, it efficiently retrieves order counts initially, significantly reducing the number of database operations and speeding up the process.
Original PR description
Before this commit: We fetch all the sale orders for a partner every time we open unfold lines. This commit aims to reduce orm operations by fetching the sale orders counts one time upon loading the bank reconciliation for the first time or changing the pager. task-5241035 Forward-Port-Of: odoo/enterprise#100479
This update resolves a validation error that occurred when creating PEPPOL invoices with cash rounding enabled. The fix removes a blocking XML node that was causing issues with the invoice's UBL structure, ensuring invoices are correctly processed and validated against PEPPOL standards. This ensures accurate invoice generation and transmission.
Original PR description
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash…
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash rounding method (in the settings where cash rounding can be enabled): - precision `1.00` - strategy: Add a rounding line - profit / loss account: any 4. Create an invoice - Set a Belgian partner (e.g. "BE Company CoA" is okay) - Set the cash rounding method from step 2 - Single Line with price=70.00€ and a 21% tax 5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items: - 70.00€ base - 14.70€ tax - 0.30€ rounding 6. Confirm & Send (with PEPPOL) Current Behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€ - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€ - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax" - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `BR-E-08`: "In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount BT-116 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT"" Expected behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ Solution: Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines. https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals As invoice lines should contain their item name. Rounding line won't have one. https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/ As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information. https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310 As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order. This commit also: - fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08). opw-5434335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241717
13 changes
Enhancements to existing features
This update adjusts the chart of accounts for Odoo's Vietnamese localization to comply with new accounting regulations (Circular 99/2025). This change is necessary to ensure accurate financial reporting starting in January 2026, aligning with current Vietnamese accounting standards.
Original PR description
Update the COA for the vietnamese localization, which is based on the circular 200/2014 by the new one based on the circular 99/2025. This new COA applies starting in Jan. 2026 task-5357470 Forward-Port-Of: odoo/enterprise#103769 Forward-Port-Of: odoo/enterprise#102843
Resolved issues and error corrections
This update prevents unnecessary email reminders for timesheet approvals. The system now only sends reminders when there are actual timesheets needing approval, ensuring users aren't overwhelmed with notifications. This change optimizes the approval workflow and reduces email clutter.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#102860 Forward-Port-Of: odoo/enterprise#52355
This update fixes an issue where the summary lines in the Barcode app appeared in light colors when Dark Mode was enabled. The fix uses dynamic color variables to ensure the summary lines correctly adapt to the user's chosen theme, improving the user experience across different settings. This ensures consistent visual presentation regardless of the user's preferred dark mode setting.
Original PR description
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before"…
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before" src="https://github.com/user-attachments/assets/39f47454-6dc5-4fe6-927d-8ebc984b13b7" /> ## Cause The `background` property was set to a constant (light) color. ## Steps to reproduce 1. Install the Barcode (`stock_barcode`) and Purchase (`purchase`) apps. 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. Turn on Dark Mode by clicking in the upper-right corner and toggling *"Dark Mode"* 3. Create a product tracked *By Unique Serial Number*. 4. Create a Purchase Order for the product created in step 3 with a quantity greater or equal than 2, then click *Confirm*. 5. Go to the Barcode app, click *Operations*, then *Receipts*, and select the picking created from the PO. 6. The summary line appears in white (or light blue when selecting it). ## Solution We can use variables instead of constant colors. The `--list-group-bg` variable holds a different color depending on whether the line is selected, faulty, or completed. https://github.com/odoo/enterprise/blob/999009c859a1fb8e244f754a530fe39d71ede506/stock_barcode/static/src/components/line.scss#L27-L47 ## After this commit <img width="1912" height="983" alt="after" src="https://github.com/user-attachments/assets/899366fc-0290-42e8-9c50-fd3298e262d6" /> opw-5364654 Forward-Port-Of: odoo/enterprise#102270
This update fixes a UI issue where long email messages would overflow the message bubble, causing a broken display. The change makes email content scrollable within the bubble, ensuring a consistently readable experience for users sending and receiving messages. This improves usability for the subscription module.
Original PR description
Current behavior before PR: When the email template (message_type = `comment`) has content that is longer (in width), the content tends to overflow out of the bubble which breaks the UI. Desired behavior after PR is merged: This commit fixes the issue by making the content scrollable inside the bubble. Task-5363388 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242934 Forward-Port-Of: odoo/odoo#237878
This update fixes an issue where refund alerts were incorrectly triggered due to rounding differences in order totals. The change ensures that the system accurately compares refund amounts to order totals, preventing false alerts and improving the reliability of the Point of Sale system. This ensures accurate financial reporting and reduces potential customer service issues.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240 Forward-Port-Of: odoo/enterprise#103551 Forward-Port-Of: odoo/enterprise#102224
This update resolves a problem where scanning barcodes on picking orders with kit product variants would cause errors. The fix ensures that packaging information is correctly captured during barcode scans, allowing for accurate tracking of kit components. This improves the reliability of the barcode scanning process for inventory management.
Original PR description
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration.…
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration. 2. Create a product, that as a least 2 variants. 3. Add a packaging to one of the variants. 4. Create a BoM for created product (kit type). 5. Create a picking order for the variant with packaging. 6. Print the picking operation to scan the code through barcode. 7. Go to barcode and try to scan it, this will trigger the traceback. ### Cause of the issue: Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data: https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91 _get_stock_barcode_data will obtain the packaging methode for the products. https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16 since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information. ### Fix: We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids: https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441 our fix will allow for packaging in the variant to be considered when there is more than only one variant. opw-4852875 Forward-Port-Of: odoo/enterprise#103155 Forward-Port-Of: odoo/enterprise#87867
This update corrects a technical issue where the IoT test button incorrectly reported successful connections even when errors occurred (like timeouts or other websocket problems). By standardizing the data format and adding timeout checks, the button now accurately reflects the true status of the IoT device, improving reliability.
Original PR description
This commit fixes several situations where a positive status would be given by the test button despite the presence of an error: - If the websocket connection was used but there was a timeout - If the websocket connection was used but there was any other error - If any 6-digit error code was returned when using the stable IoT box To fix these issues, we stop using the `data['message']` field, since it gets ignored by the websocket confirmation controller. We now use the same result format as the other requests (and the stable IoT box). We also add a check for the `"timeout"` that we receive when a websocket request times out.
This update resolves a technical issue where order completion with UrbanPiper resulted in an 'undefined street' error. The fix ensures the system correctly checks if a customer is assigned before completing the order, preventing this error and allowing users to successfully mark orders as ready and print receipts.
Original PR description
Steps to produce: ==== - Place an online delivery order through urbanpiper - Edit the order and remove customer - Complete the order as Marks as Ready - Print Reciept Issue: ==== - TB occurs stating undefined street Fix: ==== - Check whether partner is assigned or not task-5407001 Forward-Port-Of: odoo/enterprise#103633 Forward-Port-Of: odoo/enterprise#102100
This update ensures the Helpdesk dashboard's styling is consistent with other Odoo dashboards. Specifically, the conditional formatting for the Top Customers pivot has been extended to include all rows, and border styles have been aligned. This improves the overall visual appearance and user experience.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103284 Forward-Port-Of: odoo/enterprise#103019
This update resolves an issue where read-only accounting users couldn't access customer statements. The fix corrects a restriction in the system that previously limited button visibility to 'Invoicing' users, ensuring all authorized users can now view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103148 Forward-Port-Of: odoo/enterprise#102683
This update resolves a technical issue that caused a traceback when users accessed the bank reconciliation popover in debug mode, specifically when reconciling statements with invoices in different currencies. The fix ensures the popover component receives the correct data, improving stability and usability for users.
Original PR description
In Bank reconciliation widget, when reconciling a statement with a move in different currency, users may display a popover to access some reconciliation info. Currently, accessing this component in debug mode may raise a traceback. Steps to reproduce: - Have a Bank statement in company currency - Reconcile with an invoice in foreign currency - Go in debug mode - From the reconciliation widget, locate the reconciled bank statement - Click on the reconciled bank statement popover button Issue: Traceback is shown `OwlError: Invalid props for component 'BankRecLineInfoPopOver': 'exchangeMove' is not a object` It occurs because props validation of the Owl component will fail BankRecLineInfoPopOver opw-5355964 Forward-Port-Of: odoo/enterprise#103731
This update fixes an issue where the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting of employee contract overlap with payslips. The change ensures that contract overlap dates are accurately limited to the payslip period, improving payroll accuracy and reporting.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103500 Forward-Port-Of: odoo/enterprise#100700
This update resolves a problem preventing connections to IAP Codaclean, which is a key integration for Belgian accounting. The issue was caused by a missing parameter in the system, now corrected to ensure seamless data exchange and proper functionality.
Original PR description
Connections to IAP Codaclean are failing because of missing `enterprise_number` param. no-task-id Forward-Port-Of: odoo/enterprise#103724
13 changes
Enhancements to existing features
This update corrects the names and descriptions of taxes used in the Odoo accounting system for Belgium. These changes ensure accurate reporting and compliance with Belgian tax regulations. This impacts the way tax calculations are handled within the system.
Original PR description
### With this commit:- - We are updating the current tax name and its description in Belgium. - Please visit the task for more reference. task-5363874 Forward-Port-Of: odoo/odoo#242553 Forward-Port-Of: odoo/odoo#236242
Resolved issues and error corrections
This update ensures that product attributes are correctly displayed on refund orders and receipts. Previously, when a refund was processed, these attributes were lost. The fix correctly transfers the attributes from the original order to the new refund order, improving the accuracy of refund records.
Original PR description
**Steps to reproduce:** - Make an order with a product that has variants and chose whatever in the popup - Pay for that order, then refund it - The attribute is not shown on the orderline anymore - The attribute is not shown on the receipt either **Why the fix:** When making a refund, we are actually making a new order, so we need to move the data from the old order to the new refund order. During this transit, the *attribute_value_ids* was forgotten on the moving lines, so the attributes were lost. We now give the old attributes to the new line. opw-5393332
This update resolves a technical issue within the HTML editor that could cause errors when content is deleted during editing. The fix ensures the editor continues to function correctly even when all inserted content is removed, improving overall stability and user experience. This was triggered by a disconnect between selection nodes.
Original PR description
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`,…
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`, and some specific `<br>` nodes. Ultimately, the selection is set after the last inserted node. In some cases, none of the inserted content remains after the clean up. When this happens, the selection is being set after the last inserted node, which is not part of the DOM anymore, and therefore leads to an error. This commit prevents this from happening by detecting when all inserted content was actually already removed. Steps to reproduce: - In a plain web page, copy a <br> into the clipboard - In an editor, put a character on a line - Paste => An error popup was displayed task-5429909 [FIX] html_editor: avoid failing when selection nodes are disconnected This commit addresses a traceback that was spotted but for which the actual scenario remains undetermined. The only possible way this traceback may occur is if nodes inside a selection are disconnected. The test added by this commit produces the same traceback as the observed one. task-5429909 Forward-Port-Of: odoo/odoo#242488
This update resolves an issue where Google Input Tool caused errors in HTML fields, specifically when typing Arabic numbers. The fix ensures the system correctly handles `keydown` events, even those triggered by the Google Input Tool, preventing tracebacks and improving overall stability.
Original PR description
Problem: When using Google Input Tool, typing Arabic numbers causes a traceback in HTML fields. Cause: The tool triggers a fake `keydown` event without the `key` attribute. This is failing before c10fd06320b013057831a6a46b2922b5386b71ef. Solution: Explicitly check that the `key` attribute exists on the event before using it. Steps to reproduce: - Install Google Input Tool in your browser. - Open any HTML field. - Add any character using the extension. - Observe a traceback. opw-5447680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242498
This update prevents the automatic cancellation of 'post -> stock' pickings when a backorder is cancelled in multi-step production routes. Previously, cancelling a backorder would also remove the completed picking. This change ensures that pickings are only cancelled if the related MO is fully completed, streamlining operations and reducing unnecessary disruptions.
Original PR description
Issue ----- For multi step routes, cancelling the backorder MO also cancels the (post -> stock) picking for the produced quantity. Steps to reproduce ----- - Activate routes - Go to the main warehouse and activate 3 step production - Creation of a MO for 100 units - Validate the pre production picking - Produce 40 units and create a backorder for remaining quantity - Cancel the backorder > The "post -> stock" picking is cancelled as well Cause ----- The picking is in "ready" state, so it gets cancelled by https://github.com/odoo/odoo/blob/083d53c688a0d18a1f4594b9fcbbfa738aa5e86d/addons/mrp/models/mrp_production.py#L1743-L1744 Desired behaviour ----- > Only cancel related MO pickings (pre prod/post prod) if no MO (or MOs) done yet. Don't cancel related MO pickings if any MO validated. ----- Ticket: opw-5405024 Forward-Port-Of: odoo/odoo#239865
This update prevents unnecessary email reminders for timesheet approvals. The system now only sends reminders when there are actual timesheets needing attention, ensuring users aren't overwhelmed with notifications. This change optimizes the approval workflow and reduces email clutter.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#102860 Forward-Port-Of: odoo/enterprise#52355
This update resolves an issue where the summary lines within the Barcode app appeared in a light color scheme, regardless of the user's Dark Mode setting. The fix utilizes dynamic color variables to ensure the summary lines correctly display in dark mode, improving the user experience and visual consistency across the Odoo platform.
Original PR description
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before"…
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before" src="https://github.com/user-attachments/assets/39f47454-6dc5-4fe6-927d-8ebc984b13b7" /> ## Cause The `background` property was set to a constant (light) color. ## Steps to reproduce 1. Install the Barcode (`stock_barcode`) and Purchase (`purchase`) apps. 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. Turn on Dark Mode by clicking in the upper-right corner and toggling *"Dark Mode"* 3. Create a product tracked *By Unique Serial Number*. 4. Create a Purchase Order for the product created in step 3 with a quantity greater or equal than 2, then click *Confirm*. 5. Go to the Barcode app, click *Operations*, then *Receipts*, and select the picking created from the PO. 6. The summary line appears in white (or light blue when selecting it). ## Solution We can use variables instead of constant colors. The `--list-group-bg` variable holds a different color depending on whether the line is selected, faulty, or completed. https://github.com/odoo/enterprise/blob/999009c859a1fb8e244f754a530fe39d71ede506/stock_barcode/static/src/components/line.scss#L27-L47 ## After this commit <img width="1912" height="983" alt="after" src="https://github.com/user-attachments/assets/899366fc-0290-42e8-9c50-fd3298e262d6" /> opw-5364654 Forward-Port-Of: odoo/enterprise#102270
This update fixes a data inconsistency issue in Peruvian invoices and credit notes. Previously, the document number was formatted with leading zeros, but the related name field wasn't updated. This change ensures all invoice fields are consistently formatted, improving accuracy in vendor invoices and reports.
Original PR description
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not…
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not synchronized, causing data inconsistencies between these fields. Steps to reproduce: 1. Create a purchase invoice for a Peruvian company 2. Select a document type (Factura, Boleta, or Credit/Debit Note) 3. Enter a document number like "F01-100" 4. Save the record 5. Observe that l10n_latam_document_number shows "F01-00000100" but name field may show a different format This fix ensures that after formatting the document number, the name field is synchronized with the correctly formatted value, preventing inconsistencies in vendor invoices and reports. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241948
This update corrects a bug that caused automatic balancing lines to be added to journal entries for company-paid expenses. The fix ensures that tax calculations are handled correctly when creating these expense reports, preventing inaccurate accounting entries. This ensures consistent and reliable expense tracking.
Original PR description
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2.…
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2. Confirm and generate the expense report. 3. Reset the expense’s journal entry to draft and add an analytic account on the first line. → An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited. ## Cause For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*. In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes. However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`. This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines. As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate. ## Solution Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`. **opw-5166707** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241545 Forward-Port-Of: odoo/odoo#233841
This update resolves a validation error that occurred when generating PEPPOL invoices with cash rounding enabled. The fix removes a problematic XML node that was causing issues with the invoice's UBL structure, ensuring invoices are correctly processed and validated against PEPPOL standards. This ensures accurate invoice generation and compliance.
Original PR description
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash…
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash rounding method (in the settings where cash rounding can be enabled): - precision `1.00` - strategy: Add a rounding line - profit / loss account: any 4. Create an invoice - Set a Belgian partner (e.g. "BE Company CoA" is okay) - Set the cash rounding method from step 2 - Single Line with price=70.00€ and a 21% tax 5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items: - 70.00€ base - 14.70€ tax - 0.30€ rounding 6. Confirm & Send (with PEPPOL) Current Behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€ - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€ - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax" - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `BR-E-08`: "In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount BT-116 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT"" Expected behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ Solution: Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines. https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals As invoice lines should contain their item name. Rounding line won't have one. https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/ As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information. https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310 As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order. This commit also: - fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08). opw-5434335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241717
This update fixes an issue where read-only accounting users couldn't access the 'Customer Statement' button within customer records. The fix corrects a restriction in the system's access controls, ensuring all users with accounting rights can now view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103148 Forward-Port-Of: odoo/enterprise#102683
This update corrects a bug where purchase taxes weren't correctly applied to purchase orders when products were added from purchase agreements. The fix ensures that taxes associated with the parent company are now accurately reflected on child company purchase orders. This improves financial accuracy and reporting across the Odoo system.
Original PR description
### Issue: In a child company, adding a product from a Purchase Agreement to a Purchase Order does not apply the associated parent company's purchase taxes ### Cause: In the onchange, taxes were filtered by company: ```python taxes_ids = fpos.map_tax(line.product_id.supplier_taxes_id.filtered(lambda tax: tax.company_id == requisition.company_id)).ids ``` This filter fails for taxes belonging to the parent company, so they were not applied on the child company purchase order ### Steps to reproduce: - Create a company branch and switch to it - Enable `Purchase Agreements` in Settings - Create a product with a Purchase Taxes (ex. 15%) - Create a Purchase Agreement for any vendor with this product - Create a RFQ for the vendor and add the agreement - Observe that the tax is not applied opw-5121243 Forward-Port-Of: odoo/odoo#242909 Forward-Port-Of: odoo/odoo#237114
This update fixes a minor issue where discounts could result in a small, unexpected tax difference ($0.01) in sales orders. The change ensures that tax adjustments are correctly applied even when the overall tax total is zero due to discounts. This improves the accuracy of order totals.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set tax rounding to "Round Globally"; 2. create a 19.99% tax; 3. create a new sales order; 4. add a line with a $19.99 unit price & 19.99% tax; 5. add a second line with identical values; 6. apply a 100% global discount (-$38.98 subtotal, -$47.97 total). Issue ----- The order total is $0.01 due to VAT. Cause ----- The `_round_tax_details_tax_amounts` method distributes the "tax delta" across the tax details, but currently it only does this if there's a non-zero target tax amount. In our scenario, we have a $0.01 tax delta, but because our tax total is $0.00 due to the 100% discount, the delta doesn't get distributed, leading to the $0.01 difference not getting corrected. Solution -------- When deciding whether to distribute a tax delta, check the tax delta value instead of the target tax amount. opw-5345538 opw-5097907 Forward-Port-Of: odoo/odoo#240633
4 changes
Resolved issues and error corrections
This update ensures the Helpdesk dashboard's styling is consistent with other Odoo dashboards. Specifically, the conditional formatting for the Top Customers pivot has been extended to include all rows, and border styles have been aligned. This improves the overall visual appearance and user experience.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103019
This update fixes a visual issue in the Barcode app where summary lines appeared in light colors when Dark Mode was enabled. The fix utilizes dynamic color variables to ensure summary lines correctly adapt to the user's chosen theme, improving the user experience across different settings. This ensures consistent and professional appearance regardless of the user's preference for dark or light mode.
Original PR description
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before"…
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before" src="https://github.com/user-attachments/assets/39f47454-6dc5-4fe6-927d-8ebc984b13b7" /> ## Cause The `background` property was set to a constant (light) color. ## Steps to reproduce 1. Install the Barcode (`stock_barcode`) and Purchase (`purchase`) apps. 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. Turn on Dark Mode by clicking in the upper-right corner and toggling *"Dark Mode"* 3. Create a product tracked *By Unique Serial Number*. 4. Create a Purchase Order for the product created in step 3 with a quantity greater or equal than 2, then click *Confirm*. 5. Go to the Barcode app, click *Operations*, then *Receipts*, and select the picking created from the PO. 6. The summary line appears in white (or light blue when selecting it). ## Solution We can use variables instead of constant colors. The `--list-group-bg` variable holds a different color depending on whether the line is selected, faulty, or completed. https://github.com/odoo/enterprise/blob/999009c859a1fb8e244f754a530fe39d71ede506/stock_barcode/static/src/components/line.scss#L27-L47 ## After this commit <img width="1912" height="983" alt="after" src="https://github.com/user-attachments/assets/899366fc-0290-42e8-9c50-fd3298e262d6" /> opw-5364654 Forward-Port-Of: odoo/enterprise#102270
This update corrects a bug where delivery fees weren't accurately calculated when the sale order and company used different currencies. The fix ensures the delivery fee reflects the correct price based on the sale order's currency, resolving discrepancies in pricing displayed for international shipments.
Original PR description
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in…
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate. Sell for 15 EUR of products => the delivery picking shows 10 EUR Steps to reproduce ----- - Activate EUR currency at 1.5 EUR = 1 USD rate - Setup company in USD - Setup INTL FEDEX delivery method - Create a dummy product with a 10 USD sale price - Create a pricelist using the EUR currency - Create a sale for some INTL client - set pricelist to EUR - add dummy product - add INTL FEDEX shipping - confirm the sale - Confirm the linked delivery > Message in chatter shows a price of 10 EUR instead of 15 EUR Cause ----- The problem is with the `carrier_price` field of `stock.picking`. https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21 The value is set by https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155 which gets its' value from the response of https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157 We then go through https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382 where we call https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484 The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598 we should also filter to ensure the rate matches the order's specified currency. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#103232
This update fixes a bug in the Barcode app's Manufacturing Order creation flow. When tracking is disabled, a manufacturing order wasn't correctly generating components. The fix ensures the necessary data is set before comparisons are made, preventing errors and guaranteeing proper component addition to the Manufacturing Order.
Original PR description
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws…
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws - In the Barcode app, go to Manufacturing - Click New > Add product and select Table - Click Confirm -> Components are not added after the Table line The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected. This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`. This fix ensures that `lot_producing_id` is defined before performing the comparison. opw-5165163 Forward-Port-Of: odoo/enterprise#99735 Forward-Port-Of: odoo/enterprise#98440
24 changes
New functionality added to Odoo
This update enhances the project Gantt view by displaying resource availability, providing a clearer picture of team capacity and potential scheduling conflicts. This improvement allows project managers to make more informed decisions about resource allocation and project timelines.
Original PR description
After this PR resource unavailabilities will be added to project gantt view task-4730772
This update allows HR teams to easily export critical social insurance forms (Form 1 and Form 6) as Excel files directly from the employee record. The system now validates data to ensure all required information is present before export, and integrates Form 6 generation into the employee departure process.
Original PR description
This commit introduces the functionality to export NOSI social insurance forms (Form 1 for registration and Form 6 for termination) as XLSX files directly from the employee model. Adds 'Export NOSI Form 1' and 'Export NOSI Form 6' actions to the model, available in both form and list views for single or mass exports. Implements robust pre-export validation that checks for mandatory employee and company fields. If data is missing, a clear is raised, specifying all affected employees and the missing fields. Integrates the Form 6 export into the employee departure wizard. A new checkbox allows users to generate the form automatically when an employee is archived. Related task: 4933170.
Enhancements to existing features
This update enhances the Dimona process by simplifying the user interface and providing more clarity on the declaration status. It includes a new wizard for manual steps and a setting to easily switch between test and production environments, improving overall efficiency and reducing manual configuration.
Original PR description
purpose: improve the UX of the Dimona Flow - removed actions for Open/Close/Update/Cancel Dimona with Send Dimona which does the corresponding depending on the state - added more selections for…
purpose: improve the UX of the Dimona Flow
- removed actions for Open/Close/Update/Cancel Dimona with Send Dimona which does the corresponding depending on the state
- added more selections for `l10n_be_dimona_next_action` as:
- in progress when Dimona is Submited, waiting for ONSS validation
- done when Dimona is done
- issue When ONSS returned an issue; then post it in the chatter
- changed nothing to be False to be compatible with the desired display of the widget
- used the widget `dropdown_selection_badge` to show and allow to change dimona status
- added a wizard for manual dimona to guide the user to do the required steps if there is no onss certificate set
- added a dimona environment setting in the payroll setting to choose whether to communicate with production server or test server instead of changing the value of the route manually in the code when testing
- added more cases in test_dimona to handle if the declaration is blocked
task-id: 5269518This update simplifies the process for handling employee departures by introducing a new 'End of Collaboration' wizard. Instead of relying on archiving, employees can now manage their departure details through a single, intuitive workflow, aligning with existing notice period functionality. The archive function has been updated to simply mark records as inactive.
This update refactors the core Odoo HTTP module into smaller, more manageable components. This change improves code organization and potentially reduces memory usage, particularly when handling large files. The focus is on streamlining imports and optimizing file streaming.
Original PR description
The odoo.http module is a huge file with thousands of lines. In this work we split it in many smaller chunks. The desire to split odoo.http has been in the air for quite some time, notably with the…
The odoo.http module is a huge file with thousands of lines. In this work we split it in many smaller chunks. The desire to split odoo.http has been in the air for quite some time, notably with the introduction of the many facade objects. This work only moves the constants, functions and classes in new dedicated odoo.http-submodules. In order to make the diff easier to gasp, we decided *not* to do other changes such as moving methods around. That's job for a future work. We decided to re-expose under the "odoo.http" namespace only the four Controller, route, Response and request. All the other symbols are much less so used and are to be imported from their dedicated module. `content_disposition` is kinda a special one, it is often imported by controllers that load an entire file in memory before sending it. We are opinated and think it would be a better idea to stream to files in order to keep memory usage in check. We moved the function next to the Stream class so the latter can be discovered.
This update allows users to search for helpdesk tickets directly within the plugin. Following a simplification of the plugin's code, this feature has been added to improve ticket retrieval efficiency. The change requires adaptation within the Enterprise version of Odoo.
Original PR description
Purpose ======= The plugin have been simplified, and we removed the enrichment part, so the code needs to be adapted in enterprise as well. Allow searching helpdesk tickets. Task-4727609
This update simplifies how store and tag configurations are managed, offering easier-to-use Kanban and List views. Additionally, users can now update tag pricelists directly from the 'print label' menu, streamlining the process and improving efficiency.
Original PR description
We improve user experience by providing simpler kanban/list views to configure stores and tags. We also add a way of updating tags pricelists through the "print label" menu. see odoo/upgrade#9189 Task: 5380332
This update enhances the Time Off Overview by ensuring all employees are visible regardless of filtering options. Previously, the overview only displayed employees when viewed solely by individual employee groups. This change provides a more complete and accurate view of employee time off requests.
Original PR description
We show all employees in the timeoff overview only when the view is grouped only by employee and no leave filters are applied.
Task: 4852912Resolved issues and error corrections
This update resolves an issue where the bank reconciliation process would fail when multiple reconciliation models (like fees and write-offs) were applied to a single bank statement line. The fix combines the names of these models, ensuring the system can correctly process and validate complex reconciliation scenarios. This enhances the reliability of bank statement matching.
Original PR description
Steps to reproduce: - Configure several reconciliation models matching the same statement line. - Reconcile the line and validate When reconciling a bank statement line, multiple reconciliation models can be applied (e.g. fees + write-off). The matching confirmation message assumed a single record and crashed when accessing `reconcile_model.name`. Fix by joining the names of the applied reconciliation models. OPW-5416031 Forward-Port-Of: odoo/enterprise#103538 Forward-Port-Of: odoo/enterprise#103069
This update simplifies how AI errors are handled in live chat. Previously, a technical error message was translated for users, but a traceback still appeared. Now, errors are handled more gracefully, providing a generic message to users and allowing support teams to better understand the issue.
Original PR description
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function…
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms. The problem with this approach is two-fold. Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless. Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out. In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat. task-5177169 Forward-Port-Of: odoo/enterprise#97516
This update resolves an issue where unnecessary tax authority partners were pre-loaded in new Odoo databases, causing discomfort for users in sectors like restaurants. Now, partners are archived and activated only when the first return requiring them is created, streamlining the process and improving user experience.
Original PR description
New DBs are preloaded with tax authority partners, it makes users uncomfortable in some sectors(e.g restaurants). Archive these partners and activate them on the first return requiring them is created. task-5391773 Forward-Port-Of: odoo/enterprise#102701
This update ensures that users who initiate document signing (requesters) can always access the finalized, signed documents. Previously, access rights weren't automatically set, preventing requesters from viewing the completed documents. The fix grants both the requester and signer 'view' access to the signed document.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#103470 Forward-Port-Of: odoo/enterprise#97132
This update resolves an issue where scrolling in the Gantt view would cause the interface to freeze. The fix ensures selections work smoothly, even with extensive scrolling, by adjusting how the system identifies selection targets and triggering necessary cleanup processes.
Original PR description
Previously, scrolling too far during a selection or multi-selection in the Gantt view caused the interface to appear "frozen". This was caused by 2 problems: - virtualization made the initial "dragged" cell (i.e. the cell on which the selection starts, which is the recognized drag target) disappear when scrolling too far, causing the drag sequence to be interrupted; - interrputing the selection drag sequences did not call the proper cleanup functions, leaving both selection "ghost" cells and badges visible. This commit fixes both of these issues: - drag target for selection is now the cell container (not affected by virtualization), and not the cells themselves; - cleanup functions related to selection and multi-selection are now called on "dragend" instead of the "drop" handler, allowing them to be applied everytime they're needed. Forward-Port-Of: odoo/enterprise#103694 Forward-Port-Of: odoo/enterprise#103499
This update streamlines the refund process in Odoo's Point of Sale module. Now, when a user sets the refund quantity for a line to its maximum, the system automatically selects the next available refundable line, eliminating the need for manual clicks. This improves efficiency and reduces the chance of errors during refunds.
Original PR description
Before this commit : ----------- - After set the refund quantity of a line to the maximum, the user had to manually click on the next line to refund. After this commit : ------------ - When the user sets the refund quantity of a line to the maximum (equal to the refundable quantity), the next refundable line is automatically selected. Task-5334572 Related PR-https://github.com/odoo/odoo/pull/236491
This update modifies how annual leave is calculated within the Odoo Enterprise system. The 'Annual Leave' type has been removed from leave type configurations and moved to the payroll settings. Consequently, the system no longer automatically computes total annual leave days for employees.
Original PR description
Removed Annual Leave type from leave types and added it in Payroll settings, total leave days per year are not computed anymore Task: 5048791
This update allows users to successfully sync bank accounts that have been previously archived. Previously, attempting to sync an archived account would result in an error. Now, users can reconnect and synchronize these accounts, improving data accuracy and usability.
Original PR description
Before this commit: When a user tries to sync a bank account that was previously archived, the bank sync throws an error. After this commit: Users can now sync a bank account that is in an archived state. task-5261784
This update fixes a technical issue that was causing tracebacks when generating reports. The underlying code was incorrectly referencing a parameter that had been removed, leading to errors. This change ensures reports generate correctly and reliably.
Original PR description
The method still declared a progress parameter even after it was removed from the underlying call, resulting in a traceback when unfolding the report line. The parameter is now removed. ref commit: https://github.com/odoo/enterprise/commit/ff2895144ecfc66d2b23bb872b39f5b446ae0da6 task-5476442 Forward-Port-Of: odoo/enterprise#103672
This update fixes an issue where Odoo pivot reports incorrectly displayed dimension names. Specifically, when adding a dimension based on a related field (like 'country_id.name'), the display name was not properly formatted. This change ensures dimensions are shown with the correct, user-friendly names, improving report clarity and usability.
Original PR description
Steps to reproduce:
- Insert an Odoo pivot
- Click on "defer update"
- Add a dimension with a relation ("country_id.name") => The dimension is added but marked as invalid and the display name is incorrect ("country_id.name" instead of "Country > Name")
Task: 5411336
Forward-Port-Of: odoo/enterprise#103695
Forward-Port-Of: odoo/enterprise#102237This update corrects a visual issue in the upsell subscription quotation preview where section columns were incorrectly aligned. Recent improvements to the base sale module impacted how subscription columns were calculated, leading to this misalignment. The fix ensures that all sections display correctly in the preview.
Original PR description
Steps to Reproduce: - Create an upsell subscription quotation with sections - Click on the `Preview` button Issue: - Sections colspan is misaligned compared to the rest of the lines Cause: - After recent section improvements in sale, upsell subscription columns were not taken into account while computing the section colspan Solution: - Adjust the colspan when the subscription is an upsell subscription opw-5476669 Affected Version: 19.0 Before: <img width="1920" height="932" alt="image" src="https://github.com/user-attachments/assets/2321d7d7-cb6f-465f-a1af-b143d7a8ccd3" /> After: <img width="1909" height="934" alt="image" src="https://github.com/user-attachments/assets/991eef3f-d3dd-4ee3-8316-b2370009435f" /> Forward-Port-Of: odoo/enterprise#103635
This update improves the speed of the sales reconciliation feature by optimizing how sale order data is retrieved. Previously, all sales orders were loaded every time a partner's reconciliation was viewed. Now, the system efficiently fetches order counts initially, reducing the number of database operations and significantly speeding up the process for users.
Original PR description
Before this commit: We fetch all the sale orders for a partner every time we open unfold lines. This commit aims to reduce orm operations by fetching the sale orders counts one time upon loading the bank reconciliation for the first time or changing the pager. task-5241035 Forward-Port-Of: odoo/enterprise#100479
This update fixes a technical issue where sales orders were being sent to the blackbox service multiple times. The change ensures that orders are only transmitted once, improving system efficiency and reducing potential data overload. This improves the reliability of our reporting and monitoring processes.
Original PR description
This fix ensure we don't send twice the same NS (normal sale) to the blackbox. We only push the order to the blackbox if it does not contain a signature yet. Forward-Port-Of: odoo/enterprise#102564 Forward-Port-Of: odoo/enterprise#102434
This update corrects a small typographical error within the order payment validation process in the Enterprise module. The fix ensures consistent and accurate data processing, preventing potential minor disruptions to financial transactions. This is a routine maintenance update.
Original PR description
Fix small typo introduced here: https://github.com/odoo/enterprise/pull/99202 Forward-Port-Of: odoo/enterprise#103559
Code cleanup and technical improvements
This update refactors WhatsApp code within the Odoo Enterprise platform to better organize channel-related functionality. Specifically, key data and actions are now tied to the WhatsApp channel, improving stability and maintainability. This change enhances the overall WhatsApp experience for users.
Original PR description
PR community: https://github.com/odoo/odoo/pull/242598
This update streamlines how vehicle changes are tracked within the system. Previously, separate fields were used for cars and bikes, but now the vehicle model directly stores this information. This simplifies data management and eliminates unnecessary distinctions.
Original PR description
Before https://github.com/odoo/odoo/commit/078fbba4decb32ae4b5d9878ee3788f7042382e8, plan_to_change_car and plan_to_change_bike were historically related from the driver that could have both car and bike so it made sense to have them separated. Since they are now stored on vehicle model directly, there is no reason to keep them separated anymore. The vehicle is either a car or a bike (or whatever it could be) and the concept of planning to change the vehicle is not dependant of the type of the current vehicle. This commit applies the changes done in Community Fleet module. Task-4966460
4 changes
Resolved issues and error corrections
This update fixes a bug preventing credit notes created with the DIAN support document journal from successfully sending required documents. The issue stemmed from an incorrect namespace being used, which caused errors during the document generation process. This change ensures proper DIAN document transmission for credit notes.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540
This update resolves a bug that prevented users from correctly accessing and editing sign templates linked to certain item roles. The fix corrects record rules, ensuring proper access rights are granted when opening or modifying these templates. This improves the usability and reliability of the sign template functionality.
Original PR description
Fix record rules on sign.item.role that prevented users from reading and creating item roles linked to accessible templates, causing access errors when opening or editing sign templates. task-5428886
This update fixes an issue where the summary lines in the Barcode app appeared in light colors when Dark Mode was enabled. The fix utilizes variables to dynamically adjust background colors based on selection status, ensuring a consistent and visually appropriate display across different user interface themes. This improves the user experience for all users, especially those utilizing Dark Mode.
Original PR description
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before"…
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before" src="https://github.com/user-attachments/assets/39f47454-6dc5-4fe6-927d-8ebc984b13b7" /> ## Cause The `background` property was set to a constant (light) color. ## Steps to reproduce 1. Install the Barcode (`stock_barcode`) and Purchase (`purchase`) apps. 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. Turn on Dark Mode by clicking in the upper-right corner and toggling *"Dark Mode"* 3. Create a product tracked *By Unique Serial Number*. 4. Create a Purchase Order for the product created in step 3 with a quantity greater or equal than 2, then click *Confirm*. 5. Go to the Barcode app, click *Operations*, then *Receipts*, and select the picking created from the PO. 6. The summary line appears in white (or light blue when selecting it). ## Solution We can use variables instead of constant colors. The `--list-group-bg` variable holds a different color depending on whether the line is selected, faulty, or completed. https://github.com/odoo/enterprise/blob/999009c859a1fb8e244f754a530fe39d71ede506/stock_barcode/static/src/components/line.scss#L27-L47 ## After this commit <img width="1912" height="983" alt="after" src="https://github.com/user-attachments/assets/899366fc-0290-42e8-9c50-fd3298e262d6" /> opw-5364654 Forward-Port-Of: odoo/enterprise#102270
This update resolves a bug that caused an extra suspense line to be created when editing a bank statement reconcile line, particularly when dealing with bills in foreign currencies. The fix prevents the system from incorrectly duplicating bill values and generating unnecessary entries, ensuring accurate reconciliation reporting.
Original PR description
Steps to reproduce: - Create a bill in foreign currency (for example 10€) - Create a bank statement in company currency matching almost the whole bill - Reconcile the statement with the bill - Click the pencil icon - Edit the reconcile line to match the full amount of the bill - Save Issue: An extra suspense line will be created with amount equal to the bill line This occurs because the system attempts to create the tax lines without the tax for the reconcile line and ends up duplicating the bill values opw-5355964
18 changes
Enhancements to existing features
This update allows system administrators to customize the main Odoo home menu with a message. Administrators can set a configurable message through the database, such as a maintenance notification, ensuring timely communication to users. This improves internal communication and operational alerts.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#102433
Forward-Port-Of: odoo/enterprise#102239This update simplifies the process for unregistering PEPPOL accounts by allowing a default 'unregister to sender' option. Previously, users had to unlink accounts directly, which is now streamlined for better efficiency and ease of use. This change improves the overall PEPPOL integration experience.
Original PR description
Allow unregistering to sender instead of unlinking directly. task-5395262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update strengthens Odoo's PDF/A compliance to the latest 3A standard, ensuring compatibility with critical document formats. Previously, inconsistencies in PDF libraries caused validation failures. This change includes fixes to decoding issues and adds necessary metadata for full compliance, improving document processing reliability.
Original PR description
This commit upgrades our PDF/A compliance from 3B to 3A, and fixes a few issues previously undetected due to the different PyPDF libraries we're currently supporting that made the previous PDF fails…
This commit upgrades our PDF/A compliance from 3B to 3A, and fixes a few issues previously undetected due to the different PyPDF libraries we're currently supporting that made the previous PDF fails even the 3B validation. Improvement 1: PDFA validators were previously detecting our file as 3B. Hence we update the metadata content `conformance` to `A`. Issue 2: When using `._pypdf` library, we failed the 6.1.2-2 and 6.8-1 rule even though we have implemented them on the previous version. It seems that this is caused by the `if SUBMOD...` check only ensuring it's not equal to `_pypdf2_2` (which makes it trigger for the new `_pypdf`). Hence, we reclarify the comments and fix the IF check. Issue 3: After implementing issue 2, it seems that a traceback occurs every time we're using `._pypdf` and calling the pdf write method. This is because the added characters on the header can't be decoded with `UTF-8`. Hence we change it to other greater-than-127-bytes characters that can still be decoded with `UTF-8`. (The actual character used here doesn't matter). Improvement 4: To be compliant with the new 3A rules (additional rules not there in 3B when we first implemented them), we add a minimal mark info dictionary and document structure on the PDF catalog object (`_root_object`). task-None Forward-Port-Of: odoo/odoo#234960
Resolved issues and error corrections
This update fixes an error in how Odoo calculates stock valuations when processing purchases in foreign currencies with auto-standard products. Previously, an incorrect currency exchange rate adjustment was being applied, leading to inaccurate inventory values. This change ensures the stock valuation accurately reflects the product cost.
Original PR description
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the…
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since [1], in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. [1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7 OPW-5380665
This update resolves an issue where certain bank statement lines were unnecessarily granted elevated permissions (sudo). Removing these permissions improves security and reduces potential risks associated with access to sensitive financial data. This change ensures that only authorized users can access and manipulate bank statement information.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242771
This update resolves an issue where the 'Pending' button in manufacturing orders incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the employee currently working on the operation is impacted when the 'Pending' button is clicked, improving order management accuracy.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The change ensures the wizard now correctly selects the customer-facing 'OUT' operation, streamlining the return process and improving order accuracy. This resolves a potential confusion point for users.
Original PR description
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a Helpdesk ticket for that customer. 4. From the ticket, click the "Return" button to open the wizard and select the sales order. Issue: - The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation. Cause: - Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary. Fix: - The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order. task-4948134
This update corrects an issue where manually changed invoice currency rates were lost when the invoice date wasn't specified. Previously, Odoo automatically set the invoice date to today, triggering unnecessary recalculations and data loss. Now, the system only recomputes rates and lines if the user manually adjusts the rate, ensuring accurate currency calculations.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551 Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should. Comparing `invoice_currency_rate` to the expected rate at creation is a better guess. task-5477481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where payment reports were inconsistently using different export formats (NACHA or localization-specific). The fix ensures that payment reports now consistently use the correct format based on the company's localization, improving report accuracy and reliability for financial reporting. This impacts all Odoo Enterprise users.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295This update ensures that all attendees of a calendar event receive post-event feedback emails, not just the event owner. The fix corrects a previous issue where email recipients were limited to the event's creator. This enhancement improves communication and collaboration for calendar-based activities.
Original PR description
**Steps to reproduce:** - Install Calendar and Marketing Automation apps - Go to Calendar - Add an event with multiple attendees - Go to Marketing Automation - Create the marketing automation…
**Steps to reproduce:**
- Install Calendar and Marketing Automation apps
- Go to Calendar
- Add an event with multiple attendees
- Go to Marketing Automation
- Create the marketing automation campaign
- Select `Calendar Event` as target
- Filter to only get your event
- Add an activity with a template
- Launch a test or start the campaign
- Mail is only sent to the owner of the event, not all the participants
Fixed in 19.0 as the attendees also receive the mail
Could also be reproduced with a more useful flow using appointment:
- Add appointment type
- Create meeting on it with a name, attendees, and status set to checked-in
- Create a mail automation campaign for Calendar Event
- Filter on [("appointment_status", "=", "attended")]
**Issue:**
Goal was to set a feedback mail which triggers after a calendar meeting was done. But the recipients are set using the `partner_id` of the record in:
`default_recipients = RecordsModel.browse(res_ids)._message_get_default_recipients()`
**Fix:**
Override `_message_get_default_recipients` to get the `partner_ids` of all the attendees.
opw-5266543This update fixes a technical issue that caused confusing traceback error messages during the ZATCA onboarding process. Now, users receive clear, user-friendly alerts with the actual error returned by ZATCA, ensuring a better experience and compliance with onboarding requirements. This improves the overall user experience and prevents potential issues with ZATCA integration.
Original PR description
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace…
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace result in exactly 127 bytes; see refs [1] and [2])—the system returns a traceback to the user instead of a clear and user-friendly error message. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType' This is due to the check-in `_l10n_sa_request_production_csid` for an 'error' key, not present in the response when an OTP is invalid because in these cases, the `_l10n_sa_call_api` returns the response_data directly. This fix improves the behaviour by displaying a user-friendly alert message with the error returned by ZATCA, instead of a traceback. This ensures a better experience and compliance with CCSID onboarding flows. [1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571 [2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960 sentry-7169834710
This update corrects a calculation error in the Belgian HR payroll module (l10n_be_hr_payroll) related to employment bonuses. The changes ensure that bonus calculations accurately reflect the latest tax regulations up to March 2026, improving payroll accuracy for Belgian employees. This update is a critical fix to maintain compliance and accurate financial reporting.
This update fixes an issue where accepting UrbanPiper online orders in multiple POS locations resulted in multiple preparation tickets being printed. The fix ensures that a preparation ticket is only printed once, regardless of how many POS sessions are open, improving order efficiency and reducing printing costs.
Original PR description
When a POS session is open in multiple tabs/locations, accepting an UrbanPiper online order triggers multiple preparation ticket prints. Steps to reproduce: - Configure POS with UrbanPiper and a preparation printer. - Open the same POS session in multiple tabs/locations. - Receive an online food delivery order via UrbanPiper. - Accept the order in the POS terminal (TicketScreen). (Note: Order may also be auto-accepted by UrbanPiper.) Issue: - The same order printed multiple preparation tickets due to multiple active session instances. Fix: - Ensure preparation ticket prints only once when accepting (or auto-accepting) UrbanPiper orders. - Remove local order records when rejecting an online order. Task-5353283
This update reverts a previous change that was causing issues when multiple companies used the same accounting entries. It ensures that account entries on move lines are correctly associated with the appropriate company, resolving a conflict that could lead to inaccurate financial reporting. This improves data integrity and reliability.
Original PR description
This reverts commit 7a2b03846f07dcf04743d745c7c942ea17721d0a. This commit created issues with account shared by multiple companies
This update removes a previous permission that allowed inventory users to change locations within the stock module. This change was deemed too risky and outside the scope of an inventory user's responsibilities. Testing confirms this change doesn't impact core functionality.
Original PR description
During the development of the task of the PR https://github.com/odoo/odoo/pull/149149, this permission was added as a possible way to fix some found problems, but that's not the way to fix them, as allowing inventory users to modify locations is something very dangerous and out of scope of what an inventory user should do. Reverting the permission, and doing manual tests with an inventory user for doing a "update quantity" or a "inventory adjustment", there's no problem, so maybe that permission was needed in a past codebase. @Tecnativa
This update resolves a technical issue in the Ecuadorian Point of Sale (POS) localization that caused a traceback when changing the selected customer. The fix ensures a customer is always selected, either a specific customer or 'Consumidor Final', improving stability and accuracy of transactions.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570
This update removes an unnecessary restriction that prevented users from inserting records into lists grouped by many2many fields. The change clarifies the process and ensures users can consistently add records from these grouped lists, improving usability. This resolves a previous limitation without impacting core functionality.
Original PR description
When we introduced the record-specific insertion from a list, we added a limitation on lists grouped by many2many fields but this limitation makes no sense, it only blocks the users without any clear reason. Task: 5267035
This update resolves a problem where the demo data for the Mexican payroll modules incorrectly set the company and partner names during installation. This prevented proper CFDI stamping of invoices and payment complements in demo databases, ensuring demo data is reliable for testing and demonstration.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases.
6 changes
Resolved issues and error corrections
This update fixes an issue where discounts applied to repair quotations weren't correctly carried over to the linked sale order lines. The fix removes a faulty process that was resetting the discount calculation, ensuring discounts are accurately reflected in the final sale order. This improves the accuracy of pricing and reporting for repair services.
Original PR description
**Steps to reproduce:** * Install the **Repair** module with demo data. * From Setting -> enable 'Discounts' and 'Pricelists' * From the home screen, search for Pricelist and open it. * Open the…
**Steps to reproduce:** * Install the **Repair** module with demo data. * From Setting -> enable 'Discounts' and 'Pricelists' * From the home screen, search for Pricelist and open it. * Open the default USD pricelist and go to Configuration → `Show public price & discount to the customer` * Open the *Repair* app. * Create a **Repair Order with parts**. * Click **Create Quotation** button from the repair order. * In the quotation, order line and set a **discount**. * Return to the repair order using the **Repairs** smart button. * Confirm the repair order, then **Start repair** and **End repair** order. **Observed behavior:** * The discount added on the quotation line disappears from the linked sale order line. **Cause:** * The `discount` field on `sale.order.line` is computed by `_compute_discount`, which `depends` on `product_id`, `product_uom`, and `product_uom_qty`. When `product_uom_qty` is written during `action_repair_done`, the compute method is triggered and the `discount` is recalculated. https://github.com/odoo/odoo/blob/49169c4c4fec57d78cd82c4c9366de9d69540e6a/addons/repair/models/repair.py#L457 **Fix:** * Remove the for loop that calls `write()` on the sale order lines, as it is functionally incorrect and causes the discount to be reset. --- opw-5352567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the clarity of expense bills by using payment reference notes to populate payment term line names. Previously, company account expenses resulted in empty payment term line names. This change ensures users see relevant notes from the payment reference, improving traceability and accounting context. It aligns with standard invoice practices.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices generated with complex certificates (multiple similar RDNs) failed validation by external authorities. The fix ensures the issuer is correctly generated by prioritizing RDNs, improving compliance with Spanish tax regulations. This prevents invoice errors and potential delays.
Original PR description
When a certificate contains multiple RDNs of the same type (for example several OU entries), the generated issuer is incorrect. This happens because the current implementation relies on a dictionary to sort the RDNs, causing duplicate keys to be overwritten. Steps to reproduce: - Create a certificate with multiple OU RDNs - Upload the certificate in Odoo - Generate the Facturae EDI document - Validate it using official tools: https://face.gob.es/es/facturas/validar-visualizar-facturas https://valide.redsara.es/valide/ejecutarValidarFirma/ejecutar.html The validation fails because the issuer is incorrect. This commit fixes the issue by sorting RDNs using a priority-based list, ensuring all RDNs are preserved and ordered correctly. opw-5408225 opw-5380996 opw-5253287
This update corrects a mistake in the French language version of Odoo's tax reporting functionality. Specifically, an aggregation error in box 15_1 was identified and resolved. This ensures accurate tax calculations and reporting for French businesses using the Odoo system.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/869f80b466ec2246f27e11fa823eb32ac664fb01 we made a mistake in the box 15_1. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem preventing connections to IAP Codaclean, which is essential for accurate VAT reporting. The issue was caused by a missing parameter in the connection process. This fix ensures seamless integration with Codaclean, improving compliance and data accuracy.
Original PR description
Connections to IAP Codaclean are failing because of missing `enterprise_number` param. no-task-id
This update resolves a problem where Odoo was incorrectly handling multiple tax repartition lines, resulting in broken UBL files used for electronic invoicing. The fix ensures that all tax lines are properly processed, generating valid UBL files for international trade compliance. This prevents errors in export processes.
Original PR description
When dealing with multiple repartition lines on a tax, only the first one is considered leading to a broken ubl file. Introduced by: f35aefed9347f68b6957ec790c129235a294882c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr