Monday, September 29, 2025
124 changes
6 changes
Enhancements to existing features
The tax search view now includes the tax amount field, so users can find taxes by entering their configured percentage or fixed amount in the search bar. This makes tax setup easier to navigate and reduces time spent locating the right tax records.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
Resolved issues and error corrections
This fix prevents email signature formatting, such as resized images, from being damaged when messages are prepared for Outlook compatibility. Users should see more consistent email appearance between chatter messages and the full email composer.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
8 changes
Enhancements to existing features
Tax records can now be found by entering their configured percentage or fixed amount in the search bar. This makes it faster for accounting users to locate the right tax setup without browsing through tax lists manually.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
1 change
Resolved issues and error corrections
Helpdesk team settings now only show internal users when assigning team members for tag-based ticket dispatching. This prevents portal users from being selected by mistake, keeping automatic ticket assignment limited to the right staff.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188**
4 changes
Enhancements to existing features
The tax search screen now includes the configured tax amount in search results. This makes it easier for users to quickly find taxes by their percentage rate or fixed amount directly from the search bar.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
2 changes
Enhancements to existing features
The tax search now includes the configured tax amount, so users can quickly find taxes by entering a percentage or fixed amount in the search bar. This makes tax setup and review faster, especially for companies with many tax records.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
4 changes
Enhancements to existing features
This update restructures how product stock valuation fields are calculated so custom modules can adapt the behavior more easily. It mainly benefits implementations that need tailored inventory accounting logic without changing core code.
Original PR description
FWP of https://github.com/odoo/odoo/pull/160201 cc @pfertyk @svs-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The AI field picker now prevents users from selecting the same field more than once and clearly marks fields that are already selected. Long field paths also wrap correctly, making them easier to remove and reducing user frustration when configuring AI prompts.
Original PR description
before this commit: When you press Enter in the field picker, it will always pick the same field again, even if it is not visible. After this commit: A field can only be selected once, and it stays visible in the list. Added a visual check to show that the field is already selected. Forward-Port-Of: odoo/enterprise#93890
Importing certain electronic invoice files could fail when a quantity field was set to zero. This fix prevents that error so affected UBL/CII invoices can be imported more reliably in Accounting.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
Payment terminal messages printed at the bottom of POS receipts now use the correct text size. This makes receipt details easier for customers and staff to read while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
This fixes an issue where reinstalling the Danish Nemhandel module could leave it broken. Businesses using Danish electronic invoicing can reinstall or recover the module without disrupting its setup.
Original PR description
**Description of the issue/feature this PR addresses:** Reinstalling the module breaks it. 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#228747
Resolved issues and error corrections
The bank reconciliation widget now avoids repeating the same date on every transaction line when several entries share a date. This makes the list easier to scan and reduces visual clutter while still showing the date at the start of each date group or statement.
Original PR description
When you have several transactions on the same date, it's not really necessary to repeat the date on each line. It bloats the widget. We will now only show it if it's the first transaction at that date or if it's the first of a statement. task-4749339
Greek VAT numbers that start with the common 'EL' prefix are now treated as Greek VAT numbers during validation. This ensures customer country information is filled correctly in exports such as DATEV accounting files, reducing manual corrections and reporting errors.
Original PR description
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer…
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer from Greece with VAT number EL033910442 2. Create an invoice for that customer 3. Navigate to Accounting > Reporting > General Ledger 4. Download Datev Data through the gear icon 5. Open EXTF_Customer_accounts.csv 6. Notice that EL was not recognised as the country code **Root Cause** The VAT validation logic `simple_vat_check` first tries to find a country-specific check function `check_vat_EL`, but such a function does not exist. For Greece, the correct function is `check_vat_GR` (since the ISO country code is `GR`). When `EL` is passed directly, no check function is found, validation fails, and the VAT country is left empty. **Fix** Normalize the VAT prefix before validation by mapping EL → GR, ensuring Greek VAT numbers prefixed with EL are validated with the existing check_vat_GR logic. Opw-4982164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225422
This fixes an issue where email signature formatting could be damaged when messages were prepared for Outlook, especially for resized images. Users should see more consistent email appearance between the chatter composer and full email composer.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
This fix prevents UBL invoice imports from failing when an imported file contains a zero value for the base quantity. Businesses can now import affected customer invoices without interruption, improving reliability for electronic invoicing workflows.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
This fix prevents the website preview from briefly showing old page styling when a page reloads after theme changes. Business users get a smoother editing experience with less visual flicker when updating layouts or background colors.
Original PR description
In this [commit], fallback iframe was added to avoid flickering between iframe reloads. But the flicker still happens if we change page's style, since we do not apply the new styles to the fallback iframe. To reproduce the issue: - Open Website and start editing - Move to the 'Theme' tab - Change page layout to 'Boxed' - Set background color to a non-transparent color, e.g. red - Save, and do any action to reload the iframe, e.g. go to /contactus => The iframe flickers from the previous color to red, which shouldn't be the case. Task-4985472 [commit]: https://github.com/odoo/odoo/commit/7b19831e1c624b483008feb526ba773ec8b23009 Forward-Port-Of: odoo/odoo#221391
Payment terminal messages printed at the bottom of POS receipts now use the correct font size. This makes important payment information easier to read on printed receipts while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
A test for financial reports now targets the exact report being checked instead of potentially switching to a related variant. This improves confidence in report validation without changing day-to-day product behavior.
Original PR description
the test test_custom_engines_related_groupby needs a slight improvement to target the report it is called with, rather than possible variants of the report. This can be achieved using the key 'no_report_reroute'.
Resolved issues and error corrections
This fix swaps the placement of the “exempt” and “exempt imports” fields in the Mexican DIOT report so each value appears in the legally expected column. The amounts were already calculated correctly, but the corrected layout helps avoid confusion and reporting mistakes.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228882 Forward-Port-Of: odoo/odoo#228303
Dark mode display issues were corrected in Point of Sale and appointment screens. Icons and text now use colors that remain readable across light and dark themes, making the interface easier to use for staff.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078 Forward-Port-Of: odoo/enterprise#93993
The Mexican DIOT report export now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion when businesses submit or review the downloaded TXT file, while the underlying calculated amounts remain unchanged.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
The update aligns enterprise localization tests with a recent change that adds delivery party information to UBL electronic documents. This helps ensure electronic invoice and related document checks remain reliable for affected localizations, especially Peru.
Original PR description
The community commit introduced the `<cac:DeliveryParty>` element under `<cac:Delivery>` in UBL XML. This enterprise commit improves test coverage for the element and updates existing UBL tests that were failing due to the additional tag. ---- Community PR: odoo/odoo#223756 task-5022404
Resolved issues and error corrections
The update ensures DATEV main account settings are applied only to companies based in Germany, preventing incorrect accounting behavior for companies in other countries. It also improves how debit and credit lines are gathered, making the process more efficient for larger accounting entries.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`.
The CRM Periodic Digest tip now shows the correct number of free credits for targeted lead generation. This avoids misleading users by stating 20 credits instead of the incorrect 200 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252
The partner ledger now keeps partner names and expand arrows properly aligned on phones and tablets. This makes the report easier to read and use on smaller screens without changing its functionality.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889