Thursday, April 2, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update fixes a flaw in the website user leaderboard that incorrectly ranked users based on their all-time karma. The change ensures users are now accurately displayed based on their recent activity (week or month), improving the user experience and data accuracy. This was achieved by pre-calculating karma gains at the database level.
Original PR description
[FIX] website_profile, gamification: fix weekly/monthly leaderboards Prior to this commit, the leaderboard pagination logic was flawed when filtering by specific time periods (e.g., "This Week" or…
[FIX] website_profile, gamification: fix weekly/monthly leaderboards Prior to this commit, the leaderboard pagination logic was flawed when filtering by specific time periods (e.g., "This Week" or "This Month"). The system would first retrieve users sorted by their *all-time* global karma, apply pagination (taking the top X users), and only then calculate the karma gain for the specific period for those few users. This caused users with high recent activity but low all-time karma to only be displayed much later in the page order than they should. This commit fixes the issue by introducing a pre-search step that calculates the karma gain for the requested period at the database level. Pagination is now applied to this specific result set, ensuring users are correctly ranked by their actual performance during that week or month. Note: A new method `_get_users_by_tracking_karma_gain` was added to `res.users` to handle this logic. This approach was chosen to strictly preserve the signature of existing methods for the stable version. A distinct refactor to unify these calculation methods is planned for the master branch. Steps to reproduce: - Install the eLearning module. - Create a few users with different karma_points (more than 25 to have 2 pages). - Go to /profile/users. - Group by week. - Paginate, and you will notice that the order is wrong; the first user on the second page might have more points than users on the first page. Also, when the logged-in user is not on that page, they do not appear at the bottom. task-5344657 opw-3979785 Forward-Port-Of: odoo/odoo#256908 Forward-Port-Of: odoo/odoo#176626
This update fixes a problem where the translation editor on appointment details pages (when guests are allowed) would break due to newline characters in the data. The fix uses a more robust regex to handle these characters, ensuring translations are correctly displayed. This improves the user experience for appointment scheduling with guest options.
Original PR description
When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue. Steps To Reproduce: 1. Create an appointment. 2.…
When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue. Steps To Reproduce: 1. Create an appointment. 2. Go to the "Options" tab, and click on "Allow Guests". 3. Go to the web page for the appointment, select the data and time. 4. Now, on the details page, go to any other language than the default, and click on edit/translate. 5. The issue occurs. The issue occurs when the regex tries to match the placeholder where the guests are added, which is enabled by the allow_guests. It contains strings with newline characters. The regex fails to take into consideration for these newlines and breaks causing the issue to appear. To fix the issue, we'll use regex to account for the new lines. Also the fix adapts [this commit](https://github.com/odoo/odoo/commit/bc30d2592d4a7913eddf30bac8be2d94b6c22ad4) to work with the [website refactoring](https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2) opw-5412775
This update resolves a crash that occurred when users deleted fields within the website form builder. The issue stemmed from the way website forms were inadvertently treated as XML, leading to parsing errors. The fix ensures that field deletions are handled correctly, preventing disruptions to website functionality.
Original PR description
Steps to reproduce ================== tl;dr: html fields are parsed as xml - Go to Helpdesk > Tickets > Warranty - Open studio - Add a new text field named "TEST" - Remove it from the view - Exit studio - Go to the website - Click on new - Add a new blogpost - Set a title and save - Click on "Contact & Forms" - Click on the first block - Click on the form - Change the form action to "Create a ticket" - Click on "+ Field" - Change the Type selection to "TEST" - Click on save - Enable debug mode - Go to "Settings / Technical / Database Structure / Fields" - Type x_ in the search bar and press enter - Delete the field => lxml.etree.XMLSyntaxError Cause of the issue ================== When deleting a field, `_check_if_used_in_website_form` is called to prevent the deletion if a field is used in an html field. The html fields were parsed with an xml parser.. opw-5946029 Forward-Port-Of: odoo/odoo#256066
This update resolves a problem where website assets weren't loading correctly on replica Odoo instances after a theme change. The fix ensures that newly generated asset bundles are properly built from the primary instance, preventing errors when accessing these assets via read-only routes. This improves website functionality for users on replica instances.
Original PR description
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created…
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env. In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle. Steps to reproduce: 1. Configure Odoo with a PostgreSQL primary/replica setup. 2. Open a website in edit mode. 3. Trigger an asset regeneration (for example by changing a theme color). 4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle. Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env. opw-6034833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255530
This update fixes an issue where email notifications were incorrectly routing external emails as internal aliases. The change enhances the system's ability to accurately filter internal aliases based on allowed domains, preventing potential notification errors and ensuring correct email delivery. This improves the reliability of our notification system.
Original PR description
The fix introduced in https://github.com/odoo/odoo/pull/216737 can lead to "over-eager" filtering when an external email address matches a localpart (left part) alias in a input email list contains…
The fix introduced in https://github.com/odoo/odoo/pull/216737 can lead to "over-eager" filtering when an external email address matches a localpart (left part) alias in a input email list contains internal emails (aliases to filter) AND external email addresses (should not be filtered). The `_find_aliases` method is used to identify internal system emails (aliases, bounces, catchalls) to prevent mail loops and ensure correct recipient filtering during notification grouping. Before this fix, when the `mail.catchall.domain.allowed` system parameter was set, the logic for local-part aliases (where `alias_incoming_local` is True) failed to correctly associate the local part with the allowed domains. This resulted in external email addressed being returned by the system, potentially leading to incorrect notification routing. We now use a more robust approach: - Pre-filter local parts based on the allowed domains to reduce DB load. - Utilize Python Sets for O(1) lookups of static and local aliases - Explicitly validate the (local_part, domain) combo during the final filtering. Example Scenario: - Config: mail.catchall.domain.allowed = "test1.com,test2.com" - Alias: "info" (alias_incoming_local=True) - Input: ["info@test1.com", "info@test3.com"] ### Output Before Fix: ["info@test1.com", "info@test3.com"] (The function failed to recognize info@test3.com as an external alias to be ignored based on the `mail.catchall.domain.allowed` config) ### Output After Fix: ["info@test1.com"] (Correctly identifies the internal alias tob filtered while ignoring the external one) OPW-5469264 OPW-5504201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244272
This update fixes an issue where PEPPOL self-billing invoices weren't correctly including the delivery address and GLN number in the XML export. The change ensures the delivery address from the company partner is used, resolving a data discrepancy and improving PEPPOL invoice accuracy. This ensures compliance and proper invoice processing.
Original PR description
**PROBLEM** When selfbilling with peppol, we have no way of providing a GLN number, or modifying the delivery address. Even if we create a delivery address partner on the current company partner, it's not taken into account. **STEP TO REPRODUCE** 1. Create a delivery address on the current company, set up a GLN number. 2. Configure the purchase journal to do selfbilling. 3. Create a vendor bill with this journal and send it using peppol. 4. Download the xml, and look for the Delivery tag, and notice it doesn't have the GLN number. **FIX** We search for a delivery address on the current company. If there is one, we use it for the Delivery tag. opw-6014374 Forward-Port-Of: odoo/odoo#252970
This update fixes an issue where shipping costs were incorrectly calculated when using combo products with delivery methods based on quantity. The fix ensures that shipping costs accurately reflect the quantity of individual components within the combo, preventing inflated shipping charges. This improves the accuracy of order pricing and enhances the customer experience.
Original PR description
**Issue:**
When using a delivery method that has a shipping cost based on the quantity of the product, the shipping cost is incorrect if there is a combo product. The quantity of the combo product was added to the total quantity of its components.
**How to reproduce:**
1. Create a delivery method based on rules.
2. Create a rule that uses the quantity (ex: 0$ + 5$ times the quantity)
3. Create a combo product
4. Create a sale order and add the combo product to it
5. Add the shipping
=> The shipping cost is incorrect
ex: With 1 combo choice, the shipping cost is doubled
**Fix:**
When calculating shipping cost, skip the sale order line of the combo product and only use the sale order lines of the components.
opw-6016209
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256978
Forward-Port-Of: odoo/odoo#256055This update fixes an issue where the Mod 347 BOE export incorrectly used 'X' as an indicator for declarations. The change ensures the correct 'C' for complementary and 'S' for substitute declarations are used, aligning with AEAT specifications and preventing file rejection by the tax authority. This ensures accurate tax reporting for Spanish companies.
Original PR description
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the…
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company` - Navigate to Accounting > Reporting > Tax Report - From the smart button, select `Report: Tax Report (Mod 347) (ES)` - Download the BOE file using the dropdown. - In the wizard: - Enable `Substitutive Declaration` or `Complementary Declaration` - Set `Previous Report Number` (e.g., 123456789) - Click `Generate BOE` - Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required) **Observation:** AEAT does not recognize 'X' as a valid indicator for substitutive or complementary declarations and interprets the file as a standard return. **Root Cause:** At [1], the BOE Mod 347 generation writes 'X' for both substitute and complementary declarations. **Fix:** This commit ensures the file contains correct indicators: - 'C' for `complementary declarations` - 'S' for `substitute declarations` This aligns Modelo 347 with AEAT specifications and ensures consistency with the implementation of Modelo 349 at [2]. Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html [1]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062 [2]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491 opw-6048711 Forward-Port-Of: odoo/enterprise#112566