Monday, September 1, 2025
26 changes · saas-18.4
Enhancements to existing features
Website editing screens now look cleaner and use the available space better. The preview area no longer shows an unnecessary top border, and theme preset options span the full width for easier selection.
Original PR description
Some improvements on the UI while in edit mode: - Remove border top from the preview iFrame - Make the theme preset full width task-4367641
This update makes automated tests for messaging and live chat more dependable by using stable page markers instead of visual styling details. It reduces false test failures when the interface design changes, helping teams maintain quality with less disruption.
Original PR description
This commit updates the test selectors to use data-as-tab-id to avoid ambiguity. This change enhances the robustness of the tests by reducing their dependency on CSS classes. Using data-as-tab-id attributes provides a more stable and reliable way to select elements in the DOM for testing purposes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows accounting return periods to be adjusted when needed instead of always relying on the configured period. It supports smoother data migrations where older returns may not match current period settings, helping preserve historical reporting accuracy.
Original PR description
The method _get_period_boundaries not allow to override the targetted period and start_date. This is used for the migration script to recreate old returns that not always has the same period as the one configured. See: https://github.com/odoo/upgrade/pull/8288 Forward-Port-Of: odoo/enterprise#93100
Resolved issues and error corrections
This fix avoids checking empty quote PDF documents for encryption, preventing unnecessary errors when those documents are processed. It helps keep sales quote document handling reliable when an uploaded or configured PDF has no content.
Original PR description
If the document is empty we don't need to check for encryption. Otherwise we risk getting an error. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line…
If the document is empty we don't need to check for encryption. Otherwise we risk getting an error.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 544, in _tag_root
f(rec)
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 444, in _tag_record
record = model._load_records([data], self.mode == 'update')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5500, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5418, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4827, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
check(self)
File "/home/odoo/src/odoo/18.0/addons/sale_pdf_quote_builder/models/product_document.py", line 46, in _check_attached_on_and_datas_compatibility
utils._ensure_document_not_encrypted(base64.b64decode(doc.datas))
File "/home/odoo/src/odoo/18.0/addons/sale_pdf_quote_builder/utils.py", line 12, in _ensure_document_not_encrypted
if pdf.PdfFileReader(io.BytesIO(document), strict=False).isEncrypted:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/tools/pdf/__init__.py", line 91, in __init__
super().__init__(stream, strict)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 317, in __init__
self.read(stream)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 1408, in read
self._basic_validation(stream)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 1449, in _basic_validation
raise EmptyFileError("Cannot read an empty file")
PyPDF2.errors.EmptyFileError: Cannot read an empty file
```
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#224674Miscellaneous changes
**Issue** Credit notes submitted to TicketBAI incorrectly include a positive ImporteTotalFactura in the generated XML, instead of a negative value. **Steps to Reproduce** 1. Install Accounting and TicketBAI modules. 2. Create, confirm, and send an invoice. 3. Reverse the invoice to create a credit note. 4. Confirm and send the credit note. 5. Download the generated XML and observe the total amount. **Root Cause** The _get_importe_desglose_foreign_partner method did not account for w
Original PR description
**Issue** Credit notes submitted to TicketBAI incorrectly include a positive ImporteTotalFactura in the generated XML, instead of a negative value. **Steps to Reproduce** 1. Install Accounting and TicketBAI modules. 2. Create, confirm, and send an invoice. 3. Reverse the invoice to create a credit note. 4. Confirm and send the credit note. 5. Download the generated XML and observe the total amount. **Root Cause** The _get_importe_desglose_foreign_partner method did not account for whether the move is a credit note or an invoice. As a result, the total amount (ImporteTotalFactura) is always positive **Fix** Use the existing is_refund parameter to correctly apply the sign to the total amount based on the document type. Opw-4814241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212954
Fixed an issue where users could not open the full list of events on non-working days in the calendar. The “show more” link now responds correctly, preventing accidental creation popovers and making busy off-day schedules easier to review.
Original PR description
**PROBLEM** If you add a lot of daily event on a off-day, the "show more" link to show all events is not clickable. Clicking bring the event creation popover. **REPRO STEPS** 1. install calendar and hr. 2. on a off day (grey background) in the week or day view, add events until the "show more" link shows up. 3. click on it, and notice the event creation popover pops up instead of the event list popover. **CAUSE** FullCalendar css class fc-non-business have a zindex of 1, a div with this class is "above" the link. **FIX** Removing a line that removed the css class fc-daygrid-more-link to the "more-link" element. Modifying css to keep the style consistent even with this new class. opw-4844719 Forward-Port-Of: odoo/odoo#221007
This fix adjusts an internal Discuss test so its expected performance measurements account for routing cache behavior. It helps keep automated validation stable and reduces false failures during release checks, without changing user-facing features.
Original PR description
runbot-231489 Forward-Port-Of: odoo/odoo#224940
This fixes self-order cart lines so they save every selected product attribute value, matching the regular Point of Sale behavior. It helps ensure orders with configurable products are recorded consistently and accurately for staff and downstream processing.
Original PR description
Before this commit, the ptav of attributes configured to create variants was not saved in the order lines. This was inconsistent with the behavior in Point of Sale, where all ptav values are saved in the order lines. opw-5020130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224699 Forward-Port-Of: odoo/odoo#224080
The Saudi localization no longer shows the "THIS IS NOT A LEGAL DOCUMENT" warning on vendor bills, vendor credit/debit notes, purchase receipts, or sales receipts. This keeps the warning focused on customer invoice documents where it is relevant when the QR code is missing, reducing confusion for users and suppliers.
Original PR description
Before this commit: - The message "THIS IS NOT A LEGAL DOCUMENT" was also displayed on Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. - The warning should only appear on Customer Invoices, Credit Notes, and Debit Notes when the QR code is missing After this commit: - The warning message is no longer displayed on all Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. Task-5044870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224473
Fixed a purchase order display issue where later pages showed only the vendor’s product name instead of both the vendor name and the product’s internal name. This makes multi-page purchase orders consistent and helps users identify products more clearly.
Original PR description
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the…
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the settings. If you can't disable it, you can disable the view `purchase.order.form.inherit.matrix` to trigger the bug. - Create a product - Go to the purchase sheet - Add a vendor - Add the field "Vendor Product Name" and "Vendor Product Code" and fill them - Create a purchase order - Add your product - Add your product a second time (on a second line) - Confirm the PO - Activate debug mode - Go to the view and add a limit to have only 1 POL per page - Return to your PO - Go to the second page #### Current behavior: - Only the vendor name is displayed #### Expected behavior: - The vendor name should appear at the top, while the db name should be displayed under as in the first page. #### Cause of the issue: On the first page, POLs data are fetch through a `web_read` on the PO, while on other pages data are fetch through `web_read` on the POLs of the page. While fetching POL data with a `web_read` the client ask for several informations including: `name` and `product_id.display_name`. If both return the same, the client show only one, else it shows the `display_name` on top and the `name` below. - `name` return the vendor name - `product_id` is fetch with the context `partner_id` which transform the `display_name` from the db_name to the Vendor name Therefore it fetches twice the vendor name and don't have the name from the db. #### Solution: - remove the `partner_id` from the context. #### Consequence: - When adding a product to the PO, the name of the product displayed in the dropdown list will be the name from the db instead of the name of the vendor. PO confirmed that consequence is OK as long as it's still possible to search for product using vendor code, which is still possible. opw-4737337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223250
Product kits now respect quantity-on-hand filters based on their actual computed availability from component stock. This prevents kits from appearing in product lists when they do not truly match the selected stock range, improving inventory search accuracy.
Original PR description
#### Issue: - When filtering products on "Quantity on hand", kits may appear when they shouldn't #### Step to reproduce: - with MRP - create a new product - create a BoM for this product as kit - make sure you have product of the BoM on hand - go to product - add filters: - "Quantity on hand" > 1 - "Quantity on hand" < *less_than_you_have* #### Current behavior: - kit appears #### Expected behavior: - kit doesn't show #### Cause: - kit were filtered has having both 0 quantity (as unstored product) and their quantity (computed from stock of BoM products). Therefore they were compliant with both filter. #### Solution: - remove kits from products compliant with the filter if they don't comply with the filter with their computed quantity opw-4967763 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224681 Forward-Port-Of: odoo/odoo#221224
This fixes an internal test configuration so the Discuss test suite uses the correct test model from its own module. It helps keep automated checks reliable and avoids accidental reliance on another test module.
Original PR description
PR #223438 uses `mail.test.rating` model (which belongs to `test_mail_full` module) as the test model in `test_discuss_full` module. This PR changes the test model to the correct one. runbot-231321 Forward-Port-Of: odoo/odoo#224630
A website test was adjusted so it no longer fails when the system performs fewer database queries than the maximum allowed. This improves reliability of automated checks without changing customer-facing website behavior.
Original PR description
This test fails in community only as the query count is lower than the maximum allowed. runbot error 226784
This fix prevents Discuss calls from showing an error when someone leaves or crashes at the same time another participant joins. It makes call handling more reliable in a rare timing situation, reducing disruptive errors for users.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/200981, a race condition could occur where the call is over when the the rtc session matching a track event is obtained. This could occur if you crash or leave at the moment another user arrives. You could get a track event from the SFU, wait for the rtc session record from Odoo, leave te call, finally get the rtc session from odoo. This would lead to a traceback as this handler expected that the call was still ongoing. Forward-Port-Of: odoo/odoo#224658 Forward-Port-Of: odoo/odoo#224588
The Chilean electronic invoicing demo setup now includes the required certificate serial number. This lets users test sending invoices to the Chilean tax authority without hitting an installation-related error, while leaving real production certificates unchanged.
Original PR description
**Issue** When installing l10n_cl_ed, the `subject_serial_number` field is left empty. This causes an error when attempting to send an invoice to the SII. **Steps to Reproduce** 1. Install Accounting and l10n_cl_edi 2. Create and confirm an invoice 3. Click "Send Now to SII" 4. Error: Invalid Operation **Root Cause** The `subject_serial_number` is not set during installation, and this field is required for electronic document generation. **Fix** Restore the behavior from version 17.0 by setting a default `subject_serial_number` if it's missing and the certificate is available. This ensures the demo data is functional and allows users to test the SII integration out-of-the-box. Opw-4961801 Forward-Port-Of: odoo/enterprise#90636
When an accounting return entry is duplicated, the new copy is no longer incorrectly tied to the original return. This prevents duplicate entries from affecting or appearing as part of the same tax/reporting return, improving data accuracy.
Original PR description
Duplicating some return's move also kept the duplicate linked to the return. This is wrong. task-5046319 Forward-Port-Of: odoo/enterprise#93323
Receipts for point-of-sale setups using preparation displays or preparation printers now show the correct tracking number. This helps staff and customers match orders to receipts more reliably and avoids confusion during order preparation.
Original PR description
- Ensure the `tracking_number` is dipslayed on receipts for config which use a preparation dipslay or a preparation printer. task-id: 4922308 community PR: https://github.com/odoo/odoo/pull/222094 Forward-Port-Of: odoo/enterprise#93318 Forward-Port-Of: odoo/enterprise#91833
This fixes a regression that caused IoT communication sessions to be opened earlier than needed after a recent internal refactor. Restoring lazy session handling helps keep point-of-sale and self-order IoT interactions efficient without changing user workflows.
Original PR description
* : pos_iot, pos_self_order_iot The refactor introducing the `iot_http` service dropped by mistake the previous lazy_session optimisation [1], this commit reintroduce it. [1]: https://github.com/odoo/enterprise/commit/313bde6feb756c050a20a3459e1e8282d11ffa66
Egypt payroll calculations now handle terminated employees who do not have annual leave allocations. Instead of failing during payslip computation, the system treats their remaining annual leave as zero so payroll can continue reliably.
Original PR description
When computing payslips for terminated employees (archived) with no annual leave allocations, the method `_l10n_eg_get_annual_remaining_leaves` raised a traceback due to missing allocation data. This fix ensures the method safely handles employees without allocations by returning 0 remaining leaves instead of crashing. This guarantees payslip computation works correctly for employees with no leave allocations. task-5026406
A payroll accounting test was updated to use a fixed car acquisition date so it will continue to pass in 2026 and beyond. This is an internal quality fix that helps keep automated validation reliable without changing business features or user workflows.
Original PR description
Some tests will fail in 2026. This adds a freeze time to prevent this failing. Task: 5034173 Forward-Port-Of: odoo/enterprise#92983
Gantt card popovers now show standard labels such as Name, Start, and Stop in the user's selected language instead of always appearing in English. This improves the experience for non-English users viewing custom Gantt menus created with Studio.
Original PR description
Steps to Reproduce: - Change the language to something other than English. - Create a new menu in the Appointment module using Studio. - Link that menu with the existing model (Resource Time of…
Steps to Reproduce: - Change the language to something other than English. - Create a new menu in the Appointment module using Studio. - Link that menu with the existing model (Resource Time of Detail). - Save the changes and add the Gantt view - Save the changes and close Studio. - View this new menu in the Gantt view Issue: - When clicking onto the kanban popover card for any record, the labels will remain as "Name" , "Start" , and "Stop" in English, and it will not translate. Reason: - [1] changed the rendering of default kanban card templates from XML to JS. This changed the default template to be static. Fix: - Add a call to the translation core tool "_t" on the three labels upon their generation in _getKanbanViewParams(). This ensures that the arch template that is generated is translated correctly into the user's set language. [1] : b2e31239041e6b7850888a3ae070c3f8a40ea5ee [opw-4861899](https://www.odoo.com/odoo/my-tasks/4861899) Forward-Port-Of: odoo/enterprise#90605
Payroll users can now change salary rule colors reliably from both Salary Rules and Salary Structures. This ensures visual styling is applied correctly in the rule form and pop-up, making salary rule setup clearer and less confusing.
Original PR description
Steps to Produce: - open payroll app - Go to Salary Rules or go to Salary Structures and open any salary rule. - try to change color of any rule. issue: - The color does not change in the Salary Rules. - Additionally, styles do not apply in the salary rule pop-up accessed through Salary Structures. Fix: - Instead of changing the color with formrenderer, a custom widget was created to apply styles directly to the field. opw-4716810 task-4774448 Forward-Port-Of: odoo/enterprise#83514
The Timesheets leaderboard now correctly shows the tip of the day when the leaderboard feature is enabled. This restores expected guidance in the leaderboard dialog and helps users see daily tips while tracking timesheet performance.
Original PR description
Steps to Reproduce: -- - Open timesheet module - Go to setting and enabled leaderboard feature - Open leaderboard dialog and there you will be able to see tip of the day is not visible Issue: -- The issue was even after enabling the leaderboard feature the tip of the day was not visible inside the leaderboard dialog which is unexpected behaviour. Cause: -- The root cause was inside the getLeaderboardData method call where we were not fetching tip from the orm call and the issue is caused by this PR https://github.com/odoo/enterprise/pull/78541 Fix: -- To resolve this, I have include tip while making orm call also store that tip value inside leaderboardData task-4981767 Forward-Port-Of: odoo/enterprise#92811
This fix prevents the French VAT report wizard from crashing when required report dates or report details are not yet available during setup or testing. It makes the VAT amount calculation safer by using default values until enough information is present, improving reliability without changing normal user workflows.
Original PR description
steps to reproduce the issue : 1- install l10n_fr_hr_payroll_account without demo data 2- and run this test .test_computed_fields_without_dependencies Added a dependencies using…
steps to reproduce the issue :
1- install l10n_fr_hr_payroll_account without demo data
2- and run this test .test_computed_fields_without_dependencies
Added a dependencies using @api.depends('report_id', 'date_from', 'date_to') on the _compute_vat_amount method to ensure automatic re-evaluation when any of these fields change.
In test_computed_fields_without_dependencies, the record is created using model.new(), which means required fields like report_id, date_from, and date_to may not be set yet. This caused a crash due to ensure_one() on an empty report_id.
Even though these fields are required, they are not automatically filled when using model.new() (unlike saved records).
Also introduced early exits by setting default values (vat_amount = 0.0, is_vat_due = False) and skipping computation when any of the required fields (report_id, date_from, date_to) or result VAT lines are missing because of ensure_one() in options.
These safeguards prevent errors in the test
build_error-115299
Forward-Port-Of: odoo/enterprise#87608The French VAT reporting flow now uses the correct account when creating a reimbursement entry. This helps keep reimbursement accounting accurate and reduces the risk of manual corrections.
Original PR description
This commit will change the account used for the reimbursement move. task-4932427 Forward-Port-Of: odoo/enterprise#91212
Fixed an issue where sorting a grouped Budget Report by description could trigger an error and interrupt users. This improves reliability when reviewing budget information in Accounting reports.
Original PR description
Currently an error occurs when we try to order a grouped list on `budget.report` model. Steps to replicate: - Install `account_budget` with demo data. - Go to `Accounting > Reporting > Budget Report`. - Go to list view and group by Budget. - Click on the Description (table header) to order the list. Error: `AttributeError: 'bool' object has no attribute 'split'` The error occurs due to line [1] in `web_read_group` calling `.split()` on `_order`, which is `False` because the model sets `_order = False` [2]. Solution: - Remove `_order = False` from the model definition. - Since the model is not stored in the database (`_auto = False`), removing `_order` will not cause issues in stable versions. [1]: https://github.com/odoo/odoo/blob/b14da3d3f4465e2bf0125de0484fe9cb1bc79aed/addons/web/models/models.py#L420 [2]: https://github.com/odoo/enterprise/blob/8cc8443dc11c176b55f7eb3efa07db5edb7e6b0c/account_budget/reports/budget_report.py#L11 sentry-6747467261