Friday, July 25, 2025
18 changes · saas-18.4
Enhancements to existing features
Swiss companies can now more easily configure EU One Stop Shop reporting for B2C goods sales to customers in EU countries. The change adds tax mapping between Switzerland and EU countries, improving setup and discoverability for cross-border VAT compliance.
Original PR description
Make it easy for any Swiss company that wants to operate B2C sales of goods to customers located in the EU to take advantage of the EU One Stop Shop (OSS) Module, aka l10n_eu_oss_reports. We will ease the discoverability and the configuration Adding the Tax Mapping between Switzerland and the rest of the EU countries task-4943589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220260 Forward-Port-Of: odoo/odoo#219380
Updates the Canadian localization to reflect Nova Scotia's Harmonized Sales Tax reduction from 15% to 14% effective April 2025. This ensures invoices, accounting entries, and tax reporting can use the correct Nova Scotia tax rate while preserving the existing 15% rate for other provinces that still require it.
Original PR description
Following a change in April 2025, Nova Scotia's Harmonized Taxes (HST) has been changed from 15% to 14%. As such new taxes, accounts, and groups had to be added to account for this change. As this is only for Nova Scotia and none of the other provinces we cannot archive the taxes and groups since New Brunswick, Newfoundland, and Labrador still use it. task-4937159 Legal reference: https://www.canada.ca/en/revenue-agency/services/tax/businesses/topics/gst-hst-businesses/charge-collect-which-rate.html Forward-Port-Of: odoo/odoo#220004 Forward-Port-Of: odoo/odoo#219117
Resolved issues and error corrections
Point of Sale now only shows the product categories explicitly selected in the restriction settings. This prevents empty child categories from appearing to cashiers when a business chooses to limit visible categories, making the sales screen clearer and less confusing.
Original PR description
## Short functional explanation of the error When a category is the child of another category, it is always displayed, despite specifying in the settings that we don't want to display the child. ##…
## Short functional explanation of the error When a category is the child of another category, it is always displayed, despite specifying in the settings that we don't want to display the child. ## Reproduction Steps 1. Go to settings. In "Product & PoS categories", check "Restrict categories", click on PoS Product Categories and create 2 new categories: a parent category and a child category. 2. Close the settings and go to Products and create 2 different products: one to which you'll assign the parent category and one to which you'll assign the child category. 3. Go back to settings. In "Product & PoS categories", under "Restrict categories", only select the parent category. 4. Go to Point of Sales and click on the parent category. ### Expected behavior Only the parent categories and the parent product should show. ### Unexpected behavior The child category shows, with no products inside. ## Origin of the issue This behavior was previously expected. Therefore, there was a line in pos_category.py that would add to the available categories the children of each available category. opw-4877405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216310
This fix removes line breaks from product descriptions in Italian electronic invoices before they are sent to the SDI tax portal. It prevents invoice submissions from being rejected when a product description contains multiple lines.
Original PR description
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on…
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on send 5. Only enable Send to Tax Agency. 6. Click "Send" again. 7. Go to the Attach files and download the attachment. 8. Check the `<Descrizione>` (description) in the XML file. **Issue:** The `<Descrizione>` field in the `<DettaglioLinee>` tag includes newline characters, which are not accepted by SDI portal. **Causes:** The line description is using '\n'.join(...), which results in actual newline characters in the XML. https://github.com/odoo/odoo/blob/ca7de6b2fbe4626583b67a34d77bbb523d972f79/addons/account/models/account_move_line.py#L513 https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/l10n_it_edi/models/account_move.py#L316-L324 **Solution:** To fix this, replace newline characters in the description with spaces and Strip leading/trailing whitespace. This ensures SDI receives a single-line <Descrizione>value. **Before fix:**  **After fix:**  Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4808826) opw-4808826 co-authored by: Raj Bhuva (bhra@odoo.com) Forward-Port-Of: odoo/odoo#218168
The editor now again converts links pointing to the same website into shorter internal links, with the option enabled by default. This helps avoid exposing Odoo instance domains in published pages and keeps links cleaner and more portable.
Original PR description
*: html_builder This commit restores the feature (lost during the website builder refactoring [1]) that automatically converts absolute URLs pointing to the origin domain into relative URLs. It also introduces a heuristic to detect links pointing to the user's own Odoo instance domain (e.g., https://mydb.odoo.com/...) and treats them as internal links. In both cases, a checkbox (enabled by default) allows the user to opt into this conversion. Mentioning .odoo.com instance domains (especially one’s own) in published URLs is discouraged and considered bad practice. ex: url: http://localhost:8069/contactus [x] Autoconvert to relative link [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Improves Greece myDATA e-invoicing by fixing VAT formatting, error handling, PDF generation, and invoice type calculation issues. It also makes setup easier by moving myDATA options into settings and adding sensible default classifications for invoices.
Original PR description
First major fixes and improvements for Greece EDI. task-4781479 Forward-Port-Of: odoo/odoo#218927 Forward-Port-Of: odoo/odoo#209078
This fix prevents IoT boxes from deleting existing drivers when a driver download fails or returns an invalid file. It helps keep connected hardware working even if the linked database is offline or temporarily unavailable.
Original PR description
Before this commit, if the IoT box was connected a DB which then went offline (e.g. expired runbot), and it tried to download drivers, the request would fail but it would still delete the old handlers. After this commit, we avoid this problem in two ways. Firstly, we check that we received an OK HTTP status before trying to process the response body. Secondly, we check that the reponse we have received is a valid zip file BEFORE deleting the old handlers. This way we only delete them if we are sure we have something to replace them with. task-4933638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219271 Forward-Port-Of: odoo/odoo#218163
Fixes an error that occurred when users clicked Indirect Subordinates in an employee's organization chart. This keeps the Employees app navigation reliable and prevents users from being blocked by a crash when viewing reporting relationships.
Original PR description
A traceback occurs when clicking Indirect Subordinates in the Organization Chart of an employee. Steps to reproduce the error: - Install ``hr`` module with demo data - Go to Employees > Open…
A traceback occurs when clicking Indirect Subordinates in the Organization Chart of an employee. Steps to reproduce the error: - Install ``hr`` module with demo data - Go to Employees > Open ``Mitchell Admin`` - In the Organization Chart, click the number next to Mitchell Admin. - Then click Indirect Subordinates. Traceback: ``` TypeError: inconsistent models in: hr.employee(1, 6, 5) - hr.employee.public(5,) ``` In this [commit], ``subordinate_ids`` field was changed to be related to ``employee_id.subordinate_ids``. https://github.com/odoo/odoo/blob/cc65ae3854f845e5cc87cb808c4707279bf28be0/addons/hr_org_chart/controllers/hr_org_chart.py#L89 So, ``subordinate_ids`` now returns records of the ``hr.employee`` model. ``child_ids`` is the records of ``hr.employee.public`` model. So, This leads to a traceback at the above line, where it expects consistent models. [commit]: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759 sentry-6752005852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening the Employees app could fail for non-admin users when homeworking attendance showed someone as working from the office. This update aligns the public employee view with the same status options as the main employee record, preventing the error and restoring access.
Original PR description
Currently an error occurs when we open Employees app with a non admin account. Steps to replicate: - Install `hr_homeworking` with demo data. - Login with admin and open `Employee > Mitchell Admin`…
Currently an error occurs when we open Employees app with a non admin account. Steps to replicate: - Install `hr_homeworking` with demo data. - Login with admin and open `Employee > Mitchell Admin` form view. - On the Work tab you'll find the seven days of the week, set today's field to 'Office'. (For Ex: If Today is monday so fill in Office for monday). - Now Logout and login through some other account like Marc Demo. Open Employees and you will get the error. Error: `ValueError: Wrong value for hr.employee.public.hr_icon_display: 'presence_office'` This error occurs after a recent [refactor](https://github.com/odoo/odoo/pull/202869) in the code and that time they forgot to add the other values for `hr_icon_display` field. In saas-18.3 [1], the code directly inherited from the base model `hr.employee.base`. However, in saas-18.4 [2], the refactor split the code into `hr.employee` and `hr.employee.public`, only `hr.employee` includes the new selection items, while `hr.employee.public` does not. This caused the wrong value error. [1] - https://github.com/odoo/odoo/blob/aa8b09ca61dfd405ebebbeff4e45a08bf7ad84fd/addons/hr_homeworking/models/hr_employee.py#L8-L24 [2] - https://github.com/odoo/odoo/blob/850e575b71b04597d31140cec53a596456370325/addons/hr_homeworking/models/hr_employee.py#L8-L24 This commit solves this issue by adding the necessary values to the `hr_icon_display` field. sentry-6731346730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project task recipients are now automatically added as followers when a task is shared or when they are contacted through the task chatter. This fixes cases where customers received a share or message but still could not see the task in the portal.
Original PR description
Before this commit, when a task was shared through the share wizard or when a message was sent to a customer via the chatter, the recipients were not added as followers of the task. As a result, they couldn't see the task in the portal. This commit ensures: - Recipients are now added as followers of the task when it is shared with them through the wizard. - A message to a customer in the chatter also adds them as a follower of the task. task-4781259 Forward-Port-Of: odoo/odoo#220195 Forward-Port-Of: odoo/odoo#211169
This fixes overtime calculations when employees use extra hours for time off. Attendance now counts only the relevant daily overtime entry, preventing duplicate overtime records from distorting extra-hour balances.
Original PR description
When you create an attendance entry it will create an attendance overtime entry corresponding to that day. The relation is used to count the ammount of extra hours in that day. Only one overtime is expected per day in order for it to work properly. The issue arises when you create a time off using extra hours. That will also create an overtime This commit aims to filter the overtimes when counting the extra hours. The same was used before a refactoring that happened in a fix [bc1f2cdf3b8d448c9522311393aad728a33a2404] which aparently removed it. opw-4806193 Forward-Port-Of: odoo/odoo#219435
This fixes Spanish TicketBAI reporting so credit notes created using the differences method show negative amounts where required. It helps ensure invoice corrections, tax totals, and POS-related credit notes are reported accurately to the tax authorities.
Original PR description
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#220300 Forward-Port-Of: odoo/odoo#217172
Self-service POS orders are now sent to preparation only after payment succeeds when an online or terminal payment method is configured. This prevents unpaid kiosk orders from reaching staff too early, while still allowing mobile self-orders to proceed without payment when no online payment option is available.
Original PR description
pos_self_order*: pos_online_payment_self_order, pos_self_order_adyen, pos_self_order_razorpay, pos_self_order_stripe Ensure self-orders are sent to the preparation display only after a successful payment, when a valid payment method is configured. **Issue 1: Orders sent for preparation before successful payment** **Steps:** - Configure the kiosk with an online or terminal payment method. - Open the kiosk, add products, and proceed to payment. **Issue:** - Preparation orders were being sent even if the payment was not completed. **Fix:** - Restrict preparation flow to only orders with a successful payment when a valid payment method is configured. --- **Issue 2: Orders not sent for preparation in mobile mode without the online method** - Allow unpaid orders to be sent for preparation only in mobile mode when no online payment method is configured. Task-4845410 Related: https://github.com/odoo/enterprise/pull/87173 Forward-Port-Of: odoo/odoo#213493
Fixed an issue in the website editor where pressing backspace after selecting content across paragraphs could remove text beyond the selected area. This helps prevent accidental loss of content while editing pages or rich text.
Original PR description
Problem: Given content like: ``` <p>keep<br>[delete</p> <p>delete<br>delete<br>]</p> <p>keep</p> ``` Pressing backspace removes the last "keep" as well, which is incorrect. Cause: The merge logic uses `range.endContainer` as `joinWith`, but does not account for `range.endOffset`. When `range.endContainer` is a `<p>` with a non-zero offset, the condition `next.previousSibling && next.previousSibling === joinWith` fails. During merging, `next` may go inside `joinWith`, making the logic invalid. Solution: Prevent merging when `next` is positioned exactly at `range.endOffset`, preserving the correct boundary. Steps to reproduce: - Add the sample HTML to the editor - Select from `[delete` to `delete]` - Press backspace -> The final `<p>keep</p>` is deleted incorrectly opw-4905047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220163 Forward-Port-Of: odoo/odoo#219392
When a helpdesk ticket is shared or a customer is messaged, those recipients are now automatically added as followers. This ensures they can access the ticket through the customer portal, reducing confusion and follow-up support requests.
Original PR description
Before this commit, when a ticket was shared through the share wizard or when a message was sent to a customer via the chatter, the recipients were not added as followers of the ticket. As a result, they couldn't see the ticket in the portal. This commit ensures: - Recipients are now added as followers of the ticket when it is shared with them through the wizard. - A message to a customer in the chatter also adds them as a follower of the ticket. task-4781259 Forward-Port-Of: odoo/enterprise#90830 Forward-Port-Of: odoo/enterprise#86169
Chilean electronic factoring files now show the transferred invoice total in Chilean pesos, even when the original invoice uses another currency. This prevents incorrect regulatory XML values and helps ensure AEC files match local reporting requirements.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MntTotal tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on Send Now to SII and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MntTotal is in selected currency which is wrong related: https://github.com/odoo/enterprise/commit/4e97c5d008c2879c5d014203fafc2c125d6c5ae7 opw-4830957 Forward-Port-Of: odoo/enterprise#90232
Self-order kiosk and mobile orders are now only sent to the preparation display after payment succeeds when a payment method is configured. This prevents staff from preparing orders that customers have not paid for, while still allowing mobile unpaid orders when no online payment option is available.
Original PR description
pos_self_order*: pos_online_payment_self_order_preparation_display, pos_self_order_preparation_display Ensure self-orders are sent to the preparation display only after a successful payment, when a valid payment method is configured. **Issue 1: Orders sent for preparation before successful payment** **Steps:** - Configure the kiosk with an online or terminal payment method. - Open the kiosk, add products, and proceed to payment. **Issue:** - Preparation orders were being sent even if the payment was not completed. **Fix:** - Restrict preparation flow to only orders with a successful payment when a valid payment method is configured. --- **Issue 2: Orders not sent for preparation in mobile mode without the online method** - Allow unpaid orders to be sent for preparation only in mobile mode when no online payment method is configured. Task-4845410 Related: https://github.com/odoo/odoo/pull/213493 Forward-Port-Of: odoo/enterprise#87173
This fix prevents errors in Mexico payroll and salary offer calculations when an employee does not yet have an initial contract start date. Payroll now uses safe default values so recruiters and payroll teams can continue salary configuration and payslip calculations without interruption.
Original PR description
Before this fix, various computations relying on `employee.first_contract_date` fails if the value was missing, notably: - `_compute_integration_factor` in payslips - Python expressions in MX salary rules (holiday bonus, ISR, etc.) Steps to reproduce: Install the following modules: - Recruitments, Payroll, Salary Configurator - Mexico - Payroll, Mexico - Payroll - Localisation, EDI for Mexico Go to Recruitment -> create or click on application in any offer -> click on generate offer(create a contract templates if needed) -> Click on Salary Configurator, notice the Invalid Operation Error After fix: - Default the integration factor to 1 and years worked to 0 when no start date exists - Safely guard salary rule conditions and computations with proper checks This ensures robust payroll calculation even for employees without an initial contract date. opw-4853613 Forward-Port-Of: odoo/enterprise#90648