Thursday, March 12, 2026
10 changes · saas-18.2
Resolved issues and error corrections
Stock transfer error messages now identify the specific package causing a consistency issue. This helps users resolve problems faster, especially in large transfers with many products or packages.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
The copy button for the two-factor authentication setup code now works again when users cannot scan the QR code. This helps users complete security setup more smoothly and removes an outdated dependency in that area.
Original PR description
__Problem__ Since odoo/odoo@e3da5f1 the onclick listener set on `copyButton` is lost because we give the HTML of the body as argument at the dialog creation. __Steps to reproduce__ 1. Go to `/my/security` 2. Click on "Enable two-factor authentication" 3. Confirm password 4. Click on "Cannot scan it?" 5. The "Copy" button doesn't work __Fix__ - Inherit from `InputConfirmationDialog` to add a listener to the button. - At the same time, remove the remaining jQuery dependency in this part of the code Forward-Port-Of: odoo/odoo#251852 Forward-Port-Of: odoo/odoo#251429
This fix ensures scrap quantities are calculated for every manufacturing scrap record, even when some records do not have a bill of materials. It prevents later records from being skipped and left with an incorrect default quantity, improving accuracy in manufacturing inventory operations.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252149
Danish Nemhandel invoice exports now include the required buyer identifier format marker. This helps ensure electronic invoices follow the OIOUBL standard and are accepted by Danish recipients and systems.
Original PR description
Nemhandel follows the OIOUBL 2.1 XML format. To specify the Buyer identifier, we use the <cac:PartyIdentification> node. But we are missing the `schemeID` attribute, which should be for DK "DK:CVR". This commit adds this attribute. opw-5232123 Forward-Port-Of: odoo/odoo#250942
This fix ensures temporary files created during PDF report generation are marked for deletion as soon as they are created. It helps prevent leftover files from accumulating on servers after reports or tests run, reducing maintenance noise without changing user-facing behavior.
Original PR description
Investigated after finding `/tmp/report.*` left over after running tests. #186547 left some temporal holes in the cleanup which are apparently sufficient to not correctly clean the files in some cases? Since `mkstemp` already creates the files, don't wait to have written stuff inside to record the file for deletion, do it immediately *then* write content to the file. An even better solution would be to use `NamedTemporaryFile(delete_on_close=False)`, however that's only available from 3.12, and it does not log deletion errors (although I'm not convinced that's useful in the first place).
Users can now reopen emoji and GIF pickers immediately after closing them by clicking elsewhere. This removes the need for an extra click and makes message composition feel smoother and more reliable.
Original PR description
**Current behavior before PR:** When the GIF or emoji picker is dismissed by clicking outside, the component state remains out of sync because `props.onClose` isn't triggered. This causes the next attempt to open the picker to fail, requiring an extra click from the user. **Desired behavior after PR is merged:** Closing the picker now correctly triggers the `props.onClose`. This ensures the component state is always reset, allowing the picker to reopen immediately on the next click. task-[5953015](https://www.odoo.com/odoo/project/1519/tasks/5953015) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Back-in-stock notification emails now show product images at an appropriate size instead of displaying them full-size. This improves email readability and gives customers a cleaner, more professional notification experience.
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 the SEPA payment wizard incorrectly displayed the number of payments being skipped. The change ensures the warning message accurately reflects that only the first installment of each bill is being paid. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
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, ensuring the test now consistently passes. This ensures the planning module functions correctly across different time zone settings.
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 previous change that disrupted the initial state of quality control tests. The change was caused by a related fix in another part of the system. This ensures that quality control tests are functioning correctly, maintaining data integrity.
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