Tuesday, October 14, 2025
13 changes · saas-18.3
Enhancements to existing features
Companies using Austrian POS localization can now automatically invite the company email address to access their Fiskaly dashboard. If the email changes, a new invitation is sent, and existing Fiskaly organization details are kept up to date.
Original PR description
In this commit: ------------------ - If a company email is set in the company information, we send an invitation to that email, allowing the user to access their company data on the Fiskaly dashboard by logging in using the company email. - If the email is later updated, access invitation will automatically be sent to the new email. - If the fiskaly organization exists, we should update the organization data even if the authentication is remaining to keep the data uptodate. Related PR: https://github.com/odoo/iap-apps/pull/1098 Task: 4881786
The account merge process now gathers existing account codes in one database operation instead of checking each company one by one. This reduces processing time for databases with many companies, making account merges faster and smoother.
Original PR description
The merge wizard needs to collect the account codes of the accounts we are merging in order to write them on the merged account as the final step of the merging process. At the moment, collecting the account codes is done in Python and loops over all the existing root companies, retrieving the code of the account for each company. On a recent l10n [runbot](https://runbot.odoo.com/runbot/build/90542336) (with 146 companies), this was causing the merging step to take ~4.5 seconds per account, most of this time being taken just by collecting the account codes. Instead, we collect the codes in a single SQL query. Flamegraphs: [before.json](https://github.com/user-attachments/files/22726956/before.json) [after.json](https://github.com/user-attachments/files/22726960/after.json) task-none Forward-Port-Of: odoo/odoo#230158
Resolved issues and error corrections
The Subscriptions MRR Breakdown report now ignores archived companies when preparing report data. This prevents an access error in multi-company setups where the original company was archived and another active company is used.
Original PR description
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro),…
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro), then set that currency as the Main Currency of the new Company. - Then, set a currency rate on the previous Main Currency i.e USD. - Create a Subscription Sales Order and confirm it. - Open the MRR Breakdown report. - Click into the data of the report. Observation: An error message will occur appear (Access Error) Issue: - when building the query, it also fetches the archived company, due to `active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build which fetches no data, leading to sort of access error as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches. Fix: - we explicitly search for active companies opw-5090463 Forward-Port-Of: odoo/enterprise#95989
The duplicate transaction warning in bank reconciliation now works again. Users who see the banner can be directed to the tool for finding duplicate transactions, reducing confusion and helping them clean up bank data.
Original PR description
Before this commit, the action "Some transactions may be duplicates." was broken because 2 elements from the old bank reconciliation widget were removed. The commit [[1]] of the new bank reconciliation widget forgot to add the action service and a link to the journal. These 2 elements were used to redirect the customer to the Find duplicates tool. This commit adds, in the extension of the bank reconciliation kanban controller, the call to the action service and adapt the old code to match the new one. no task id [1]: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109
This fix keeps text colors and gradient formatting intact when users change heading styles inside lists. It also prevents formatting issues with checklist strike-throughs and avoids invalid nested formatting when continuing to type after a list.
Original PR description
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list…
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list item. - Move the cursor outside the list by pressing Enter twice and start typing in the new container. Current behavior before PR: - When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent. - This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`. Desired behavior after PR is merged: - All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element. - Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice. task-5039499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224262
The attendance auto-checkout process now correctly closes open attendance entries even when the employee checked in on a previous day. This prevents missed checkout records after downtime or delayed scheduled processing, improving accuracy of attendance tracking.
Original PR description
Problem: the auto-checkout feature was basing the computation on the fact that the unclosed attendance was starting today. However, it might not always be the case, for example if the server is shutdown for more than 24 hours after checking in. Steps to reproduce: - Activate the auto-checkout feature - Create an open-ended attendance for two days ago - Run the cron - Result: the attendance is not closed. This commit solves the issue by taking into account the days delta between today and the check-in date. task-5082359 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#227981
Changing a user's locale can alter which day is treated as the start of the week, which affects spreadsheet pivot data grouped by day of week. This fix reloads affected pivots after a locale change so users see accurate values instead of stale or incorrectly grouped results.
Original PR description
Chaning the locale can change the first day of the week. But the normalization of the server value depends on this `locale.weekStart`, se we need to reload the pivot when the locale changes, otherwise we might display wrong values for a "day_of_week" grouping. Task: [5149508](https://www.odoo.com/web#id=5149508&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#230949
Combo products in Point of Sale preparation tickets are now routed correctly when different printers handle different product categories. Each printer shows the combo title and only the relevant child items, reducing kitchen or preparation mistakes.
Original PR description
Before this commit: =================== - When using separate printers for product categories, combo products were not printed correctly. - All child products of a combo were sent to every printer, regardless of their category. After this commit: ================== - Combo products are now handled properly in preparation tickets. - Each printer will print the combo product title along with only the child products that belong to its assigned category. Task: 5056115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225658
This fix makes reconciliation models available when using invoicing features, preventing accounting workflows from getting stuck. It also cleans up confusing screens related to creating reconciliation model lines, making the invoicing experience smoother for users.
Original PR description
Currently flows are stuck if you don't have the models. And some views are really weird (create a reconciliation model line). 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 fix ensures the point-of-sale payment screen updates correctly after a customer completes an online QR code payment. It prevents staff or customers from seeing an outdated QR payment prompt and avoids errors when finalizing the order.
Original PR description
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup…
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup manually and performing another action resulted in a `Finalize order` error. - This happened because the WebSocket handler flow were not updating the order state properly. After this commit: =============== - Ensure the frontend refreshes payment status directly from the server when the current order is updated. - Remove unnecessary synchronization calls to prevent stale state. - The order is now correctly marked as paid, and no finalize error occurs after closing the QR popup. Issue: =============== - The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION` was fetching the full `pos.order` unnecessarily, because the order state is already updated by another WebSocket flow. - `notify_synchronisation` in the self order flow was redundant, as updates are already handled in the `pos_self_order` module’s `pos.order` file. Task - 5107009 Forward-Port-Of: odoo/odoo#229847
A Point of Sale issue was fixed where forcing a payment to finish could leave terminal payments marked as still in progress. This prevented cashiers from selecting terminal-linked payment methods for the next transaction, so the fix helps checkout continue smoothly.
Original PR description
Before this commit, the function sendForceDone was not setting paymentTerminalInProgress to false, which blocked the user from doing another terminal payment as the payment methods linked to a terminal are not clickable. After this commit, sendForceDone can be used without blocking future terminal payments. opw-4978772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231098 Forward-Port-Of: odoo/odoo#230969
Fixes a blank QR Menu page for Belgian blackbox point-of-sale setups when customers open the menu before the PoS session has started. This ensures the online menu remains accessible as expected and avoids a disruptive customer-facing failure.
Original PR description
When you open the QR Menu of a PoS that uses the blackbox, the menu will not appear if the session is not opened. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Setup the same PoS to use the QR Menu * Try to open the menu without opening the PoS > Observation: The QR Menu never show anything, the page stays blank. Why the fix: ------------ Here (https://github.com/odoo/enterprise/blob/0635388bdc9f115d527e0d2da43dfcd0d4a00d1f/pos_blackbox_be/static/src/self_order/overrides/services/self_order_service.js#L61-L62) if the session is not opened, we try to read `_product_product_work_in` on session that is undefined. opw-4829700 Forward-Port-Of: odoo/enterprise#93196
This fix allows product imports to correctly include uploaded files, such as PDFs, in custom Studio file fields. Businesses can now update product records from spreadsheets without errors or missing attachments when non-image files are included.
Original PR description
## Versions 18.0 > 18.3 Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6 ## Issue Importing products (with file fields) from XLSX file triggers an error or does not update when…
## Versions
18.0 > 18.3
Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6
## Issue
Importing products (with file fields) from XLSX file triggers an error or does not update when uploading related PDF files.
## Steps to reproduce
https://github.com/user-attachments/assets/7f4c1faf-de8c-4923-a50e-cce77071679d
*Requires Studio app*
- Go to any product's backend page and open Studio customization:
- Add a "File" field to the product page and link it to a "PDF Viewer" widget;
- Keep the field name ("New File");
- Save and close.
- Go to the products' list view in debug mode and select a product (e.g. Acoustic Bloc Screens) to export (via "Actions"):
- Check the "import-compatible" checkbox;
- Remove all fields to export;
- Look for "file" in available fields:
- Add the "New File (x_studio_binary_field_xxx_xxxxxxxxx)" field;
- Add its related "Filename for x_studio_binary_field_xxx_xxxxxxxxx (x_studio_binary_field_xxx_xxxxxxxxx_filename)".
- Export in XLSX format.
- In your computer's file explorer:
- Download or create a PDF file and copy its name;
- Open the XLSX file and paste the PDF filename in the 2 empty columns;
- Save and close the file.
- In the products' main view click "Import records" action button:
- Click "Upload Data File" and select the XLSX product file.
- Click "Upload your files" in the "Files to import" section on the left and select the PDF file.
- Click "Test" or "Import"
## Cause
This upload feature has been described in task 4077715. This specific lines seems to be based on another one a bit further in the code: https://github.com/odoo/odoo/blob/e42f5bee59daa0e270ae4803cc827009974da232/addons/base_import/models/base_import.py#L1289
## Fix
Allow all files base 64 conversion by removing a restriction on images only.
opw-4931579
Forward-Port-Of: odoo/odoo#229648