Friday, November 28, 2025
12 changes · saas-18.2
Resolved issues and error corrections
This update resolves an error that occurred when users tried to view time off information for contracts without a defined working schedule. The fix prevents the system from attempting to access incorrect data, ensuring a smoother user experience. This improves stability and usability of the Gantt view.
Original PR description
Currently, an error occurs when a contract has no working schedule set and the user tries to open the Time Off overview in the Gantt view. **Steps to Reproduce:** 1. Install `hr_holidays_contract_gantt` with demo data. 2. Open the **Marc Demo** employee and remove the **Working Schedule** from the contract. 3. Navigate to: Time off > Overview **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error. **Fix:** This commit skips the computation when the contract does not have a working schedule set. [1] - https://github.com/odoo/enterprise/blob/e60429fce3875a282172cd81d18322d472d7fee4/hr_holidays_contract_gantt/models/hr_leave.py#L52 sentry-7017326141 Forward-Port-Of: odoo/enterprise#99262
This update resolves an issue where invoices weren't created for alternative sale orders generated from upsells. The fix ensures the 'next invoice date' is correctly copied from the original upsell order, preventing a date calculation error that previously blocked invoice creation. Now, invoices are generated successfully for these orders, ensuring accurate payment and billing.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99831 Forward-Port-Of: odoo/enterprise#98983
This update fixes a visual issue where the comparison price wasn't showing on subscription product pages. The fix involves updating how the pricing information is displayed dynamically on the website, ensuring customers see the correct recurring price alongside the subscription plan. This improves the user experience and accuracy of pricing information.
Original PR description
Steps to reproduce: 1. Install website_sale_subscription 2. Enable Comparison Price from the settings 3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price…
Steps to reproduce: 1. Install website_sale_subscription 2. Enable Comparison Price from the settings 3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price 4. Go to product page via smart button Issue: - The comparison price is not visible beside the recurring plan. Cause: - The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing. Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values. Solution: - In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>` before: <img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" /> After: <img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" /> opw-5248297 Forward-Port-Of: odoo/enterprise#100140
This update resolves an issue where the DIOT tax report export failed when journal entries lacked a linked partner. The fix ensures the report generation process continues smoothly by explicitly handling entries without partners, preventing errors and improving data accuracy for Mexican tax reporting. This ensures reliable reporting for all journal entries.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#100671 Forward-Port-Of: odoo/enterprise#96529
This update resolves a visual issue in the check printing process for US layouts. Previously, the payment date would overlap with the table below when a specific setting was disabled. The fix ensures the date is correctly positioned, preventing this overlap and improving the appearance of generated checks.
Original PR description
In the Accounting app, users can print checks created to pay Vendor Bills. When using any of the US Checks Layout (from `l10n_us_check_printing`), the payment date would overlap the table beneath it…
In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.
<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />
This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.
https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34
By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.
### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
- Set any Vendor
- Set any Bill Date
- Add any Product (with a positive price, the total price of the bill must be positive)
- Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.
This fix moves the date right above the table.
<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />
opw-5165112
Forward-Port-Of: odoo/enterprise#100487This update resolves a bug where a call remained visible in the Odoo softphone after it was disconnected. The fix ensures that calls are immediately removed from the softphone interface when they are no longer linked, improving the user experience and data accuracy.
Original PR description
A call that was unlinked previously remained visible in the VOIP softphone. This fix ensures that the call is correctly removed from the softphone view as soon as it is unlinked. Task-5262162 Forward-Port-Of: odoo/enterprise#100138 Forward-Port-Of: odoo/enterprise#100036
This update enhances the reliability of payment processing by automatically retrying failed requests (specifically 5xx errors) when the payment server is temporarily unavailable. This ensures that tills remain operational and prevents payment processing interruptions, improving the overall user experience. The changes simplify the code and improve error handling for the l10n_de_pos_cert module.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693 Forward-Port-Of: odoo/enterprise#93694
This update fixes an issue where scanning a lot multiple times during a barcode picking process would incorrectly create a backorder. The fix ensures that quantity updates are applied correctly to the relevant lines, preventing the unnecessary creation of a backorder when scanning the same lot multiple times. This improves the accuracy of inventory management.
Original PR description
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm -…
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm - open the picking in barcode - scan the stock location - scan the lot - scan the lot another time - validate **Current behavior:** a backorder is created **Expected behavior:** No back order should be created **Cause of the issue:** After scanning the lot for the first time we have the following situation: two lines : - one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1 - one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1 both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2 All of this is correct. when scanning the lot for the second time: _findLine iterates through the lines to select the right line to use. _findLine calls _lineIsNotComplete on the first line to check if it's complete (this first line is complete). https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684 But _lineIsNotComplete will actually do the check on the parent line (which is not complete), so the return value will be true. https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338 As a consequence, the quantity will be added in the first line and we will have a qty_done of 2 in the first line and a qty_done of 0 in the second line. Which will lead to the creation of a back order opw Forward-Port-Of: odoo/enterprise#99774
A bug was causing the Original Bills report to generate an empty PDF within Odoo Studio. This was due to the complex process of creating the report, involving multiple streams. To resolve this, the Studio interface has been updated to simply blacklist this specific report, ensuring consistent functionality.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to Invoices - Open studio - Click on "Reports" - Select the "Original Bills" report => The report is empty Cause of the issue ================== The Original Bills is a very specific report. Multiple streams are created and then combined to make the final PDF See: odoo/odoo#85150 Solution ======== Since studio cannot handle this usecase, we blacklist this report opw-5108198 Forward-Port-Of: odoo/enterprise#100769 Forward-Port-Of: odoo/enterprise#100729
This update corrects a reporting issue where employee leave days were incorrectly included in planned hours calculations. The fix ensures that leave and holidays are properly excluded from the Timesheets > Planning Analysis report, providing more accurate project time tracking. This improves reporting reliability and data accuracy.
Original PR description
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects. **Steps to Reproduce** 1. Create a planning slot for an employee spanning a full month 2. Add employee time-off (resource.calendar.leaves) during that period 4. Navigate to Timesheets > Timesheets / Planning Analysis report 5. Filter by the employee and date range 6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project **Root Cause** The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy. **Solution** Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates. opw-5027070 Forward-Port-Of: odoo/enterprise#100516 Forward-Port-Of: odoo/enterprise#97657
A test case in the Odoo Enterprise accounting module was failing due to differences in payment state handling between the community and enterprise versions. This change moved the test case to the enterprise environment to ensure it accurately reflects the expected behavior, resolving the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453 Forward-Port-Of: odoo/enterprise#100834
This update resolves a bug that caused the system to crash when users attempted to validate signatures on employee contracts. The issue stemmed from a missing field in the HR employee model after the 'Sign, Employee Contracts, and Documents' app was uninstalled. The fix adds a graceful bypass to handle the missing field, ensuring smooth contract signing functionality.
Original PR description
The system will crash with an error when the user tries to validate the signature.
**Steps to produce:**
- Install `Sign, Employee Contracts, and Documents` apps with demo data.
- Go to Apps and uninstall the `hr_contract_sign`module.
- Send any employee a sign request for a document.
- When the employee tries to validate and send the document, the error appears.
**Error:**
`KeyError: 'sign_request_ids'
ValueError: Invalid field hr.employee.sign_request_ids in condition ('sign_request_ids', 'in', [1])`
**Cause:**
- When `sign` route is called, then we try to search field `sign_request_ids` in `hr_employee`. but we can see the field `sign_request_ids` is defined in `hr_contract_sign` module.
- And user removed the `hr_contract_sign` module, so the field no longer exists. in the hr_employee model.
**Solution:**
- Added a graceful bypass when `sign_request_ids` is missing,
**sentry-6819182542**
Forward-Port-Of: odoo/enterprise#95449