Monday, May 18, 2026
8 changes · saas-18.2
Resolved issues and error corrections
This fix ensures Odoo consistently chooses the expected company contact as the author when multiple contacts share the same email address. It prevents sales emails from being attributed to the wrong company partner, reducing confusion in customer communications.
Original PR description
Steps to reproduce: 1. Install `sale` and `contact` 2. Make a company contact that starts with "A" 3. Give the same email as the current company 4. Create a sale order, and remove the salesperson…
Steps to reproduce:
1. Install `sale` and `contact`
2. Make a company contact that starts with "A"
3. Give the same email as the current company
4. Create a sale order, and remove the salesperson from it.
5. Send an email using the "Send by email" button
Issue:
- The message author is resolved to the wrong company partner
Cause:
- The code gives priority to some partners, but when two partners still have the same priority,
it does not use a clear final rule to choose between them.
- In that case, the result depends on the existing order of partners, so the wrong one can be picked.
- https://github.com/odoo/odoo/blob/ea56382f804e494a86a72dab02a26134ef358c50/addons/mail/models/mail_thread.py#L2075-L2084
Solution:
- Add a final tie-break rule based on partner `id`.
- This makes the result stable and prevents a newer partner with the same email from being chosen
over the expected one when both have the same priority.
opw-5907006
Forward-Port-Of: odoo/odoo#249207The shop page now only shows a crossed-out comparison price when it is actually higher than the sale price. This avoids confusing shoppers by preventing identical prices from appearing as a discount.
Original PR description
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for…
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for the product. Issue: --- - The strikethrough appears on the compare price (25) even when the compare price equals the sales price. - The strikethrough should only appear when the compare price is strictly greater than the sales price. Root cause: --- - In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal. Solution: --- - Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2]. Before: --- <img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" /> After: --- <img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" /> [1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834 [2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346 opw-6178129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262434
A test was added to ensure customers are subscribed to their in-store delivery records. This helps make sure they receive important delivery confirmation emails for pickup orders.
Original PR description
Forward-porting of a test ensuring the partner of an in_store delivery is subscribed to the delivery, allowing him to receive email confirmation related to the delivery opw-6095396 Forward-Port-Of: odoo/odoo#263005
This update simplifies the process of fetching transactions from Codabox. Previously, users needed write access to the company record, which wasn't necessary after the initial connection was established. This change ensures smoother and more efficient transaction retrieval.
Original PR description
Currently, we use the `_l10n_be_codabox_verify_prerequisites` method before trying to fetch transactions. This method checks if the user has write access rights on res.company model which should not be mandatory to fetch transactions from codabox when the connexion is already created. opw-6108811 Forward-Port-Of: odoo/enterprise#117097
This update fixes an issue where Knowledge articles appeared in a narrow, unreadable format when printed on larger screens. The fix specifically targets the Knowledge editor's form view, preventing a default CSS rule from causing this layout problem. Now, articles print correctly in a standard format.
Original PR description
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size. See: ```scss .o_form_view.o_xxl_form_view { .o_form_view_container {…
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.
See:
```scss
.o_form_view.o_xxl_form_view {
.o_form_view_container {
width: 1px; /* List view needs a width value to recompute the size correctly */
}
}
```
However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.
Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"
=> The article is rendered in a very narrow column.
To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.
Task-5999878
Forward-Port-Of: odoo/enterprise#103259This update resolves an issue where the SD Worx report would fail when generating reports for employees without a working schedule, particularly when combined with company public holidays. The fix ensures the report gracefully handles missing employee data, preventing errors and improving report reliability.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll_sd_worx module - Create a public holiday in one company without a working schedule - Create an employee that doesn't have a working schedule nor a contract - Try to generate the sd worx report - A traceback will pop-up ## Cause: Since we fetch all employees if we have a public holiday with no schedule, this puts us in a scenario where we try to access a key in that doesn't exist and it will trigger a KeyError ## Fix: Make sure we fallback on an empty recordset in case we don't have the employee in the key list of the dict we are checking opw-5500070 Forward-Port-Of: odoo/enterprise#117268
This update fixes inconsistencies in the XML structure used for Swedish payments (ISO 20022). Specifically, it ensures the correct format for key data fields like the bank identifier, enhancing compatibility with Swedish banking systems and improving payment processing accuracy. This resolves a technical issue impacting the reliable transmission of payment data.
Original PR description
Here is few fixes added to the swedish iso 20022 XML: - CdtrAgt seems to be always mandatory, change the condition in `_skip_CdtrAgt` to always use the CdtrAgt if payment_method is iso20022_se - The `_is_se_bban` is too restrictive, this should be always True when payment method is swedish iso - The `FinInstnId` node can either contain BIC or ClrSysMmbId. But as ClrSysMmbId seems to change from one bank to another, it's more relevant to always use the BIC. opw-5395736 Forward-Port-Of: odoo/enterprise#114662
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. By renaming the duplicate ID, we've ensured that approval rules are applied correctly based on user and manager roles, improving the reliability of the approval process. This change addresses a minor technical problem with no impact on users.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010 Forward-Port-Of: odoo/enterprise#113480