Monday, September 29, 2025
10 changes · 17.0
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
Link tracking redirects now encode certain repeated dot characters that some web server setups may block as suspicious. This helps ensure tracked links continue to open reliably for users behind stricter nginx configurations.
Original PR description
Purpose ======= It has been reported that some nginx configuration detect '...' as malicious. When testing, encoding the '...' solve the issue, and so we force the encoding for the redirection URL. Task-4920533
Resolved issues and error corrections
This update fixes an automated test so it selects the correct first available option when barcode manufacturing flows are checked. It helps keep validation stable after related purchase lookup behavior changed, reducing false test failures without changing day-to-day user functionality.
Original PR description
## Versions 17.0+ ## Issue Test wants to click the first dropped down element which changes because of Purchase lookup behavior opw-5025352
Purchase order lines now find matching products regardless of letter casing, aligning their behavior with sales orders. This helps buyers see all relevant product matches when creating RFQs or purchase orders, reducing missed selections caused by case-sensitive internal references.
Original PR description
## Versions 17.0+ ## Issue Inconsistent product lookup behavior between Sales Orders and Purchase Orders. When searching for a product in a Sales Order line, all matching products are suggested,…
## Versions
17.0+
## Issue
Inconsistent product lookup behavior between Sales Orders and Purchase Orders.
When searching for a product in a Sales Order line, all matching products are suggested, regardless of letter casing.
However, in Purchase Orders, the same search behaves differently. If "Variant Grid Entry" is **unchecked**, only an exact (case-sensitive) match is returned.
## Steps to reproduce
*Ensure Sales app is installed*
- Create 2 products:
- Product 1:
- Name: TEST;
- Internal Reference: Aa1.
- Product 2:
- Name: TEST;
- Internal Reference: aA1.
- Create a SO for any customer:
- Add product by looking for "Aa1", and see both "TEST" products.
- Go to Purchase's settings:
- Uncheck "Variant Grid Entry" if checked.
- Create a RFQ for any customer:
- Add product by looking for "Aa1", and see only one "TEST" product.
## Cause
POs use `product_id` while SOs use `product_template_id`:
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/purchase/views/purchase_views.xml#L276
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/sale/views/sale_order_views.xml#L492
This means a PO calls `ProductTemplate`'s `_name_search` method while an SO calls `ProductProduct`'s `_name_search` method:
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/product/models/product_template.py#L549-L599
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/product/models/product_product.py#L543-L591
## Fix
These 2 methods are acting differently but are used in complex flows (like for Barcode app). Adding a more open domain only on Purchase's `ProductProduct` model allows to target specific spots to apply the `ilike` search.
opw-5025352The 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
The Planning app walkthrough has been adjusted so its guided steps work properly on mobile devices. This helps users complete onboarding or training flows more reliably when using Planning from a phone or tablet.
Original PR description
In this added tour steps to work in mobile. Also made changes with some steps to better accommodate mobile tour steps task-3709542 Forward-Port-Of: odoo/enterprise#65261
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650
Original PR description
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650
Fixed an issue where the project button on a sales order could show one archived project but open a blank new project form instead of the existing project. This keeps the sales order shortcut consistent and prevents users from being sent to the wrong screen.
Original PR description
Before this commit, and since commit [1], the project stat button counter on the SO form view would count archived projects. It also changed the stat button related action python method to consider…
Before this commit, and since commit [1], the project stat button counter on the SO form view would count archived projects. It also changed the stat button related action python method to consider the archived projects, but it came with a bug when the only project existing for a SO is archived. In this case, when clicking on the stat button (showing "1"), it would navigate to an empty form view to create a new project, because the action wrongly returned a `False` `res_id`. Just an oversight of the `if` condition considering archived projects correctly but not the actual line inside that condition. The chance is taken to save the `projects` in a variable to avoid such oversights later, even tho it makes the diff harder to read. Steps to reproduce: - Create a service product, set it to "Create a task" - Add a project on that product, say "Project 1" - Create a SO with that product, confirm it - You see the project stat button set to 1, clicking on it go to the project (good) - Now archive the "Project 1" project - Go back to the SO, stat button still show "1" (good) but clicking on it won't redirect to the project (bad), it will open a new form view to create a project. Note that if there is 2 projects, and one is archived, there is no issue because you don't go into that `if` condition, and the action return a list/kanban views with the correct list of projects ids (including the archived ones) There is no bug in 16, because archived products are not counted in the stat button, see commit [2]. Such a case can't happen there, as if only one project exists for a SO and its archived, the stat button won't be shown. The button visibility wasn't based on the `project_count` field but the `project_ids` field. The ORM when reading `project_ids` is ignoring the archived one (expected ORM behavior when going through relational fields without `active_test=False` forced). [1]: https://github.com/odoo/odoo/commit/eef4506f32f09dcda9990556e55131bc17855dcc [2]: https://github.com/odoo/odoo/commit/76a6a0d2ec802db2d9a7f9db61b20323d47479ce opw-4878303