Daily updates from Odoo
Wednesday, August 20, 2025
14 changes · master
Resolved issues and error corrections
This update keeps the Belgian point of sale certification module compatible with the latest Odoo version by replacing an outdated internal component. It helps prevent errors in POS category handling after upgrading to version 19.0.
Original PR description
Starting from 19.0, odoo.osv is depreciated, so we need to use odoo.fields.Domain instead. [Runbot-230364](https://runbot.odoo.com/odoo/error/230364)
The Journal Audit report no longer crashes when its underlying Journal Report has had all lines removed. Instead of showing an error, the system safely stops processing empty report data, improving reliability for accounting users.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305 Forward-Port-Of: odoo/enterprise#91979
The Sign button is now hidden once a document has been fully signed from the chatter. This avoids confusion for users by removing an action that is no longer needed after signing is complete.
Original PR description
Before this fix, even after a user signed a document from the chatter and The document was fully signed, and the Sign button was still visible. In this PR, the button is hidden once the document is fully signed. Forward-Port-Of: odoo/enterprise#92597
The Swiss payroll wage type view no longer shows the discussion panel after messaging support was removed from the related record. This prevents users from seeing a non-working or irrelevant communication area, keeping the screen clearer and avoiding confusion.
Original PR description
After mail thread was removed from the model, the chatter is still present in the view and should be removed Forward-Port-Of: odoo/enterprise#92316
This change adjusts an internal test so it stays aligned with a recent spreadsheet component update. It helps keep automated quality checks reliable without changing the user-facing document spreadsheet experience.
This update fixes an internal accounting test so it automatically uses the correct year when checking payment references. This helps keep the test suite stable over time and avoids avoidable build failures when dates change.
Original PR description
In `test_matching_rules_with_empty_aml_move_name`, the payment `move_id.name` was hard-coded to use the year "25" in the sequence prefix (e.g. MOVE25/00004). This caused ValidationErrors when the mocked posting date in the test environment belonged to a different year, as the sequence mixin enforces alignment between the move date and sequence year. The test now derives the year suffix dynamically from the actual `move_id.date` to ensure it always matches the posting date used in the test context. This makes the test stable regardless of the current (or mocked) date, removing the need for manual adjustments when fiscal years or test setup dates change. build_error-230659 Forward-Port-Of: odoo/enterprise#92080
The Planning app now validates shift template start and end hours before creating the display name. This prevents a system error when users enter an invalid hour, replacing it with a proper validation message so the form can be corrected safely.
Original PR description
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and…
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and enter an `invalid end hour (greater than or equal to 24)` > `save`. `ValueError: hour must be in 0..23` This error occurs after [this commit](https://github.com/odoo/enterprise/commit/a0bb61f5871fe02a0a32691f33dabfb06c9d2ce2), which added the _get_name method to generate the display name without validating the data.when a user enter invalid value in the end hour while creating or editing shift template. The compute method is then triggered, which attempts to generate the display name [1] based on the formatted time. During the formatting of the end time, the hour value is invalid for the time function,and raise the error [2]. This commit ensures that if the start hour or end hour is invalid, it raises a validation error, similar to [this commit](https://github.com/odoo/enterprise/pull/67580/commits/fa566f9de1b8f75510cbc01837fb3ff4764eccdf). [1]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L54 [2]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L74-L78 sentry-6792658060 Forward-Port-Of: odoo/enterprise#91779
The Knowledge and Helpdesk Knowledge test tours were adjusted to match updated media dialog behavior from a related accessibility improvement. This helps keep automated checks reliable and reduces the risk of regressions in article editing and file block workflows.
Original PR description
This commit is linked to the [MediaDialog accessibility improvement PR] in community. [MediaDialog accessibility improvement PR]: https://github.com/odoo/odoo/pull/220737 task-3680626
The Planning app now hides the auto-plan option when a shift has no start or end date. This prevents users from triggering an error while working with unscheduled shifts created from sales orders.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383A small cleanup removes an unused internal parameter in the Belgian POS blackbox module. This reduces confusion in the code without changing how users work with the point of sale.
Original PR description
An unnecessary parameter has been added and mistakenly not removed. This commit removes it. Forward-Port-Of: odoo/enterprise#92554
Upsell orders for subscriptions now prevent changes to the commission plan when the original order has Freeze Plan enabled. This avoids misleading sales users into choosing a new plan that would not be used for the resulting commission purchase order.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307 Forward-Port-Of: odoo/enterprise#92217 Forward-Port-Of: odoo/enterprise#92157
AI prompt field selection now avoids showing unnecessary separators when inserting properties. Boolean fields also correctly treat False as a valid value, preventing misleading warnings for users.
Original PR description
Bug === The `False` value is a valid value for boolean type, and the warning should not be displayed for that type. When inserting properties in an AI prompt, the property separator should not be visible. Task-4896271 Forward-Port-Of: odoo/enterprise#92699 Forward-Port-Of: odoo/enterprise#88483
Dutch VAT payment instructions now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This ensures the payment communication shown to users matches Dutch tax reporting requirements and reduces the risk of incorrect tax payment references.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an…
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615 Forward-Port-Of: odoo/enterprise#92691 Forward-Port-Of: odoo/enterprise#92407
This fixes an internal test setup issue for Australian payroll accounting by giving the test user the access rights needed for accounting and HR records. It helps ensure automated checks run reliably without affecting day-to-day users.
Original PR description
[FIX] l10n_au_hr_payroll_account: missing groups The common test file is accessing models in account and hr modules but the user miss groups to have access to them. runbot-230965