Wednesday, December 17, 2025
15 changes · saas-18.3
Resolved issues and error corrections
This update resolves a minor issue where the websocket connection could unexpectedly drop during user logout tests. The fix ensures a reliable reconnection process, guaranteeing that the test consistently establishes a new connection after a logout. This improves the stability and predictability of our testing procedures.
Original PR description
Before this commit, the `websocket disconnects when user logs out` was sometimes failing. This test ensures that the websocket reconnects when the user logs out. When the environment is initially…
Before this commit, the `websocket disconnects when user logs out` was sometimes failing. This test ensures that the websocket reconnects when the user logs out. When the environment is initially created, a lot of places call the `bus_service@start` method. The worker starts the websocket when receiving the first event, and discard the others. However, in this case, the call to `_start` can happen before the closing handshake is completed. As a result, the websocket is still in closing mode and the handshake is aborted. Since the disconnection wasn't clean, the `reconnect` event is triggered instead of the `connect` one. This is not a big deal and shouldn't impact the test. What matters is that a new connection is established. This commit fixes the issue by checking that a reconnection is done, either via the `connect` or the `reconnect` event. fixes runbot-234056 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#240247
This update refines the configuration of the Account EDI Proxy Client to ensure accurate participant registration across different localization settings (My Accounting and Italy). The change removes a previous restriction and restores a necessary constraint, preventing duplicate registrations and improving system stability.
Original PR description
This commit removes the `unique_active_edi_identification` constraints from the _auto_init of `account_edi_proxy_client` client user model, and adds back the constraint on `l10n_my_edi` and `l10n_it_edi` to make it apply only to those localizations. task-4852830 Forward-Port-Of: odoo/odoo#224811
This update resolves an issue where the snippet modal's background color wasn't consistently displayed across browsers (Chrome, Firefox, Safari). It also ensures that text within the snippet modal respects the user's chosen color scheme, providing a better and more reliable dark mode experience. This improves usability for all users.
Original PR description
This commit aims to fix two issues with the snippet modal in dark mode: 1. Streamline the background color accross browsers. Chrome takes into account the classes on the iframe for the background…
This commit aims to fix two issues with the snippet modal in dark mode: 1. Streamline the background color accross browsers. Chrome takes into account the classes on the iframe for the background color but Firefox and Safari don't. 2. The text below the custom snippets is always black, regardless of the color scheme selected. These 2 issues are fixed by using the color-scheme cookie value inside the snippet modal's iframe, adding as a meta tag and a custom class. task-5095262 | Browser(s) | Before | After | |--------|--------|--------| | Firefox/Safari | <img width="1192" height="847" alt="image" src="https://github.com/user-attachments/assets/f38f4944-3379-4300-8ec7-78a73dcce7f1" /> | <img width="1174" height="828" alt="image" src="https://github.com/user-attachments/assets/06e93051-737e-4abe-b937-79ce9a4e0a33" /> | | Chrome | <img width="1171" height="828" alt="image" src="https://github.com/user-attachments/assets/c5f1fcb4-eb55-4a26-83f5-e2c3c65ad0dd" /> | <img width="1174" height="833" alt="image" src="https://github.com/user-attachments/assets/c4066e4d-876c-455c-92eb-1ab0e115500c" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227751
This update corrects a bug where a procurement group wasn't consistently linked to deliveries when multiple moves were added to a picking. The change ensures that a procurement group is always created and linked, regardless of whether a sale order is associated, improving the accuracy of inventory tracking and order fulfillment. This resolves an issue impacting order processing efficiency.
Original PR description
### Steps to reproduce: - Create a picking with a move for any product #### Issue 1: > A procurement group is created and linked to the transfer - Add a second move on the picking and save #### Issue 2: > The procurement group of the picking is lost ### Cause of the issue: The `_set_sale_id` set method creates a procurment group and links it to the picking no matter if the `sale_id` is set or not. https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L90-L93 https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L100-L113 opw-5386424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239697
This update prevents HR users from receiving unnecessary reminder emails. The fix filters out time-off and holiday entries when sending reminders, ensuring that notifications are only sent for actual timesheets requiring user input. This improves efficiency and reduces email clutter.
Original PR description
**Steps to reproduce:** - Install timesheet_grid_holidays - Create a user with no timesheet access - Create a leave and approve it as a manager - Set up employee reminders in timesheet settings - Run the timesheet reminder scheduled action **Issue:** HR users without timesheet app access or who haven’t submitted timesheets in the past 3 months were still receiving reminder emails. **Cause:** When a time-off is approved or a public holiday is recorded, it generates timesheet entries, which causes reminder emails to be sent incorrectly. **Fix:** Filter out time-off and public holiday entries when sending reminders. Now, reminders are only sent for actual timesheets that require user input. task-5085790 Forward-Port-Of: odoo/enterprise#101984 Forward-Port-Of: odoo/enterprise#95450
A test was failing due to inconsistencies in date handling between online and offline POS systems. This fix ensures the test accurately reflects how the system behaves when not connected to the internet, preventing future disruptions. The change uses a reliable data source to build the date, ensuring consistent test results.
Original PR description
**Why the fix:** The date was frozen in the backend but it did not work in the case where we are offline. This happens because when offline we get the date in the frontend by creating a *new Date()*, which is not affected by either the backend or the frontend freezeDate. This means that when the year changes, this test would fail, as we check that the year is 2025 by hardcoding it. To avoid this, we now use the pos_reference value to build this part back together. runbot-233565 Forward-Port-Of: odoo/odoo#238113
This update ensures that orders processed through the UrbanPiper POS system are automatically marked as paid once they are dispatched. This change addresses a dependency issue and utilizes a similar process to previously handled order statuses. It improves the accuracy of order tracking and streamlines the payment process for UrbanPiper transactions.
Original PR description
Since `pos_urban_piper` module is not in the dependency of `pos_blackbox_be`, we need to add a blank method `_fetchUrbanpiperOrderCount` that will be overriden in both module. It's the same mecanism as what's been used for `_doneOrder`. task-id: 5261892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239228
This update resolves an issue where invoices posted at early times in the Chilean timezone were incorrectly interpreted as being in the previous day, leading to errors. The fix ensures invoice dates are handled correctly, preventing this problem and improving invoice processing reliability.
Original PR description
**Issue:** ```python File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation raise UserError( odoo.exceptions.UserError: The stamp date and time…
**Issue:**
```python
File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```
**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).
**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp
Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518
Forward-Port-Of: odoo/enterprise#102127
Forward-Port-Of: odoo/enterprise#101901This update resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Overtime) and the LPP (Lohnsteuer-Pauschbetrag) tax deduction. The fix ensures accurate tax and payroll reporting for Swiss businesses using the Odoo Enterprise module.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update fixes an issue where optimized Odoo deployments failed to start if the `payment_stripe` module wasn't present. The change silently handles missing dependencies, ensuring Odoo starts correctly even without the Stripe payment module. This improves the overall stability and reliability of Odoo deployments.
Original PR description
Description of the issue/feature this PR addresses: The `payment` module does not declare a dependency on the `payment_stripe` module but the code implicitly depends on it. This makes a problem in optimized deployments where the `payment_stripe` module is not included. Current behavior before PR: Optimized Odoo deployments without `payment_stripe` fail to start because of a `ModuleNotFoundError`. Desired behavior after PR is merged: If the module is not available, the import error is silently ignored and the `is_stripe_supported_country` calculation returns `False`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240131 Forward-Port-Of: odoo/odoo#239562
This update corrects a formatting problem in invoices generated when using quotation templates in sales orders. Previously, the name and description were combined on the invoice PDF. This fix ensures that descriptions are correctly separated with a new line, improving invoice clarity and consistency for users.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. read: #235122 opw-5130171 Forward-Port-Of: odoo/odoo#240177 Forward-Port-Of: odoo/odoo#237110
This update corrects a formatting problem in invoices generated when using quotation templates in sales orders. Previously, the invoice PDF displayed product names and descriptions on the same line, creating an unreadable format. This fix ensures descriptions appear on separate lines, improving invoice clarity and professionalism.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. opw-5130171 Forward-Port-Of: odoo/enterprise#102208 Forward-Port-Of: odoo/enterprise#100417
This update resolves an issue where large product images on the Shop page were being blurred due to how they were being sized. The fix ensures product images maintain their original aspect ratio, displaying correctly regardless of their size. This improves the visual presentation of products for customers.
Original PR description
Steps to reproduce: =================== 1- Add a product with a very large image width & publish product. 2. Go to the Shop page & type product name. -> The product image is blurred. Cause: ====== The product images have `h-100 w-100` classes which force them to fill the container dimensions exactly, ignoring their intrinsic aspect ratio. Solution: ========= Add the `object-fit-contain` class to the image. This ensures the image scales to fit within the container while preserving its aspect ratio. Side note: `object-fit-contain` class will be added only in version 17.0 In the next versions the class already exists. opw-5258658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239506 Forward-Port-Of: odoo/odoo#238108
This update ensures that rental orders created from leads automatically include the tags associated with the original lead. Previously, rental orders lacked this functionality due to a minor difference in how context information was passed. This change streamlines the process of tagging rental agreements, improving organization and reporting.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a lead with tags; 2. convert lead to rental order. Issue ----- The new rental order has no tags. Cause ----- Tags are added to regular sales orders via the `_prepare_opportunity_quotation_context` method, but rental orders use `_get_action_rental_context` instead, which is virtually identical, but adds the `in_rental_app` context value, and doesn't include `default_tag_ids`. Solution -------- Rather than having duplicate code, make `_get_action_rental_context` retrieve the base context from `_prepare_opportunity_quotation_context`, then adding `in_rental_app=True`. opw-4549941 Forward-Port-Of: odoo/enterprise#102220
This update resolves an issue where copying and pasting empty list items within the HTML editor would prevent the backspace key from working. The fix now automatically inserts a line break (<br>) into the pasted item, ensuring proper backspace functionality and preventing editing problems.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a new paragraph, type some text. - Create a numbered list below paragraph, type some text. - Keep the cursor at the start of list text and select the above text - Copy the selection and paste in a new paragraph. - Backspace in pasted list is not working. This happens because pasted list item is empty. **Desired behavior after PR is merged:** Now, copied empty list item is filled with `<br>`, as result backspace works properly. task-5226511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234869