Thursday, April 16, 2026
22 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where Odoo invoices sent via Peppol were being rejected due to incorrect tax calculations. The fix ensures that the TaxableAmount is consistently calculated across all tax categories, including those with discounts and fractional prices, aligning with Peppol's requirements.
Original PR description
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with…
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84 3. Send via Peppol 4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc. When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection. Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally. opw-6093243 Forward-Port-Of: odoo/odoo#258909
This update resolves an issue where a Peppol document would repeatedly be created when a user removed their journal configuration. The fix ensures that acknowledgements are correctly sent to IAP, preventing unnecessary document duplication and improving the reliability of Peppol document processing. This ensures accurate data exchange and avoids potential delays.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/odoo#259330
This update resolves an issue where a new Peppol document was incorrectly created and repeatedly generated when a user removed their journal configuration. The fix ensures that acknowledgements are properly sent to IAP, preventing duplicate document creation and improving the reliability of the Peppol integration.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/enterprise#113922
This update resolves an error that occurred when users tried to access ticket links after an attendee was removed from an event. The fix prevents a technical error (IndexError) by gracefully handling empty attendee lists, ensuring ticket links always work correctly.
Original PR description
Currently, an error occurs when accessing the ticket link after the related attendee has been deleted. **Steps to Reproduce:** - Install the **Events** module. - Create a new event. - Create an attendee with a valid email ID. - Make sure the email is sent successfully. - Delete the attendee for the event. - From the received email, try to click on the **"View Tickets"** link. **Error:** `IndexError - tuple index out of range` **Cause:** The controller filters registrations using the provided `registration_ids`, but when the attendee is deleted, the resulting recordset becomes empty. It raises an error when trying to access the first element of an empty recordset. **Fix:** This commit handles empty recordsets by returning early when no registrations are found. sentry-7357927405
This update fixes an issue where transaction date ranges were sometimes inaccurate when importing data from Codabox. The change ensures that the date range used for importing transactions is always the latest available date – either the Codabox lock date or the last statement date – preventing data discrepancies.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update simplifies the process of reloading your chart of accounts. Previously, a confusing error message prompted users to update the localization app. Now, a clear warning directs users directly to the relevant apps, making the process easier and more intuitive.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly. Forward-Port-Of: odoo/odoo#259398 Forward-Port-Of: odoo/odoo#257515
This update fixes an issue where tax group changes could cause errors due to account updates not being synchronized. The change ensures that account relationships within tax groups are only updated when necessary, preventing constraint violations and improving system stability. This primarily impacts how tax groups are managed and related to accounts.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This update resolves a technical issue that prevented demo flows from running correctly when new Peppol and Nemhandel response data was added. The team corrected a missing key in the demo utility files, ensuring demo mode now functions without errors. This improves the reliability of our demo environment.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
This update fixes an issue where floors were incorrectly displayed in the restaurant's point-of-sale system. Previously, floors were loaded through indirect processes, leading to inaccurate floor selections. Now, the system correctly uses the configured floor IDs for each POS configuration, ensuring accurate floor selection for restaurant orders.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258178 Forward-Port-Of: odoo/odoo#257113
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix addresses a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO companies.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update removes a confusing tooltip from the calendar popover for boolean fields. The tooltip was displaying unnecessary HTML content, creating a poor user experience. This change simplifies the calendar interface and improves usability.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259069 Forward-Port-Of: odoo/odoo#259011
This update resolves an issue where images on the website weren't displaying correctly on deeper pages. The fix adds missing forward slashes to image source URLs, ensuring the browser correctly interprets them. This ensures all website images, including those on product pages, display properly.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#258879
This update resolves an issue where the Avatax integration in the express checkout process was causing the confirmation button to become unresponsive. The fix removes unnecessary external API calls related to tax calculations, streamlining the checkout flow and improving stability. This change addresses a bug related to error handling during tax calculations.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259229 Forward-Port-Of: odoo/odoo#256692
This update resolves an issue where the checkout process became unresponsive when using the Avatax module with the Brazilian localization. The previous code was unnecessarily calling external tax APIs, leading to errors and preventing users from completing their purchases. This fix removes the unnecessary API calls, restoring the checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
This update resolves a technical error that prevented users from selecting a store when the store's address information (city or street) was incomplete. The fix ensures the system correctly handles missing address details, improving the reliability of the Click & Collect feature. This prevents errors and ensures a smoother shopping experience for customers.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137 Forward-Port-Of: odoo/odoo#259164
This update addresses a regulatory requirement in Mexico (CFDI) that prohibits signing payments registered in the future. The code now filters out future payments, removing the 'Update Payments' button when only future payments are present. This ensures compliance and avoids potential issues with government regulations.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#113945 Forward-Port-Of: odoo/enterprise#112320
This update fixes a potential issue where the SD Worx payroll report was defaulting to the current year, leading to test failures. The change ensures the correct year is always referenced, preventing future problems and ensuring accurate reporting. This improves the reliability of payroll data.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
This update resolves a visual inconsistency where styling applied to images (like rounded corners or shadows) was incorrectly carried over when users replaced images with icons in the To-do app. Now, the system automatically removes these styling classes, ensuring icons appear with their intended, clean design. This improves the overall user experience and consistency of the application.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258060
This update resolves an issue where all employees were loaded into POS sessions, regardless of employee type. Now, the system only loads employees based on the POS configuration, improving performance and reducing unnecessary data loading. This change ensures a smoother and more efficient POS experience.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a recent issue where generated invoice PDFs weren't displaying company information correctly. The change reverses the order of the issuer and receiver addresses, resolving customer complaints. Switching to a simpler internal layout ensures the document clearly identifies it as an Odoo-generated invoice.
Original PR description
When an invoice is received through Peppol, it may not contain an embed PDF. If no, we create one. However, due to several complaints, this commit exchange the place of the issuer and receiver addresses and information. Company information were rendered in the header of the document through the external_layout. Switching to the internal layer avoid doing so. opw-5980655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254693
This update fixes an issue where web applications could incorrectly access data due to cached records. Specifically, when users edit records with x2many fields, the system now filters these records based on the user's current permissions before displaying them, preventing access errors and ensuring data security. This improves the reliability of web-based features.
Original PR description
**Description of the issue/feature this PR addresses**: web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record…
**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).
**Example**:
- **Context**:
- Two companies exist: Company A and Company B.
- Two users exist: User A and User B.
- User A can only access Company A (company_ids=[A], company_id=A).
- User B is linked to both companies (company_ids=[A, B], company_id=A).
- The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
- User A edits User B and saves the form.
- **Steps**:
- User A performs a web_read to load User B: company_ids contains only Company A.
- User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.
**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.
**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.
Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904This update fixes an inconsistency in how rental prices are calculated when dealing with time-zoned dates. Previously, using relativedelta on UTC dates resulted in incorrect price calculations. Now, the system accurately determines the rental duration based on the start and end dates in their respective time zones, ensuring consistent pricing across different locations.
Original PR description
Relativedelta on UTC dates or time-zoned dates doesn't return the same result. In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work…
Relativedelta on UTC dates or time-zoned dates doesn't return the same result. In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates. Example: Consider a website in UTC+1 (Brussels timezone DST off). And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). Converted in UTC for the back-end, we have: from the 30/11/2025 23h00 to the 31/12/2025 22h59. relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow: 30/11/2025 23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. Time difference = 1 month, 23 hours, 59 minutes. Price = 2 months. Consider a second rental from the 01/01/2026 to the 31/01/2026. 31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. Time difference = 30 days, 23 hours, 59 minutes. Price = 1 month. opw-5130762 Forward-Port-Of: odoo/enterprise#101714 Forward-Port-Of: odoo/enterprise#98571