Tuesday, October 14, 2025
18 changes · 18.0
Enhancements to existing features
Updates Odoo's point of sale and related event/customer display flows so local IoT device connections continue to work as Chrome introduces stricter local network access rules. This helps avoid disruption for businesses using IoT hardware such as printers or displays from secure browser sessions.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/96850 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This commit simply adds this change where appropriate. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231014
This update prepares Odoo IoT and Point of Sale IoT connections for upcoming Chrome browser changes. It helps ensure local IoT devices can still be reached reliably when users access Odoo over HTTPS.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/231014 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This PR simply adds this change where appropriate. As part of this we have also backported the change from jquery -> fetch. task-5157145 Forward-Port-Of: odoo/enterprise#96850
Resolved issues and error corrections
This fixes an issue where accounting users limited to a company branch could not select accounts from the parent company when creating journal entries. The change ensures branch-only users can access the appropriate parent-company accounts, reducing blocked accounting workflows.
Original PR description
**Steps to reproduce:** - Install accountant - Create a company branch for a company - Create a non-admin user with Accounting rights and access to the branch only - Connect with the created user - Go to "Accounting / Accounting / Journal Entries" - Create a journal entry and try to set an account on a line **Issue:** There is no account available. The accounts from the parent company should be selectable. **Cause:** The accounts are searched with a "parent_of" domain on "company_ids" field, which is a many2many field. However, as the user doesn't have access to the parent company, the parent company is excluded from the search when parsing the domain. opw-5096437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The attendance auto-checkout process now correctly handles employees who checked in on a previous date. This prevents open attendance records from staying unclosed when the automated job runs after delays such as server downtime.
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
Invoice SEPA QR codes now consistently include the payment reference used for reconciliation when one is available. This prevents the QR code from falling back to a less precise customer reference, helping payments match invoices more reliably.
Original PR description
Issue: - While generating SEPA QR for invoices, we intended to use the payment reference (structured communication) to ease reconciliation. - A strict format validator caused structured refs to be invalid, and the QR fell back to the customer reference (unstructured comment). Fix: - Removed the strict validation for structured communication. - If a payment reference exists, put it in the structured field and clear the unstructured comment. - Only use the unstructured comment when no payment reference is provided. Impact: - QR codes consistently carry the intended payment reference. Task [link](https://www.odoo.com/odoo/project.task/5122875) task-5122875
Product imports that include custom Studio file fields can now correctly upload related files such as PDFs from XLSX imports. This prevents import errors and ensures attached documents are saved as expected when updating product records.
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-4931579Fiscal positions will no longer replace an active tax with an inactive one when preparing invoice lines. This prevents invoices from accidentally using taxes that have been disabled, improving tax accuracy and reducing manual corrections.
Original PR description
With this commit we exclude inactive taxes from the tax mapping of fiscal positions. Steps: - Create a fiscal position FP that maps an active tax to an inactive one - Create an invoice, set FP and create add an invoice line with a product having the active tax -> The tax mapping is applied and the inactive tax is set, it shoudln't opw-5117775
Corrects Spanish e-invoice XML generation so product prices with extra decimal precision and globally rounded taxes match the actual invoice values. This helps avoid rounding discrepancies, rejected electronic invoices, and incorrect totals in submitted Facturae documents.
Original PR description
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded…
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere. 2. When the tax rounding was set to round_globally, the TotalTaxOutput in the XML might differ from the actual tax_amount from the invoice because of rounding errors occurring during uncessary re-computation while building the XML. While stable is not the place to change all functions related, we can isolate computed tax output and tax withheld values and transmit them without any intermediary. As this file was changed in 18.0 another PR was needed from 17.0: https://github.com/odoo/odoo/pull/209623 (unit price decimals) and https://github.com/odoo/odoo/pull/229017 (tax rounding issue, detected after 209623 was closed) task-4650439
Gift Card and E-Wallet products will now appear in the Point of Sale screen even when the store is limited to selected product categories. This ensures staff can reliably sell these payment products without needing extra category setup.
Original PR description
Before this commit: =================== If the PoS configuration is restricted to specific categories, but the Gift Card and E-Wallet products do not have any category assigned, these products will not be visible in the PoS UI. After this commit: ==================== Gift Card and E-Wallet products are now always visible in the PoS UI, regardless of whether a PoS category is assigned or not. Purpose: ============ Gift Card and E-Wallet products should always be available for sale in the PoS. This ensures they can be sold physically from the PoS UI without requiring category assignment. Task-5103770
This fixes an issue in the HTML editor where typing next to a link inside formatted text could lose the intended styling. Users can now add links within styled text without unexpected formatting changes at the link boundaries.
Original PR description
Problem: If we add a link on a slice of formatted text we end up being able to type unformatted content at the link edges. Cause: After https://github.com/odoo/odoo/commit/3bcbd6f34facb9c88290dbd6496cc5103665a0a2 the `span` can be split and `feff`s are placed around the link, precisely between the link and the `span`. This allows writing unformatted content at the caret when placed between them. Solution: Ensure that the link is created inside the `span`. Also prevent the formatting applied by `.btn` when the link is inside a `span`. Steps to reproduce: 1. Add "abc". 2. Format all the text: set font size 48 (or whatever). 3. Select "b". 4. Create a link on "b" only. 5. Put caret before "a". 6. Press Arrow left. 7. Type any character. → The character is not formatted as the link content. task-5092298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change ensures the payment method information needed by SEPA direct debit is available from the core accounting module. It prevents installation or update failures when SEPA direct debit is used without the optional account payment module installed.
Original PR description
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from…
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from `account.payment.register`. This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`. This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail. To avoid this error, the field `payment_method_code` in the `account_payment` module needs to be defined instead in the `account` module. I open this PR on the recommendation of @hupo-odoo ([comment](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)). Here’s a screenshot of the error (runbot) <img width="1498" height="857" alt="runbot_account_sepa_direct_debit" src="https://github.com/user-attachments/assets/e8d66a96-59a3-4cf3-857b-e07a3337338c" /> Here’s the screenshot after changing to this commit <img width="1594" height="725" alt="image" src="https://github.com/user-attachments/assets/ea2fbe2c-31b8-4d61-8cf2-00e003ec3587" /> [OPW](https://www.odoo.com/es_ES/my/tasks/5139827) [PR enterprise](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477) @moduon MT-12067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The subscription MRR Breakdown report now only uses active companies when preparing its data. This prevents an access error that could occur after archiving an old company and changing currency settings, allowing users to open report details reliably.
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
Mobile users can now tap spreadsheet dashboard charts to open the related Odoo menu, matching the desktop experience. This makes dashboards easier to use on phones and tablets and reduces confusion when interacting with chart links.
Original PR description
Current behavior before PR: - Clicking on a chart in mobile did nothing, unlike on desktop where it redirects to the linked Odoo menu. Desired behavior after PR is merged: - Clicking on a chart in mobile also redirects to the corresponding Odoo menu. - The test has been refactored to remove duplication and improve readability. Task: [4884509](https://www.odoo.com/odoo/2328/tasks/4884509) Forward-Port-Of: odoo/odoo#225372
The Swiss payroll wage type setup now exposes all backend configuration fields directly in the salary rule interface. This helps payroll administrators review and maintain ELM transmission settings more reliably without needing technical access or hidden configuration steps.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
This fixes an issue where a Point of Sale session could not be closed after processing a negative order paid with a bank method requiring customer identification. The change helps avoid blocked cashier workflows and ensures session closing works even when payment setup is incomplete.
Original PR description
When using a bank payment method that needs to identify the customer, if you made a pos order with negative amount, the session would get stuck when trying to close it. Steps to reproduce: ------------------- * Create a bank payment method and check the option "Identify Customer" * Open a POS session * Make a pos order with a negative amount * Pay the order with the bank payment method * Close the session > Observation: There is an error and you cannot close the session. Why the fix: ------------ If the payment method has no oustanding account set, it will violate an sql constraint when trying to close the session. sql constraint: account_move_line_check_accountable_required_fields opw-4939806
The attendance system now correctly calculates when an employee has been checked in for more than 24 hours. This ensures old open attendances are automatically checked out as intended, improving accuracy in attendance and overtime records.
Original PR description
`.seconds` returns the seconds component of the timedelta, after extracting the days. For attendances checked in more than 24 hours ago (processed by the cron, see `previous_attendances` search domain), `total_seconds()` will correctly return the number of elapsed seconds. no-task
Spreadsheet list side panels now keep working even if a field was removed during a migration or after deleting a custom field. This prevents users from being blocked when editing affected lists and makes migrated or customized spreadsheets more resilient.
Original PR description
If a field disappeared from a list following a migration or a deleted custom field, the list could no longer be edited in the sidepanel because we tried to access the missing field info (name & string) Task-4915281
Reverse charge taxes can no longer be configured as included in the displayed price, and the tax calculation now always treats them as excluded. This prevents incorrect tax handling and helps keep accounting results consistent with reverse charge rules.
Original PR description
After this commit, you no longer can set a custom "price_include_override" on a tax using the UI. Even if you do, the tax engine forces such tax to be price-excluded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr