Tuesday, March 25, 2025
50 changes
Resolved issues and error corrections
Odoo now correctly reads mail server capabilities needed to detect the maximum allowed email size. This helps prevent email sending issues caused by missing size-limit information.
Original PR description
The automatic detection of maximum email size was not working anymore. After this commit, the `esmtp_features` attribute is added, to ensure reliable detection of the email's size. opw-4673107 cc: @Julien00859 @Abridbus
Product images in kanban views now keep the same browser cache URL when the image field comes from the same record. This avoids repeatedly downloading the same images after opening a product and returning to the list, making navigation faster and reducing unnecessary network usage.
Original PR description
Steps to reproduce ================== - Go to the products kanban view - Open a record - Go back to the kanban view => Every product image is downloaded again Cause of the issue ==================…
Steps to reproduce
==================
- Go to the products kanban view
- Open a record
- Go back to the kanban view => Every product image is downloaded again
Cause of the issue
==================
There is a unique query param in the url as the browser doesn't fetch twice the same image from the same url in the same session.
For non related fields, we use the last record update as a unique timestamp.
For related fields, since we don't have the information about the last update, we generate a unique timestamp when instanciating an ImageField component.
It can happen that a related field points to the same model.
This is the case here where the product kanban view uses the "image_128" field.
```py
image_1920 = fields.Image("Image", max_width=1920, max_height=1920)
image_128 = fields.Image("Image 128", related="image_1920", max_width=128, max_height=128, store=True)
```
Solution
========
When a field is related but the relation points to the same model, we can still use the last record update
We can try to detect this by checking if there is a dot in the related path.This update adds automated coverage to ensure Point of Sale orders can be validated when the currency does not use decimal places. It helps prevent checkout issues in countries or setups using whole-unit currencies.
Original PR description
Before this commit, there was no test to ensure that orders could be validated correctly when using a currency with zero decimal places. This commit adds a test to validate an order with a zero decimal places currency, ensuring that the system handles such cases without errors. opw-4595028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users who do not have permission to interact with comments will no longer see emoji reaction buttons. This prevents confusing error screens and creates a smoother experience on product and course review pages.
Original PR description
Before this PR: - A user with no access attempts to react with emojis on a comment, resulting in a traceback. After this PR: - The buttons for adding emoji reactions to comments will be hidden for that users. Task-4452408
This fixes a document layout issue where long customer address details could overlap with the shipping address on DIN 5008 quotation PDFs. Businesses using this German document format will get clearer, more professional printed quotes when customer addresses contain many lines.
Original PR description
The aim of this commit is to fix a display bug where the shipping adress is overlapping the address element when too many address lines are present Steps to reproduce: - Install l10n_din5008_sale - Configure the document to use the din5008 layout - Create a UK customer with all the adress fields filled + phone - Create a quotation for that customer and Print the PDF Quote opw-4575257  Becomes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Installing the Point of Sale event module no longer fails if the default Event Registration product was previously deleted. This helps businesses recover cleanly from product cleanup actions without blocking module installation.
Original PR description
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products. Steps to reproduce: --- - Install `event_product`…
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products.
Steps to reproduce:
---
- Install `event_product` application (without demo data).
- Delete `Event Registration` from products
- Now install `pos_event` module
Traceback:
---
```
Exception: Cannot update missing record 'event_product.product_product_event'
ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_event/data/event_product_data.xml:4, somewhere inside <record id="event_product.product_product_event" model="product.product">
<field name="available_in_pos">True</field>
<field name="pos_categ_ids" eval="[(6, 0, [ref('pos_event.pos_category_event')])]"/>
</record>
```
The error occurs because the user deleted the product, and then tried to install the other module.
This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks.
https://github.com/odoo/odoo/blob/f5378fadf910d193cbb44a4d1c10a5a15d8b9a51/odoo/tools/convert.py#L364
sentry-5731062091
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe wording of an error message in the Point of Sale loyalty flow was corrected when a gift card has already been sold. This makes the message clearer and more professional for staff using the system.
Original PR description
Before this commit, the error message shown when a gift card had already been sold contained incorrect grammar: "This Gift card is already been sold." opw-4656131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents errors when a user manages time off allocations but has no employee record in the current company. The system now checks for an available employee calendar before loading allocation data, improving reliability for HR workflows.
Original PR description
Issue: if user does not have employee in the current company in managment the allocation will try to load his employee calendar which raise the error Fix: check if there is an employee for the user before trying to fetch the data Task: 4660184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where reopening the website editor could fail after a user removed every tab from a Tabs block. The editor now handles that empty-tab situation gracefully, helping users continue editing without an error screen.
Original PR description
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs…
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs in a "Tabs" block are removed and saved, the next time the editor is opened, there is a traceback because `navEl` is `null`. **Solution**: Use the first value from `possibleValues` in case `navEl` is `null` this will prevent traceback in that case but does not prevent reaching the no tab situation (Still able to remove all tabs). **Steps to Reproduce**: 1. Add a **"Tabs"** block. 2. Click inside the first tab to edit its content. 3. Press **Backspace** repeatedly until the tab is completely removed. 4. Repeat for all remaining tabs until none are left. 5. Save and exit the editor. 6. Open the editor again. - **Issue**: A traceback occurs due to `navEl` being `null`. **opw-4608389** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how Odoo checks the version of a key web component so it works correctly on newer Debian systems. It prevents startup or runtime errors caused by a deprecated version field in newer Werkzeug releases.
Original PR description
The werkzeug version is parsed by using the `__version__` attribute which is deprecated since 3.0.0. This leads to an error when running Odoo in Debian trixie that provides werkzeug 3.1.3. See - pallets/werkzeug#2772 - https://packages.debian.org/trixie/python-werkzeug-doc > Also remove the unused import of `warning`
Leave approvers without full HR access can now see employee profile images when reviewing leave requests or allocations. This fixes a display issue while keeping access limited to the public employee information they are allowed to view.
Original PR description
- add option to `image` widget to accept a relation for preview_image to enable fetching images from `hr.employee.public` Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The attendance Gantt view now calculates progress correctly for employees with flexible working schedules. This prevents weekly attendance progress from being understated due to the displayed end date being excluded from the calculation.
Original PR description
This commit adds a test to make sure the progress bar of employee fetched in gantt view of attendance returns the expected values without any issue. opw-4492625
This fix prevents module updates from overwriting the trusted Dutch tax authority bank account data, avoiding failures caused by fraud-prevention checks. The account is treated as trusted by default because it matches the official payment details published by the Dutch tax authority.
Original PR description
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official belastingdienst site, it can be trusted by default. https://www.belastingdienst.nl/wps/wcm/connect/bldcontenten/belastingdienst/business/payroll_taxes/you_are_not_established_in_the_netherlands_are_you_required_to_withhold_payroll_taxes/when_you_are_going_to_withhold_payroll_taxes/filing_payroll_tax_returns_and_paying_payroll_tax/payment similar: d4595b856045fe9d35a4ac0f28faf12f0d19cd88
Fixes a display issue in the bank reconciliation widget where very long partner names could disrupt the alignment of dates and amounts. This keeps key transaction details easy to read and compare during reconciliation.
Original PR description
When the name of the partner is too long, we truncate the name but we should have added text-no-wrap on the date and amount. opw-4502699
Miscellaneous changes
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#202455 Forward-Port-Of: odoo/odoo#202230
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 Forward-Port-Of: odoo/odoo#202455 Forward-Port-Of: odoo/odoo#202230
Since [1] the widget displayed on a server action form view when it is set up as "Update a o2m field on a record" was not displaying the fields in the proper way. Before: the value field was a text field expecting the user to input the record id by hand. After: the value field is now a many2one selector. [1]: https://github.com/odoo/odoo/commit/0a744accc2aaa965d5353e854317895d822ad954 Forward-Port-Of: odoo/odoo#203156 Forward-Port-Of: odoo/odoo#202930
Original PR description
Since [1] the widget displayed on a server action form view when it is set up as "Update a o2m field on a record" was not displaying the fields in the proper way. Before: the value field was a text field expecting the user to input the record id by hand. After: the value field is now a many2one selector. [1]: https://github.com/odoo/odoo/commit/0a744accc2aaa965d5353e854317895d822ad954 Forward-Port-Of: odoo/odoo#203156 Forward-Port-Of: odoo/odoo#202930
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting
Original PR description
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices…
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting c. Create an Analytic plan (with an Analytic account associated) 2. Set its default applicability to mandatory 3. Create two invoices, remove the analytic distribution from one of the lines in one invoice. 4. In the invoices list view, select both newly created invoices, click on Actions > Confirm Entries 5. Click Confirm 6. The invoices were posted, even though they have no analytic distributions. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4603919) opw-4603919 Forward-Port-Of: odoo/odoo#203153 Forward-Port-Of: odoo/odoo#201560
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203174 Forward-Port-Of: odoo/odoo#200624
Original PR description
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203174 Forward-Port-Of: odoo/odoo#200624
**Problem**: When copying text from the editor that contains `nbsp`, pasting it into a code editor results in invalid characters, causing issues like compilation errors. **Solution**: Replace `nbsp` with normal spaces when copying text. **Steps to Reproduce**: 1. Add text: `"a b"` (with double spaces). 2. Copy the text. 3. Paste it into a **code editor**. - **Issue**: The invisible `nbsp` causes compilation errors. **opw-4645678** --- I confirm I have signed the CLA and re
Original PR description
**Problem**: When copying text from the editor that contains `nbsp`, pasting it into a code editor results in invalid characters, causing issues like compilation errors. **Solution**: Replace `nbsp` with normal spaces when copying text. **Steps to Reproduce**: 1. Add text: `"a b"` (with double spaces). 2. Copy the text. 3. Paste it into a **code editor**. - **Issue**: The invisible `nbsp` causes compilation errors. **opw-4645678** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202904
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt
Original PR description
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded…
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt it if "PyCryptodome" library is installed. Otherwise, it will raise a "DependencyError", which is not handled in the "except" clause. As "PyCryptodome" library is not part of Odoo requirements, we should handle the raised "DependencyError". **Solution:** Try to import "DependencyError" from "PyPDF2.errors" and catch that exception when adding the banner to the PDF. Our own "DependencyError" exception should be created because version 1.26.0 of PyPDF2 doesn't declare "DependencyError" and therefore the import will fail. "NotImplementedError" is used instead in version 1.26.0 and is already handled. opw-4634417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203005 Forward-Port-Of: odoo/odoo#202129
### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider
Original PR description
### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider at any point the payment terms so the total to be paid does not include the payment terms. Payment terms were included in invoices from POS with this [commit](https://github.com/odoo/odoo/pull/100100/commits/c1cd62f0b207b3f3bbf5a03009bd8e34ee9b479f) ### Solution: Remove the payment terms on invoices from POS. opw-4458036 Forward-Port-Of: odoo/odoo#202147 Forward-Port-Of: odoo/odoo#199385
Steps to reproduce: - add a payment reference on a vendor bill - confirm - register a payment - see the memo takes the payment reference value - update the payment reference on the invoice, register (no matter if you reset the invoice into draft or not) - register a payment Issue: see the memo takes the same vale as the initial payment reference Cause: We use the `line.name` which is not wrong as when we update the payment reference the it will be updated. But whenever we update th
Original PR description
Steps to reproduce: - add a payment reference on a vendor bill - confirm - register a payment - see the memo takes the payment reference value - update the payment reference on the invoice, register (no matter if you reset the invoice into draft or not) - register a payment Issue: see the memo takes the same vale as the initial payment reference Cause: We use the `line.name` which is not wrong as when we update the payment reference the it will be updated. But whenever we update the payment reference again, the `line.name` will not be updated https://github.com/odoo/odoo/blob/0bec22df0a34c6bc201d2627cf1123509d272a6d/addons/account/models/account_move_line.py#L482-L483 Solution: We prioritize the payment reference for the communication as it is the case in 18.0 opw-4405999 Forward-Port-Of: odoo/odoo#198826 Forward-Port-Of: odoo/odoo#196611
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were p
Original PR description
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were provided from FedEx support. opw-4461150 Forward-Port-Of: odoo/enterprise#81977 Forward-Port-Of: odoo/enterprise#79617
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Original PR description
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - Spanish partner - Amount > 3005.06 (mod347 threshold) - Type for mod 347: Regular operation - Create and confirm a jounral entry with: - Payable account, debit 4000 - Receivable account, credit 4000 - Type for mod 347: Regular operation - Check Mod 347 Tax Report Issue: 'Total number of persons and entities' shows 0 This occurs because some lines of mod 347 report need to be grouped by
Original PR description
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - Spanish partner - Amount > 3005.06 (mod347 threshold) - Type for mod 347: Regular operation - Create and confirm a jounral entry with: - Payable account, debit 4000 - Receivable account, credit 4000 - Type for mod 347: Regular operation - Check Mod 347 Tax Report Issue: 'Total number of persons and entities' shows 0 This occurs because some lines of mod 347 report need to be grouped by partner, only keeping the partners whose balance for the line is above 3005.06€, so we first get all the partners that match the domain but don't reach the threshold. We exclude these partners with a 'NOT IN' clause. However, when the partner is not set, a NULL values is retrieved causing the clause to be evaluated NULL instead of False and the total count will be 0 opw-4544950 Forward-Port-Of: odoo/enterprise#81954 Forward-Port-Of: odoo/enterprise#81687