Wednesday, November 12, 2025
8 changes · 17.0
Enhancements to existing features
The official payroll figures used for Luxembourg have been updated to match the 2025 rules. This helps ensure employee payroll calculations remain accurate and compliant with the latest official values.
Original PR description
Update the official numbers of the Luxembourg payroll rules for 2025. This is a backport of PR https://github.com/odoo/enterprise/pull/79805 task-5187202
When a payment line gets stuck waiting for a payment terminal response, the POS now shows a “Force Done” option. This helps staff move forward instead of being blocked by an unresponsive terminal.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user.
Resolved issues and error corrections
This update fixes an error that could appear when opening the Accounts Coverage Report for Spanish balance sheet reports. It ensures the report data is loaded and interpreted correctly, so users can view the report without a traceback.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114This update fixes an issue where the background image of the website “text cover” snippet could disappear on mobile or when the page is zoomed in. It keeps the cover visible so pages look consistent across screen sizes.
Original PR description
Steps to reproduce: =================== - Go to website and add a "text cover" snippet - Zoom in on the page or switch to mobile view -> The cover's background image disappears Cause: ====== A Bootstrap rule applied `d-md-block` to the cover image container on screens (specifically when width >= 768px, which can be removed by zooming). https://github.com/odoo/odoo/blob/b093786714e9e8567cf75abf78ac3d954a3d89b2/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L8624 So `d-none` will be applied once d-md-block is removed. Solution: ========= Remove the `d-none` rule from this element to ensure the background image remains visible. A workaround is included for non-updated views until master. opw-5219747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening Studio on a calendar view now works even when the view includes fields with access groups. This prevents the calendar editor from crashing and makes customization more reliable for users.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash
This update ensures the Kanban view returns to a normal record limit after a grouping is removed and the view is restored. It prevents the web client from loading too many records at once, which could slow down the page or cause it to crash.
Original PR description
Steps to reproduce ================== - Add a group by in the kanban product view - Switch to the list view - Remove the group by - Switch back to the kanban view -> No limit is applied, and the webclient can crash if too many records are returned. Cause of the issue ================== The groupsLimit is set as MAX_SAFE_INTEGER in the kanban view https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/views/kanban/kanban_controller.js#L168 Which is then reused as the limit https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/model/relational_model/relational_model.js#L368 Solution ======== There is already a code path to reset the limit when switching from grouped to ungrouped, but is wasn't called on the first load (when this.root isn't set yet) opw-5167769
This change fixes an issue where some BACS batch payments could be exported with the wrong amount due to rounding errors. It ensures the payment amount is written correctly in the batch file, preventing underpayment or mismatches during bank processing.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413
This fix restores the ability to choose previously saved payment details when registering a payment for a customer invoice. It matters because businesses can again reuse stored payment methods for the right customer, avoiding failed payment setup and extra manual work.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order for a company partner; 2. create & copy a payment link; 3. open payment link in new session; 4. using demo provider, make the payment & save payment details; 5. add an invoice address to the company partner; 6. create an invoice for the company partner using the invoice address; 7. confirm invoice; 8. click "Register Payment"; 9. select "Demo" as payment provider. Issue ----- The saved payment token cannot be selected. Cause ----- Before commit 75f4008, the company partner was used to search for tokens in the payment register wizard. After the commit, the the invoice partner is used, making it impossible to select previously accessible payment tokens. Solution -------- Search payment tokens linked to either partner. opw-5193718