Tuesday, September 23, 2025
17 changes · saas-18.3
Enhancements to existing features
The web interface’s underlying component library was updated to a newer version. This helps keep the platform current and can bring small reliability or performance improvements without introducing a visible feature change for most users.
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.8.1 Forward-Port-Of: odoo/odoo#228092
Payroll payslip line and worked days reports have been adjusted so users can no longer edit fields that should only be viewed. Navigation and search improvements make it easier to find the right payroll data while protecting report accuracy.
Original PR description
-In payslip line report, some fields can be edited, which should not be allowed. -Views have been adjusted to prevent the navigation from pivot to list view. -Search view has been modified for easier data reaching.
Resolved issues and error corrections
Fixed an issue in the HTML editor where changing a linked item between numbered and bulleted list styles could cause an error. Users can now edit list formatting in To-Do content more reliably without interruptions.
Original PR description
Steps to Reproduce: 1. Go to To-Do 2. Create a link 3. Select all using Ctrl + A 4. Switch to order list and then unordered list. 5. Traceback occurs Description of the issue: - This issue occurs because a feff (zero-width no-break space) character is present inside the link. When the link is inside a list and the list type is changed, the `removeFEFF` method is triggered. `removeFEFF` removes the feff characters, but the selection is preserved based on positions from when those feffs were still present inside the link. As a result, after the list type is changed, restoring the selection causes a traceback. Solution: - Triggered `clean_handlers` before preserving the selection. This ensures feff characters are removed from the link before the selection is preserved, preventing invalid selection offsets and avoiding the traceback. task-5095561 Forward-Port-Of: odoo/odoo#227680
Timesheet reports printed from a sales order now show the related helpdesk ticket name alongside the helpdesk team. This makes billed support work easier to identify and verify for customers and internal teams.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
A date used in the product margin test was corrected to keep automated checks reliable. This helps prevent false test failures and supports smoother maintenance without changing business functionality.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227210 Forward-Port-Of: odoo/odoo#226089
This fix stops Argentina partner records from crashing when an invalid VAT or identification value is entered. It makes data cleanup more reliable and helps users continue working even when tax ID inputs contain unexpected characters.
Original PR description
Manual backport of https://github.com/odoo/odoo/commit/b01a6640895c4dd4b5bcf849740aa6b3312e9a54. This is needed to prevent crashes when trying to sanitize invalid VAT inputs for Argentina partners due to the assumption that the identification number can always be safely cast to int(). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223661
The website search suggestions dropdown now chooses the side of the search bar with the most available space. This prevents suggestions from appearing in a cramped area, improving usability for shoppers using high zoom levels or smaller browser windows.
Original PR description
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where…
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where there is the less space available. Cause: When the dropdown doesn't fit fully in the viewport below the searchbar it is always added on top even if there is less space available. The code was added in 15.0 62c265ee7d7cf36db01bf6a95b2c5ea9843ba2d3 with the intent of putting the dropdown on the top if it increased the page height when putting it below (eg. when we put a search bar in the footer). But in saas-18.2 refactoring (b9b3a605e0f4c5da3a258c980107d6162da7f44f), the code was rewritten and now: - the dropdown has a scroll bar if it is too big to fit on viewport - if the dropdown doesn't fit fully below the searchbar in the viewport, it is placed above the searchbar even if there is less space Fix: place the dropdown below the searchbar if there is more space below than above. opw-5019685 Forward-Port-Of: odoo/odoo#225220
The Spanish Modelo 130 report now uses an end-date selection instead of a date range. This prevents users from expecting results for only a selected range when the report is designed to calculate from the start of the fiscal period, reducing confusion in tax reporting.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#226177 Forward-Port-Of: odoo/odoo#218544
This update adds test coverage for the Spanish Modelo 130 tax report to help ensure it continues to calculate and display correctly. It reduces the risk of regressions in Spanish tax reporting after future changes.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#94251 Forward-Port-Of: odoo/enterprise#90044
The point of sale payment screen now correctly disables the Validate button on mobile when no payment method is selected. This helps prevent checkout mistakes and gives cashiers clearer guidance during mobile payments.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. task-id: 5072759 enterprise PR: https://github.com/odoo/enterprise/pull/94100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225975 Forward-Port-Of: odoo/odoo#225917
The point of sale settlement tests no longer rely on a fixed calendar year when choosing invoices to settle. This makes automated checks more stable over time and helps prevent false failures that could slow down future releases.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171
This fix removes a hardcoded year used when selecting invoices to settle in point of sale localization tests. It helps keep automated checks reliable over time, reducing false failures without changing business workflows.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 enterprise PR: https://github.com/odoo/enterprise/pull/93166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The bank reconciliation report now excludes currency adjustment entries that do not represent real bank money movements. This prevents exchange rate adjustments from appearing under miscellaneous operations, making the report clearer and more accurate for foreign-currency bank journals.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870) Forward-Port-Of: odoo/enterprise#94172 Forward-Port-Of: odoo/enterprise#93999
This change fixes an inconsistent accounting test caused by duplicate domestic fiscal position candidates. It removes an invalid test assumption and adds a safeguard to warn if future localization data introduces the problematic case.
Original PR description
#### Issue: `test_domestic_fp` randomly fail #### Cause: While computing domestic fiscal position, there are 2 fiscal position candidates for being domestic as they got the same `sequence` and no `country_id`. It happens randomly that the second one is fetch instead of the first one. #### Solution: The failing assert checks a case that doesn't exist in any fiscal position data. Therefore, this commits remove this part of the test, but add a warning in `test_all_l10n` to ensure this case won't happen in new data. runbot-231686 This PR is linked to [this PR](https://github.com/odoo/odoo/pull/224599) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix reorganizes editor tests so each check has its own timeout instead of sharing one combined limit. It reduces random test failures in automated validation, helping keep development and release checks more stable without changing user-facing behavior.
Original PR description
Grouping multiple `testEditor` in a single `it` is bad practice because the timeout of `it` is then shared between the different `testEditor` calls rather than each having their own separate timers. Technically, only the web_edior tests ever timed out, but I split the html_editor ones as well for good measure. runbot-231687 Forward-Port-Of: odoo/odoo#227985
POS receipts now display preset information, such as customer addresses or time slots, centered in the receipt header. This improves receipt readability and provides a cleaner presentation for customers.
Original PR description
We now want to center preset infos on receipt header (customer address or time slot) in POS. task-id: 5048706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refreshing appointment time slots now handles cases where no resource is selected. This prevents errors when checking maximum capacity, helping customers continue booking appointments without interruption.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144