Thursday, March 12, 2026
10 changes · saas-18.3
Resolved issues and error corrections
A test was failing due to an issue with how the system handles time zones. The fix corrects a calculation error that resulted in an incorrect date being generated, specifically when the system's time zone is set differently from the test environment. This ensures the test consistently passes.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
This update reverts a recent change that was causing unnecessary complexity in warehouse replenishment workflows. Previously, multiple pickings were automatically combined for supply chains, which now leads to a simpler process and reduces manual effort for users. This change prevents the creation of redundant pickings and streamlines operations.
Original PR description
This reverts [1]. Let's quote the commit: > - `Observation`: the next transfers for both receipts are merged into a single > transfer, even though both receipts were created manually and not generated > from any common source document like PO/SO. The above behavior was and is the expected one for years and should not suddenly change on stable. Even the tests were protecting the cases but [1] have changed the `assert`. Commit [1] quickly leads to the creation of tickets. For instance, in the mentioned OPW, where the user resupplies a warehouse from another one: he now has several pickings for the same supply chain, which lead to extra work (e.g., printing all the pickings) [1] https://github.com/odoo/odoo/commit/840b42fd2365a652e53d607f38ac78ccb8dd63dc OPW-6011532 Forward-Port-Of: odoo/odoo#253054
This change reverts a previous issue caused by a related update. It restores the initial state of quality control tests, ensuring they function correctly. This resolves a disruption to the testing process and maintains the stability of the quality control module.
Original PR description
This reverts [1]. It happens because of a revert OC side, cf linked commit. [1] a01d8f0e15de973a94c360c3911e74b768a3aebc OPW-6011532 Forward-Port-Of: odoo/enterprise#110133
This update fixes an issue where product availability emails were sending images at full size, resulting in large email attachments. The change ensures images are appropriately sized for these emails, improving email performance and reducing storage needs. This enhancement impacts the user experience by delivering more efficient and manageable email notifications.
Original PR description
Steps to reproduce in local: 1. Install `website_sale_stock` 2. Make a product variant with an image 3. To make it easy set field `Back in stock Notifications`'s value on this product with the help…
Steps to reproduce in local:
1. Install `website_sale_stock`
2. Make a product variant with an image
3. To make it easy set field `Back in stock Notifications`'s value on this product with the help of the studio
4. Add a person to receive notification in this field
5. Don't set Outgoing email server
6. Run cron `Product: send email regarding products availability` manually
7. To Check sent email go to `Setting > Technical > Email > Emails`
Issue:
- The image is a full-size image
<table>
<tr>
<th style="text-align: center;">Before</th>
<th style="text-align: center;">After</th>
</tr>
<tr>
<td style="text-align: center;">
<img width="1395" height="728" alt="Before"
src="https://github.com/user-attachments/assets/a3fe3b38-c4a5-4a78-a63a-552c96cfdf84" />
</td>
<td style="text-align: center;">
<img width="1383" height="662" alt="After"
src="https://github.com/user-attachments/assets/8c346302-4295-44f2-8172-6a01072b23c7" />
</td>
</tr>
</table>
opw-5915587
Forward-Port-Of: odoo/odoo#249000This update fixes an issue where customers could inadvertently set subscription start dates to 'false,' resulting in incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are properly tracked and billed accurately. This resolves a potential revenue discrepancy.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update fixes a potential error in how Odoo fetches Instagram poll IDs. Previously, the system would sometimes receive an error from Instagram when trying to retrieve the ID before the poll was fully published. Now, Odoo waits for the poll to be published before requesting the ID, preventing errors and ensuring reliable poll functionality. This improves the overall stability of Instagram integration.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
This update fixes a bug where excessive warnings were being generated due to how Odoo uses the Werkzeug library. The fix ensures warnings are properly deduplicated, preventing continuous, unintended warning messages. This resolves a problem exacerbated by workers in the system.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252427 Forward-Port-Of: odoo/odoo#252193
This update fixes a visual inconsistency in the mega menu on mobile devices. Changing the navbar font style caused the back arrow to display with an incorrect font. The fix ensures the back arrow uses the standard Odoo UI icon font, maintaining a consistent and professional appearance.
Original PR description
Steps to reproduce: =================== 1. Go to webstie and add a mega menu 2. Change Navbar font (e.g. to "Arvo") 3. Switch to mobile view and open the mega menu -> the back arrow will have unexpected style. Cause: ====== The selector `.navbar .nav-link` applies the custom navbar font-family (e.g., "Arvo") to all `.nav-link` elements inside the navbar. The mega menu back button has classes `btn nav-link oi oi-chevron-left`, so it matches this selector. Since `.navbar .nav-link` has higher specificity than the base `.oi` class, the custom font overrides `font-family: 'odoo_ui_icons'`. Solution: ========= force the .oi font-family. opw-5949405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251394
A visual bug was resolved where the logo for the Extra Hours leave type was incorrectly displayed. The developer corrected this by re-adding the necessary SVG file and attachment data, ensuring the correct logo is now shown on the Time Off dashboard.
Original PR description
Steps to reproduce: 1. Install hr_holidays. 2. Go to the Time Off dashboard. Issue: The logo for Extra Hours is incorrectly set as the Compensatory Days leave logo. Solution: The issue occurred because the SVG file and attachment data for the icon were missing. I have added them again. Before FIX:- <img width="1693" height="865" alt="before_fix_logo" src="https://github.com/user-attachments/assets/83077331-e42f-4c39-8fb6-b46834312774" /> After Fix:- <img width="1657" height="884" alt="After_fix_logo" src="https://github.com/user-attachments/assets/9d46c91d-ae87-497f-9055-a66decf5b48e" /> 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 update fixes a bug preventing loyalty discounts from being applied to sales orders using different currencies. Previously, rounding issues caused discounts to be missed for orders under 0.5. The change ensures the order's currency is used for discount calculations, guaranteeing discounts are applied accurately.
Original PR description
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1.…
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1. Install Sales app and l10n_cl and loyalty module 2. Switch to CL Company 3. Go to Sales > Products > Discount & Loyalty 4. Create a new program and change the rule's minimum purchase to 0.00 5. Go to Sales and create a new quotation for customer Acme Corporation and add any product 6. Change the sale order line unit price to 0.4 and click on Reward 7. No discount is applied Problem: The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency. Solution: Pass the order currency when computing the discountable amount opw-5946975 Forward-Port-Of: odoo/odoo#250153