Friday, March 7, 2025
11 changes · 17.0
Resolved issues and error corrections
The DIN 5008 report layout footer now uses a more readable font size when printed. This makes company details and footer text clearer while keeping the footer compact on business documents.
Original PR description
**Issue:** - When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.  **Solution:** - After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.company_details` class, but this is no longer sufficient due to the presence of `<p>` tags in the footer. To resolve this - - remove the general font-size directive - add a new one in li - add a limited line-height to the `<p>` tag to reduce the vertical size of the footer, given we are boosting the font size.  opw-4506533
This fixes an internal mismatch where analytic plan database fields were not marked as indexed even though an index was created. As a result, Odoo will no longer produce misleading log messages about expected analytic plan indexes during module updates.
Original PR description
Description of the issue/feature this PR addresses: Spurious log entries Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes…
Description of the issue/feature this PR addresses: Spurious log entries
Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes created by [_sync_plan_column](https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L281) as unexpected
Desired behavior after PR is merged: No log entry for expected index
Steps to reproduce:
- create a new analytic plan, ie 'Test plan'
- go to technical/database structure/fields, search for the custom field created on model account.analytic.line, named `x_plan{the id of the plan you created in step 1}_id`
- observe the field is not marked as indexed, even though the code creates an index
- update the analytic module, observe there will be an entry of the form `Keep unexpected index account_analytic_line__x_plan{the id of the plan you created in step 1}_id_index on table account_analytic_line`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSales users can now apply custom filters that find sales orders linked to tasks in a specific project without encountering an invalid filter error. This makes it easier to locate relevant orders based on related project work and avoids disruption when using advanced search filters.
Original PR description
Before this commit, when the user creates a custom filter in SO model to select the SO in which there is at least one task linked to a specific project, he got an error saying the domain is invalid.…
Before this commit, when the user creates a custom filter in SO model to select the SO in which there is at least one task linked to a specific project, he got an error saying the domain is invalid. This commit fixes the issue by improving the search method implementing for the `task_ids` field to make sure the search view supports a query contained inside `value` parameter. Steps to reproduce the issue: ---------------------------- 0. Install `sale_timesheet` module with demo data 1. Go to Sales app 2. Creates a custom filter and select `Tasks associated to this sale > Project` as left part, `=` as operator (second field in the custom filter) and `After sales-service` as project (right part, last field in the custom filter). 3. Apply the custom filter Expected behavior: ----------------- The custom filter should be applied without any issue. Current behavior: ---------------- The user has an error saying the domain is invalid when he tries to save/apply his custom filter.
The sales down payment wizard no longer shows an unused tax setting when it is opened before the down payment product exists. This prevents users from seeing and configuring a field that no longer affects the invoice process.
Original PR description
When creating a down payment from a SO, the first time the wizard is opened, the down payment product does not exists yet. This trigger the display of the `deposit_taxes_id` field to define a tax for the display product. But this tax has no use anymore since https://github.com/odoo/odoo/commit/a11f402d6b949fdef8a86b532642287609ea74bc. This commit removes `deposit_taxes_id` from the view (leaving it in the wizard model because of stable policy).
Installing the Danish audit trail module now automatically enables the audit trail option as intended. This helps Danish accounting setups meet audit requirements without requiring users to manually activate the setting after installation.
Original PR description
When installing l10n_dk_audit_trail module, the audit trail option wasn't checked by default task-4575368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates an internal automated test for creating partner records so it works after a related enterprise change. It helps keep nightly quality checks reliable and reduces false test failures for the Base module.
Original PR description
This https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0 caused the `test_create_res_partner` test to fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing a combo product into a regular goods product now removes its combo setup, so the point of sale no longer shows an unnecessary selection popup. This prevents cashier confusion and keeps product behavior aligned with its current type.
Original PR description
Currently if you change the type of a combo product to something else, the combo_ids are still saved and in the pos it will use them and open a selection popup. Steps to reproduce: ------------------- * Go in the products * Select Burger Combo * Change the type to "Goods" and save * Open restaurant * Select burger combo > Observation: Selection popup for combo ids appears. Why the fix: ------------ When changing the type of product we remove the combo_ids from the product form. Without combo_ids no popup appears. opw-4513392
The SHIF report wizard now skips payslips that have no SHIF or NHIF amount, preventing empty zero-value entries from appearing in the report. This keeps Kenyan payroll reports cleaner and avoids users adding irrelevant lines manually.
Original PR description
Problem ---------- - Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0. Objective ---------- - check if the SHIF/NHIF amount == 0 before add it in report entries. - Don't allow the user to add a line. Solution ---------- - add a condition on the SHIF/NHIF amount to add the payslip task-4463586
A typo in a currency label or reference was corrected in the Swiss payroll ELM transmission area. This helps ensure payroll contract information is displayed accurately and avoids confusion for users handling Swiss payroll data.
This fixes the sign used for AHV administration fees in Swiss payroll ELM transmissions. It helps ensure payroll figures are reported with the correct positive or negative value, reducing the risk of inaccurate submissions.
Fixed an issue in POS Restaurant where updating an order after removing all food items could trigger an error. This helps staff continue managing table orders and internal notes without interruptions.
Original PR description
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for the **Restaurant** shop. - Select a table, add the food (e.g., "Cheese Burger") and place the order. - Add an `Internal Note` to the ordered food item. - Remove the food item and click the `Order` button (it shows '-1 Food'). - Observe the error. **Error:** `KeyError: 'qty'` The issue occurs because when all food items are removed, `note_history` does not contain the `qty` key and it attempts to access `qty` from `note` at [1]. This commit resolves the issue by adding an additional check to ensure that 'qty' is in `note` before accessing the `qty` key. [1] - https://github.com/odoo/enterprise/blob/f1615134029860d32b95ade09738549a7bb1632d/pos_preparation_display/models/pos_order.py#L79-L80 Sentry - 6303446407