Monday, April 27, 2026
46 changes · saas-19.1
Resolved issues and error corrections
This update optimizes the performance of the project list view, making it significantly faster. Previously, the system was slow rendering large lists due to inefficient calculations. Now, the system only checks for company differences once, dramatically reducing loading times.
Original PR description
Before this commit, to render the table, the project list view computed the list of selected records once for each cell, and then iterated over that selection to check whether selected projects were all associated with the same company (to set the stage_id field readonly if not). However, computing the selection requires to iterate over all records, so the rendering was O(n^2). As a consequence, the rendering of (not so) large tables was very slow (~1s for 80 records). With this commit, we compute only once for the whole table whether the selection contains records from different companies. Forward-Port-Of: odoo/odoo#260752
This update corrects a calculation error in the HK payroll reports (IR56B/F/G) by adding adjustments for global reimbursements and deductions. This ensures that the reported taxable income aligns more accurately with Hong Kong's tax regulations, improving financial reporting reliability.
Original PR description
Added GLOBAL_REIMBURSEMENT and GLOBAL_DEDUCTION to the AmtOfSalary calculation for IR56B/F/G reports. This ensures adjustments are properly reflected in taxable income totals. task-6126661 Forward-Port-Of: odoo/enterprise#114041
This update fixes an issue where MyInvois consolidation documents incorrectly combined invoices with gaps in their sequence numbers. The system now accurately splits large batches into multiple XML lines when invoices are missing, ensuring correct invoice generation and reducing potential errors. This improves the reliability of the consolidated invoice process.
Original PR description
When generating a consolidated MyInvois document, the system must split the batch into multiple XML lines if there are gaps in the sequence (e.g., if an invoice in the middle of the range was already sent individually) The previous logic attempted to detect these gaps by searching the database(`account.move`) for any invoices that fell within the sequence range and lacked a EDI document. Because this search would find the "missing" invoices, it would fill the gap and fail to detect it and produce a single consolidated line. This commit replaces the search and relies only on the selected recordset, along with the addition of sorted `sequence_number` for gap detection and adds test for handling consolidation of broken sequences. Task: [6057214](https://www.odoo.com/odoo/project.task/6057214) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows users to create pricelist items that combine subscription and one-time sale options. Previously, products designated as recurring invoices were automatically excluded from pricelist configurations. Now, pricelists can accommodate ‘hybrid’ products, providing greater flexibility for sales models.
Original PR description
Currently, the pricelist item form strictly filters out any product marked as a recurring invoice (`recurring_invoice` = True). This prevents users from defining standard pricelist rules for "hybrid" products that are subscriptions but also have `allow_one_time_sale` enabled. This commit updates the domain on `product_tmpl_id` in the pricelist item form to include an OR condition. Products are now visible if they are NOT a recurring invoice, OR if they explicitly allow one-time sales. Task: 6052066 Forward-Port-Of: odoo/enterprise#111937
This update resolves an issue where exporting bills from the print function only included records visible on the current page. The fix ensures that all bills selected, regardless of their visibility on the page, are included in the export. This improves the accuracy and usability of the bill export process.
Original PR description
Right now when selecting all the records in the current page from bills list view and there are some other records not displayed in this page then click on "select all X" where X is all the records either displayed in the current page or not it shows "selected X", however when trying to export them through the print button it only exports the ones that are in the current page, this PR fixes this bug. opw-6129628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261058
This update corrects a previous error in Odoo's French reporting module. Accounts 657 and 757, introduced by a recent French accounting reform (PCG 2025), are now correctly classified as current operations, ensuring accurate profit and loss statements. This resolves a mismatch previously impacting financial reporting.
Original PR description
…tions As part of the PCG 2025 reform in France, accounts 657 and 757 were introduced to handle capital gains and losses on the disposal of tangible and intangible assets related to normal, current activities. Previously, Odoo incorrectly categorized these under exceptional items which led to mismatches in the P&L. Source: https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/PCG--1er-janvier-2025.pdf Relevant excerpts: <img width="630" height="372" alt="image" src="https://github.com/user-attachments/assets/88a66dac-1cc0-4a33-a902-edb6b626f18f" /> <img width="631" height="318" alt="image" src="https://github.com/user-attachments/assets/403b65dc-20ba-447e-937d-20575f1f45ab" /> opw-6105764 Forward-Port-Of: odoo/enterprise#115054 Forward-Port-Of: odoo/enterprise#114837
This update corrects a problem where invoices sent to Chorus Pro via Peppol in France were being rejected due to spaces in the SIRET number. The fix ensures SIRET numbers are exactly 14 characters long, resolving compatibility issues with the Chorus Pro system. This prevents invoice delivery failures and ensures accurate data transmission.
Original PR description
### Issue: When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected ### Cause: SIRET values must be exactly 14…
### Issue: When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected ### Cause: SIRET values must be exactly 14 characters long However, spaces were not removed when generating the XML, leading to invalid values in: `<cbc:ID schemeID="0009">` and `<cbc:CompanyID schemeID="0009">` This issue can occur for both the company and the customer SIRET, as both rely on `company_registry` As a result, Chorus Pro rejects the document due to invalid SIRET length ### Steps to reproduce: - Install `l10n_fr_facturx_chorus_pro` and switch to `FR Company` - Enable and Activate Peppol in Settings - Go in Settings > Users & Companies > Companies and open the `FR Company` - Add spaces in the Company ID: 968 515 7590 5808 - Create a Customer (Country: France, VAT: FR23334175221, Company ID/Siret: 123 456 7890 1234) - In the customer's Invoicing Tab (Invoice sending: by Peppol, eInvoice format: EU Standard (Peppol Bis 3.0), France SIRET: 11000201100044) - Create and Send an invoice via Peppol (Your Customer, any line with a tax) - Open the XML - Check the IDs and CompanyIDs in the document Before the fix, there is missing spaces opw-6047840 Forward-Port-Of: odoo/odoo#260578
This update fixes an issue where staff on leave were incorrectly showing as available for appointments through Google Calendar. The team removed unnecessary code related to scheduling offsets, as appointment slots are now pre-defined in the Google Calendar feeds. This ensures accurate availability and a better user experience.
Original PR description
Resources on leave were still showing as available in BatchAvailabilityLookup responses because unavailabilities were not checked. Also remove the min_schedule_hours offset copied from the frontend logic. It is not relevant for Google Reserve as slots are pre-built in the feeds. Task-6150788 Forward-Port-Of: odoo/enterprise#114793
This update ensures that TicketBai QR codes are correctly generated when a paid order is reprinted after reloading the POS system. Previously, the QR code wasn't being set during the initial loading of historical orders, leading to missing codes. This fix guarantees accurate QR codes for seamless order processing.
Original PR description
When printing a paid order after reloading the POS, the TicketBai QR code was missing. The QR source (l10n_es_pos_tbai_qrsrc) was only set during _postPushOrderResolve after payment, but not when loading historical orders from the backend. opw-6068076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261102 Forward-Port-Of: odoo/odoo#259372
This update resolves an issue where CODA bank statement imports failed due to discrepancies in detail sequence numbers provided by some banks. The fix allows for incremented 3.2 detail sequences, aligning with bank file formats and preventing import errors. This ensures seamless integration of bank statement data into Odoo.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
This update fixes an issue where menu links with spaces in their URLs wouldn't correctly point to newly created pages. The fix ensures that menus with spaceful URLs are properly linked, and a warning is now displayed in the menu editor to alert users about potential issues with spaces in URLs. This improves the user experience and prevents broken links.
Original PR description
When a menu item URL contains a space and has no leading slash (e.g., "some url"), creating a page from its 404 screen does not link the menu to the newly created page. The menu keeps pointing to a…
When a menu item URL contains a space and has no leading slash (e.g., "some url"), creating a page from its 404 screen does not link the menu to the newly created page. The menu keeps pointing to a 404. **Steps to reproduce**: 1. Create a menu item with a URL containing spaces and no leading slash (e.g., "some url"). 2. Click the menu item -> a 404 page is displayed (expected). 3. Click "Create Page" -> the page is created and saved. 4. Click the menu item again -> it still returns a 404 (unexpected). **Issue**: During page creation, the path is slugified (e.g., "some url" -> "/some-url"). The controller then tries to link the menu to the new page by setting `page_id`. However, `pagenew()` only searches for menu URLs with a leading slash, so a menu saved as "some url" is not found when searching for "/some url". As a result, `page_id` is never set, and `_clean_url()` keeps resolving the menu to "/some url" instead of the page's actual URL "/some-url". Menus without spaces (e.g., "mypage") have the same issue where `page_id` is not set, but since `_clean_url()` prepends "/" and renders "/mypage", which matches the new page URL, the menu still resolves correctly. **Fix**: Match both URL formats (with and without leading slash) when linking a menu to a newly created page. Additionally, a warning is now shown in the menu editor when a URL contains spaces, since spaces are slugified during page creation, which could cause confusion. (Note: this is only a warning - URLs with spaces are still allowed.) task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261208 Forward-Port-Of: odoo/odoo#248967
This update resolves an issue where mobile money transactions using DPO Pay were being declined due to a character limit exceeding 15 characters in the transaction ID. The fix ensures the transaction ID adheres to DPO Pay's requirements, preventing these errors and improving payment processing reliability for mobile money users.
Original PR description
Steps to reproduce: = - Configure a payment method with DPO Pay (Mobile Money). - Open POS. - Add a product and initiate a transaction using the DPO Pay mobile money method. - Process the transaction on the terminal device. Issue: = - Transaction is declined with error: - "Data mismatch in one of the fields - OriginatorSourceID exceeds maximum length of 15 characters." Fix: = - Updated `sourceId` generation logic for mobile money transactions. - Ensured `sourceId` complies with DPO Pay constraints (maximum 15 alphanumeric characters), as enforced in recent DPO Pay updates. - Prevented transaction failures caused by oversized `sourceId`. task-6143491 Forward-Port-Of: odoo/odoo#260553
This update fixes an issue where invoices generated with Mexican tax settings were incorrectly rounding the total amount. The change reverts to the standard mixed rounding mode for taxes, ensuring accurate invoice totals. This resolves a discrepancy identified during testing and aligns with current tax regulations for Mexico.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_mx. 2. Change the included in price settings to 'Tax included' for a 16% tax and a 53% tax. 3. Create a invoice with a product with a unit price of 360, add the 53% tax and then the 16% tax. 4. Notice the total of the invoice is 360.01 instead of 360. The issue was discussed with (las), l10n_mx_edi should no longer require to override the rounding mode for taxes. opw-5963855 Forward-Port-Of: odoo/odoo#255574
This update corrects a bug that was disrupting the testing process for the l10n_mx_edi module, which handles Mexican tax reporting. The rounding mode was temporarily changed, breaking the associated tests. This fix restores the original rounding configuration to ensure accurate test results and continued functionality of the module.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
This update corrects a problem where invoices sent to DIAN were incorrectly marked as failed, preventing proper QR code generation. The system now handles expected status update failures from DIAN, ensuring invoices are accurately reflected with the correct state. This resolves an issue impacting invoice printing and reporting.
Original PR description
Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document. The problem with that approach is that we will regularly send status…
Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document. The problem with that approach is that we will regularly send status updates to DIAN after the invoice was successfully submitted via the status cron here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L484 Those status updates are expected to fail a certain number of times (typically when no commercial status information is available, or in other terms when `l10n_co_dian_commercial_state` is still in `'pending'`). As a result, an invoice successfully transmitted to DIAN could still end up with a `l10n_co_dian_state` not set to `'invoice_accepted'`. This leads, among other things to a QR code that cannot be reprinted as the logic here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L225 determines which template to render based on that state. The issue cannot be easily reproduced or tested as `l10n_co_dian.document` are generated almost only in prod scenarios. The most common setup where the error happens is for invoices that have 2 DIAN documents: 1. the first (oldest, bottom-most) one reflects acceptance of the invoice sending by DIAN (`state = 'invoice_accepted'`) 2. the second one (most recent, top-most), which reflects the latest query for commercial status update by the cron and which failed (`state = 'invoice_rejected'` and the error message reflects the lack of commercial events) opw-6108318 opw-5931442 opw-6034035 Forward-Port-Of: odoo/enterprise#113929
This update resolves a technical error that was preventing the point-of-sale system from functioning correctly. The issue stemmed from a previous code change that hadn't been fully integrated into the saas-19.1 environment. This fix ensures the currency testing within the pricelist feature is working as expected.
Original PR description
Fixes runbot error https://runbot.odoo.com/odoo/runbot.build.error/243302 Needed because commit 9674a712d951 (https://github.com/odoo/odoo/pull/252521) is not yet forward-ported to saas-19.1.
This update fixes an issue where group payments were incorrectly applying the full amount of multiple bills to a single payment. Now, group payments accurately reflect the first installment of bills with multiple payment terms, ensuring correct accounting and payment processing. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce: 1- Install Accounting and make sure "Batch Payments" is enabled in settings 2- Go to [Accounting -> Vendors -> Bills] 3- Create two bills for the same vendor, ensuring one of them has multiple installments (i.e payment term with 3 installments) 4- Confirm the bills 5- In list view, select both bills and another bill from a different vendor and click on Pay 6- Select "Group Payments" and confirm the payment Description of issue: The batch payment of the first vendor has the full amount for both bills Expected behavior: The payment should consider the full amount of the first bill and the first installment only of the second bill opw-5969972 Forward-Port-Of: odoo/odoo#260933 Forward-Port-Of: odoo/odoo#257871
This update fixes an issue where product URLs in multilingual websites incorrectly included the category. Now, the canonical URL for products in non-default languages accurately reflects the product itself, without the category prefix. This ensures consistent and correct links for customers browsing in different languages.
Original PR description
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to…
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to the shop in fr. 4- Open the category, then open the product. 5- Open console, and search for canonical. As you see, in the second language, the canonical address includes the category address which is wrong. If you visit in the default lang, the canonical correctly refers to the url without category. Cause: --- This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself. opw-6086206 Forward-Port-Of: odoo/odoo#258834
This update ensures that stock is properly reserved against waiting delivery orders, even when the destination warehouse is a child location. Previously, incoming stock wasn't automatically linked to these waiting orders, leading to potential stock discrepancies. This fix improves inventory accuracy and order fulfillment reliability.
Original PR description
Steps to reproduce: - Create a storable product with no stock on hand - Create a delivery order from WH/Stock → state is "Waiting for Availability" - Create a receipt with destination WH/Stock/Shelf1 and validate it Problem: The incoming quantity is not reserved against the waiting delivery, even though WH/Stock/Shelf1 is a child of WH/Stock. opw-6124879 Forward-Port-Of: odoo/odoo#261072
This update fixes a potential issue where users could falsely validate signatures in draw mode using Firefox and similar browsers. Now, the system requires a visible signature drawing before validation can occur, ensuring signatures are only confirmed when genuinely signed.
Original PR description
On Firefox and similar browsers, it was possible in some cases to validate a signature field in draw mode without actually drawing a signature, allowing the document signature to be confirmed with an empty signature. This change ensures that a signature field in draw mode can only be validated when the signer has effectively drawn a visible signature. task-6117312 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#259100
This update fixes a minor display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, making it easier to understand and interpret.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update resolves an issue where copying and pasting content from the blog post editor unexpectedly modified the original field data. The fix adds a setting to the editor to prevent copying outside of the editable area, ensuring data integrity and preventing unintended changes to the source records.
Original PR description
Problem: When copying the blog post title and pasting it elsewhere, editing the pasted content unexpectedly modifies the original field source. Cause: The copied HTML retains `data-oe-*` attributes, causing the editor to treat the pasted content as a field binding and propagate changes back to the original record. Solution: `contenteditable="true"` should be added on fields (`o_savable`) to prevent copying outside of savable area. Steps to Reproduce: - Copy title of blog post. - Paste it elsewhere in editable. - Edit the pasted text. - Observe the original field source also changes. opw-6105714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes focus on enhancing the overall experience and usability of the timesheet management process. The improvements are intended to streamline workflows and reduce potential confusion.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness.
This update resolves an issue where CFDI generation for payroll payslips failed with errors due to discrepancies in decimal precision. The fix ensures all payroll amounts are rounded to 2 decimal places before XML formatting, aligning with CFDI requirements and preventing errors. This ensures accurate CFDI generation and compliance.
Original PR description
Currently, if the company is configured with a 4-decimal currency, the CFDI generation for payslips might fail with NOM111 and CFDI40119 errors. This occurs because the calculation of totals and subtotals uses the raw unrounded floats, which can cause penny differences when the XML template formats the individual lines to 2 decimal places. This commit forces all payroll concept amounts to be explicitly rounded to 2 decimal places before accumulating the totals. This ensures that the sum of the formatted XML nodes precisely matches the total and subtotal values reported in the CFDI. Accounting might require a higher decimal precision for the company's currency (e.g., 4 decimals for inventory). However, payroll CFDI stamping strictly requires 2 decimal precision. This fix isolates the payroll CFDI calculations from the company's currency settings. Forward-Port-Of: odoo/enterprise#114936
This update fixes a rare crash that could occur when canceling drag sequences in the Odoo application. The issue stemmed from a timing problem with how the system registered and executed cancellation callbacks. This change ensures the callback is available before assignment, preventing the crash and improving overall stability.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261014 Forward-Port-Of: odoo/odoo#260594