Wednesday, December 17, 2025
7 changes · 19.0
New functionality added to Odoo
This pull request focuses on enhancing Odoo's internal documentation. The team added new documentation related to various internal architecture and development processes, including module dependencies, inheritance patterns, and the Odoo layering system. This update aims to improve clarity and support for internal development teams.
Resolved issues and error corrections
Odoo now correctly recognizes Epson TM-m30 devices as receipt printers even when they are discovered through different network methods. This helps avoid printers being treated as office printers and supports better automatic setup, including clearer handling for label printers using ZPL.
Original PR description
Before this commit, the receipt printer subtype was assigned based on the presence of `CMD:ESC/POS;` in the `device-id` of the printer. However, this string was only present for the `lpd` backend, for `dnssd` it was not resulting in a subtype of Office printer. After this commit, we additionally check for the string `TM-m30` in the device name, and if it is present we set it as a receipt printer. We also check for the string `ZPL` and if found set it as a label printer. task-5411994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240255 Forward-Port-Of: odoo/odoo#240171
This fixes an issue where sharing a project task could save the wizard without the selected task, causing the send action to fail in newer versions. The task is now correctly linked when the share wizard opens, so users can send task sharing invitations reliably.
Original PR description
**Steps to reproduce:** 1. Install Project with demo data 2. Go to Tasks → cog menu → click on "Share Task" 3. Click on the "Send" button **Issue:** The `task_id` becomes NULL in the task share…
**Steps to reproduce:** 1. Install Project with demo data 2. Go to Tasks → cog menu → click on "Share Task" 3. Click on the "Send" button **Issue:** The `task_id` becomes NULL in the task share wizard. ```psql test_m19=> select id,res_id,task_id,res_model from task_share_wizard; id | res_id | task_id | res_model ----+--------+---------+-------------- 1 | 34 | | project.task (1 row) ``` In master (19.1), this leads to a crash: ```AssertionError: Invalid falsy real id``` This happens since commit [4290724](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f), where falsy IDs are no longer allowed. **Cause**: When clicking on the "Send" button, the wizard relies on [default_get](https://github.com/odoo/odoo/blob/174d5dc63048720533708b8ae4d1ad34774caabe/addons/portal/wizard/portal_share.py#L10-L18) to populate default field values. However, a falsy value is passed to the `task_id` from [here](https://github.com/odoo/odoo/blob/0a97fa64783e4b58bb17db79343fb566196e71eb/odoo/orm/models.py#L1306-L1307) since `self` is a empty record set and later during [related field](https://github.com/odoo/odoo/blob/0a97fa64783e4b58bb17db79343fb566196e71eb/odoo/orm/fields.py#L720) computation, resulting in an invalid falsy record. **Solution**: Ensure that task_id is properly set during `default_get`. **After fix:** ```psql test_m19=> select id,res_id,task_id,res_model from task_share_wizard; id | res_id | task_id | res_model ----+--------+---------+-------------- 3 | 34 | 34 | project.task (1 row) ``` opw-5342875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an automated Point of Sale test from failing when the calendar year changes. It removes a hardcoded year dependency so test results stay reliable, especially when offline behavior is involved.
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#240044 Forward-Port-Of: odoo/odoo#238113
The snippet selection window now uses the user’s dark or light mode preference consistently across Chrome, Firefox, and Safari. This improves readability by fixing mismatched backgrounds and text that stayed black in dark mode.
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 fixes a misleading warning message displayed in the eCommerce shop when a subscription product is viewed without a linked plan. The change ensures users receive a clear and accurate message – 'This product has no valid combination' – preventing confusion and potential order errors. This improves the user experience and ensures accurate product information.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Install website_sale_subscription - Create a subscription product without a plan - Open product on eCommerce Issue: - When viewing a subscription product without a subscription plan in the eCommerce shop, the system incorrectly shows the warning "This subscription is not compatible with the one already in your cart. Please order them separately or empty your cart." - This happens even if the cart is completely empty. - The method _is_add_to_cart_possible doesn’t find any valid combination to add to the cart, and because the product is marked as recurring, it always triggers the wrong message. Solution: - Add a condition to check if current product have any recurring price set if not then it will show the correct warning that 'This product has no valid combination.' Impact: - Users see clear and correct warnings on products without a subscription plan. task-5255749 Forward-Port-Of: odoo/enterprise#100929
This update corrects an issue where invoices posted at early times in the Chilean timezone were incorrectly dated as the previous day, causing validation errors. The fix ensures consistent invoice dates during testing by freezing the test time and setting a fixed invoice date aligned with the timezone.
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#101901