Daily updates from Odoo
Thursday, December 11, 2025
13 changes · 19.0
Enhancements to existing features
This update enhances the efficiency of AI embedding generation by processing large text files in optimized batches. This reduces the number of API calls, preventing errors related to token limits and improving overall performance. It's a key improvement for faster and more reliable AI-powered features.
Original PR description
## Summary This PR adds support for batching embedding requests based on each provider’s input constraints. The goal is to maximize efficiency while avoiding token or payload limit errors. By processing large text files in properly sized chunks, we minimize the number of API calls and improve overall throughput. task-id-5223195
Resolved issues and error corrections
This PR addresses several issues across various Odoo modules, including website editing, account management, MRP, and mail functionality. It fixes visual inconsistencies, corrects calculation errors, and improves performance, ultimately enhancing the user experience and data accuracy.
Original PR description
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
This update resolves an issue where a previously revoked portal user could inadvertently become the default public user for a new website. This prevented potential confidentiality risks and ensured data integrity by retaining the user's original status. The fix maintains the portal group on the revoked user, allowing for future reactivation without causing default user conflicts.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
opw-4760550
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757This update resolves an issue where a user's live chat agent name was unintentionally revealed in messages. The change ensures that when mentioning internal users in live chat, the system now uses their live chat username instead, enhancing privacy and security. This update impacts the mail module.
Original PR description
Before this commit, when mentioning an internal user in live chat it would show their name in the message body. This leads to the agent's name being leaked when a live chat username is set. This commit fixes the issue by using the user's live chat username (when available and in the context of live chats) in the generated mention element. This commit also changes `mail_message@_to_store_defaults` to send, when available, the `user_livechat_username` of the recipients of a message. task-5384305
This update adds a field to the salary configuration to allow users to specify the correct account holder name. This is crucial for payment security in Belgium, as incorrect account holder details can lead to manual payment confirmations. The change also includes fixes for testing and addresses issues found in the automated testing environment.
Original PR description
Law is now more secure and you need to have the correct name on the bank account holder otherwise payment need to be manually confirmed everytime. Therefore a field is added to the salary config to allow the user to set his account holder name separately from his actual name in case it is different. Task-5222712 [Related PR](https://github.com/odoo/odoo/pull/233965)
This update adds an index to the `sale.order.project_id` field, significantly speeding up the loading time of the project settings page. Previously, the system was performing a slow scan of the database, but this change allows for faster data retrieval and improved responsiveness.
Original PR description
Description ----------- Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant…
Description ----------- Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`. This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened. Benchmark --------- On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took: | | Before | After | |--------------|--------|-------| | Timing (hot) | 9.1s | 5ms | Reference --------- opw-5280364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239338 Forward-Port-Of: odoo/odoo#238995
This update resolves an issue preventing the local overlay feature in the HTML editor from functioning correctly. The fix ensures that the overlay is displayed as intended, improving the user experience when editing HTML content within Odoo. This enhancement ensures consistent and reliable functionality for users.
Original PR description
task-5380409
This update resolves an issue where reconciling expenses linked to multiple legacy accounts would cause the system to crash. Now, when multiple expenses share a common account, the system correctly identifies it and allows reconciliation. This ensures accountants can accurately manage historical expense data.
Original PR description
The aim of this commit is to allow accountants to be able to reconcile legacy <account.move> linked to several expenses. Context: With the refactoring of the expense module, we made the assumption that an expense paid by the company will generate one <account.move>. This is True within the new system but is wrong regarding legacy data and those weren't adapted through an upgrade script. Before this commit: Trying to reconcile an <account.move.line> that is already linked to another one from which it's <account.move> is linked to several expenses will crash while we try to get the relevant account to compute the needed_terms on the <account.move>, even if all the expenses will result in giving back the same account. After this commit: We check if all the expense retrieve the same account. If they do, we just retrieve it. If not, we throw a UserError instead of a weird singleton error. task-5113799
This update resolves an issue where the OCR process incorrectly assigned foreign currencies (like Convertible Marks) to expense reports, particularly when linked to products with standard prices. Now, users can correct the total amount after the OCR, ensuring accurate currency conversions and timely reimbursements.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236 Forward-Port-Of: odoo/enterprise#101822 Forward-Port-Of: odoo/enterprise#89093
This update resolves a potential issue in the payroll calculation process. Specifically, it adds a new 'validated days' conflict state within the work entry module, ensuring accurate tracking of validated time entries and preventing incorrect payroll calculations. This improves the reliability of payroll processing.
This update fixes issues with sending follow-up reports via snailmail, specifically addressing address validation, cover page functionality, and PDF formatting. The changes ensure the report is correctly formatted for the Pingen service and provides feedback to the user if the address is invalid, preventing silent failures.
Original PR description
#### [FIX] snailmail_account_followup: fix address, cover page and layout Currently there is the following potential problem when sending the followup report via snailmail. 1. The address generation…
#### [FIX] snailmail_account_followup: fix address, cover page and layout
Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
lead to problems with the service we use to send the actual letter.
They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
So we can not work around problems with the address generation
by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
with our current snailmail provider (Pingen). But there is no error
message about it. (Although we do have something in the usual
snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
so the user does not receive any feedback.
This could be an issue in case multiple follow-up reports are sent
at the same time.
This commit fixes these issues. (See below for details.)
(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.
(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
not rejected by Pingen because of this
But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.
(4)
We try to print / send the letter even if the address is invalid
Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
(Settings -> Accounting -> section "Customer Invoices")
- enabled to test for the cover page
- disabled to test that the address generation is adjusted
4. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
(or just search for "snailmail" in the main screen)
And select the letter
6. Download the PDF document
#### [FIX] snailmail_account_followup: forbid regenerating failed letters
The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.
Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).
After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.
Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)
#### references
opw-5160121
opw-5209504
opw-5226366
Forward-Port-Of: odoo/enterprise#101737
Forward-Port-Of: odoo/enterprise#99491This update fixes a bug in the Mexican EDI localization that occurred when refunding orders with global discounts. Previously, refunds could exceed the original order total, causing invoice generation errors. The fix limits refunds to prevent this issue, ensuring accurate invoice creation for Mexican customers.
Original PR description
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to…
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization. Steps to reproduce: ------------------- * Activate the global discount option in any PoS * Open PoS and make a sale with a global discount * Refund the sale without including the discount * Go to the backend * Go to the order list and select the 2 orders you made * Now try to create a global invoice > Observation: The global invoice is in error because the negative lines cannot be distributed correctly. Why the fix: ------------ To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense. opw-4899501 Forward-Port-Of: odoo/enterprise#101622 Forward-Port-Of: odoo/enterprise#93101
This update resolves an issue where the accounting section in Odoo Enterprise V19 was limited to SEPA countries. Now, features like the HSBC Autopay option and Batch account move lines are available for all localization settings, including the Hong Kong localization. This ensures consistent functionality across all supported countries.
Original PR description
Before this commit, the accounting section in V19 was exclusive to SEPA countries, causing some fields located in this section for other localizations to disappear. This was the case for the HK localization, which had the Payroll HSBC Autopay option inside this section, causing it not to appear, and also prevented the Batch account move lines option from being available for non-SEPA countries. With this commit, the accounting section and the Batch account move lines option are available for all localizations. This was already fixed in the master here is the PR in question odoo/enterprise#96283 task - 5268780