Tuesday, June 17, 2025
9 changes · 17.0
Resolved issues and error corrections
Romanian stock EDI exports now use the EU-required country code “EL” for Greece instead of “GR”. This helps ensure exported EDI documents are formatted correctly for partners or authorities that expect the EU VAT code.
Original PR description
Mapped the VAT code "GR" to the EU-specific code "EL" in EDI files. This ensures correct formatting of country codes for Greece in EDI exports where required. 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
Romanian stock EDI processing now skips internal warehouse transfers. This avoids unnecessary electronic document checks and prevents misleading errors for normal internal stock movements.
Original PR description
Description of the issue/feature this PR addresses: Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI…
Description of the issue/feature this PR addresses:
Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI processing for pickings that are not relevant for EDI (e.g., internal movements within the company).
Current behavior before PR:
The system does not explicitly exclude pickings of type 'internal' from EDI logic. As a result, internal transfers may trigger EDI processing even though they are not intended for such flows.
Additionally, at line 508, the existing match-case logic processes only 'outgoing' and 'incoming' types:
```
match data['picking_type_id'].code:
case 'outgoing':
partner = data['picking_type_id'].warehouse_id.partner_id if location == 'start' else data['partner_id']
case 'incoming':
partner = data['picking_type_id'].warehouse_id.partner_id if location == 'end' else data['partner_id']
case _other:
errors.append(_("Invalid picking type %(type_code)s", type_code=_other))
continue
```
Since 'internal' is not handled explicitly, it is treated as an invalid type, resulting in misleading error messages and unnecessary processing.
Desired behavior after PR is merged:
The PR introduces a condition to exclude pickings with picking_type_code = 'internal' from EDI processing. This prevents the l10n_ro_edi_stock_enable flag from being set for irrelevant pickings and avoids the generation of errors for valid internal movements.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where nested dropdown menus in CRM pivot views could appear in the wrong position after being opened more than once. Users should now see submenu options appear where expected, making navigation more reliable.
Original PR description
Exemple of steps: - Install `crm` - Open crm with pivot view - Click on '+' on a stage, exemple: "Proposition" There is a dropdown with other sub-dropdown, If we go to a sub-dropdown for the first time it is displayed correctly but the second time it is displayed with a wrong position (on the parent dropdown). The problem occurs because the `batchedUpdate` function doesn't wait for the element to be displayed before updating its position. In our case, the dropdown didn't have time to have its position adjusted because the batch was called too early. opw-4493236
The Product Expiry module now includes its missing app icon, so it appears correctly in Odoo's app listings. This small visual fix helps users identify the module more easily and keeps the app catalog presentation consistent.
Original PR description
task-4100027
This fix ensures an automated quality worksheet test has the right manufacturing permission when demo data is not installed. It prevents false test failures and helps keep manufacturing quality workflows reliable across different deployment setups.
Original PR description
The tour in `test_worksheet_quality_check` expects the "Select Work Centers" dialog to open automatically on load.
This only happens if:
- `localStorage` has no previous selection, and
- the user has `group_mrp_routings`
As seen [Here](https://github.com/odoo-dev/enterprise/blob/df3c6642cae9b40700b0b17e0335cec00ce23d3e/mrp_workorder/static/src/mrp_display/mrp_display.js#L124) in `MrpDisplay.onWillStart()`:
`if (localStorage === null && this.group_mrp_routings) {
this.toggleWorkcenterDialog(false);
}`
When running with `--without-demo=all`, the admin user does not have this group, so the dialog does not show and the test fails.
We fix this by explicitly assigning the group:
`self.env.ref("base.user_admin").groups_id += self.env.ref('mrp.group_mrp_routings')`
[runbot-161194](https://runbot.odoo.com/odoo/error/161194)Miscellaneous changes
<b>Steps to Reproduce:</b> 1. Navigate to Sales → Products → Products. 2. Click on Print Labels. 3. Select label format 2×7. 4. Add an image to the "Extra Content" field (e.g., by typing `/image`). <b>Issue:</b> - When printing labels, the image added via `extra_html` is not fully displayed. It gets cut off due to the fixed height and overflow settings on the `.o_label_extra_data` container. <b>Solution:</b> - Added responsive styling to o_label_extra_data for img so they resize pr
Original PR description
<b>Steps to Reproduce:</b>
1. Navigate to Sales → Products → Products.
2. Click on Print Labels.
3. Select label format 2×7.
4. Add an image to the "Extra Content" field (e.g., by typing `/image`).
<b>Issue:</b>
- When printing labels, the image added via `extra_html` is not fully displayed. It gets cut off due to the fixed height and overflow settings on the
`.o_label_extra_data` container.
<b>Solution:</b>
- Added responsive styling to o_label_extra_data for img so they resize properly and stay within bounds:
```css
.img {
max-height: 2.5em;
max-width: 100%;
}
```
ensures image appear without being cropped.
<b>opw-4741550</b>
Before FIX:
After FIX:
Forward-Port-Of: odoo/odoo#212903The tax breakdown is required by Argentinian law to be displayed in the bottom left corner of the invoice report. This was added in [^1] and works well for the HTML view but min-width related classes don't work well with pdf rendering, so the table stretched across the entire width of the pdf. The fix is to follow the rest of the file and use a fixed col width on the table for the pdf view. task-4779975 [^1]: https://github.com/odoo/odoo/pull/201257 Forward-Port-Of: odoo/odoo#214463
Original PR description
The tax breakdown is required by Argentinian law to be displayed in the bottom left corner of the invoice report. This was added in [^1] and works well for the HTML view but min-width related classes don't work well with pdf rendering, so the table stretched across the entire width of the pdf. The fix is to follow the rest of the file and use a fixed col width on the table for the pdf view. task-4779975 [^1]: https://github.com/odoo/odoo/pull/201257 Forward-Port-Of: odoo/odoo#214463
**Steps to reproduce:** - Install Accounting - Upload some particular PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "Arbitrary Uncaught Python Exception" Cause: When printing the original bill, we try to add a banner on the PDF. In this case, PyPDF2 fails to add a banner and raises an error from decimal library (i.e. "decimal.InvalidOperation") that is not catched. **Solution:** Bypass the addition
Original PR description
**Steps to reproduce:** - Install Accounting - Upload some particular PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "Arbitrary Uncaught Python Exception" Cause: When printing the original bill, we try to add a banner on the PDF. In this case, PyPDF2 fails to add a banner and raises an error from decimal library (i.e. "decimal.InvalidOperation") that is not catched. **Solution:** Bypass the addition of the banner in such case by handling the error. opw-4829787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214493
**Version:** 16.0 **Steps to reproduce:** - Install industry_fsm_sale - Create two tasks without linking them to a Sale Order - Go to list view and select those tasks - Click "Create Invoice" **Issue:** When the user selects tasks from the list view that are not linked to any Sale Order and tries to create an invoice, a traceback occurs. **Cause:** At least one linked Sale Order record is required when generating an invoice. If the selected tasks are not associated w
Original PR description
**Version:**
16.0
**Steps to reproduce:**
- Install industry_fsm_sale
- Create two tasks without linking them to a Sale Order
- Go to list view and select those tasks
- Click "Create Invoice"
**Issue:**
When the user selects tasks from the list view that are not linked to any Sale Order and tries to create an invoice, a traceback occurs.
**Cause:**
At least one linked Sale Order record is required when generating an invoice. If the selected tasks are not associated with any Sale Order, the process fails.
**Fix:**
This commit raise a red toast notification if none of the selected tasks are linked to a Sale Order. This helps the user understand the issue and prevent traceback..
task-4594178`
Forward-Port-Of: odoo/enterprise#83661