Daily updates from Odoo
Sunday, April 19, 2026
21 changes · master
Resolved issues and error corrections
This update restores the vendor bill auto-complete feature in the Odoo Enterprise accounting module. It reverses a previous change that removed this functionality, ensuring users can quickly and easily find and select vendor bills. This improves efficiency and reduces the time spent entering purchase data.
Original PR description
This reverts commit https://github.com/odoo-dev/enterprise/commit/509ca37eef3a6dc9d148f0a11f350d41704eb02f. Community PR: https://github.com/odoo/odoo/pull/259168 task-6119762 Forward-Port-Of: odoo/enterprise#113827
This update corrects a bug where the date filter in account reports was incorrectly displaying calendar year-end dates when using custom fiscal periods. The fix ensures the report accurately reflects the user-defined fiscal year, improving reporting accuracy and consistency.
Original PR description
To reproduce, we set a fiscal year in the settings for instance(31 March). Next, we open the balance sheet and in the report settings, disable use_fiscal_periods. Then back on the report, we open the date filter and set a custom date to the fiscal year end. This would show the calendar year end. This is because when we are in a custom period, we try to infer a period from the user input. Forward-Port-Of: odoo/enterprise#114071
This update fixes a calculation error in the Luxembourg tax reports, specifically for invoices using tax grid '226'. The report was incorrectly displaying a negative value for credited amounts. The fix involves a simple formula change to ensure accurate tax reporting, aligning with recent tax updates.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/enterprise#113952
This update improves balance sheet reports for consolidated companies with multiple currencies. It adds a 'Cumulative Translation Adjustments' line to accurately reflect currency conversion differences based on account type (historical, average, or closing rates). This ensures more precise financial reporting and avoids discrepancies.
Original PR description
In reports, when consolidating two companies with different currencies, the conversion rate differs according to the type of account: * **BS accounts**: Closing rate → taken at the last day of the…
In reports, when consolidating two companies with different currencies, the conversion rate differs according to the type of account: * **BS accounts**: Closing rate → taken at the last day of the fiscal year * **P&L accounts** and **equity_unaffected**: Average rate → average over the fiscal year * **Equity**: Historical rate → taken the day of the creation of the journal item We are adding a line to the Balance Sheet, Trial Balance and General Ledger reports to correct the gap caused by the difference of rates: the **Cumulative Translation Adjustments**. This line is calculated by summing the differences of the converted balances using the right rate, and the converted balance at the closing rate of the report. By 'right rate', we mean the rate used according to the account: * historical for equity accounts * average for income_\*, expense_\* and equity_unaffected accounts We have, for equity accounts: cta_value = balance * rate_historical - balance * rate_closing for income_\*, expense_\*, equity_unaffected accounts: cta_value = balance * rate_average - balance * rate_closing The rate_closing corresponds to the rate observed the last day of the report period. task-5424428
This update enhances appointment tracking by asynchronously recording visitor activity using JavaScript. A key fix ensures visitor records are always created when an appointment is made, resolving a previous issue with sales person assignment. Additionally, tracking is now enabled by default, simplifying view configurations.
Original PR description
In the corresponding community PR, a new tracking route is introduced to record visitors and page visits asynchronously using js. In certain cases, there might be tours which need this write to occur earlier. Fixes include: appointment: tour which fails to assign the same sales person as the visitor.track record is not created. Fix: Force the creation of the visitor when an appointment is made. Task-4939052
This update fixes an issue where subscription invoices were being incorrectly set to a future date due to upsell orders. The change prevents the system from considering upsell order dates when calculating the next invoice date, ensuring accurate billing.
Original PR description
When we compute the next invoice date of a subscription, we are checking all account move lines of the invoices linked to the subscription. But if we have an upsell with a deffered date higher than the next invoice date that should be calculated, it will set a too high next invoice date. To avoid this issue, we don't take into account the invoice lines linked to upsell to compute the next invoice date Forward-Port-Of: odoo/enterprise#113170
This update fixes an issue where invoice periods were incorrectly calculated when subscriptions were set to align with their start date. The change ensures invoices accurately reflect the subscription's billing cycle, displaying the correct month and dates. This improves invoice accuracy and reduces potential billing discrepancies.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align…
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align to Period Start. 3. Create a new Subscription: * Select the configured monthly plan. * Add any subscription product. * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025). 4. Confirm the subscription. 5. Create a draft invoice. Observation: ----------------------------------- In the invoice line, you see the message: `61 days 11/01/2025 to 12/31/2025` It should be: `1 Month 11/01/2025 to 11/30/2025` Issue: ----------------------------------- https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range Solution: ----------------------------------- Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled For upsell orders, the fix is NOT applied because for upsells, `new_period_stop` is already set to the parent subscription's `next_invoice_date`, which represents the correct billing boundary. opw-5920036 Forward-Port-Of: odoo/enterprise#107407
This update resolves a technical issue preventing the correct processing of DTE XML files received via the fetchmail server. Specifically, when a purchase journal isn't configured for LATAM document usage, an error occurs, preventing proper account move calculations. This fix ensures DTE XML processing functions as intended.
Original PR description
Currently, when receiving a DTE XML fetched by the fetchmail server, if there is no purchase journal with `l10n_latam_use_documents` enabled, an empty recordset (account.journal()) is set in the default context values. This prevents the proper computation of the field and raises an error, since the `journal_id` is mandatory on account moves. Steps to reproduce: - Ensure you have no purchase journal with `l10n_latam_use_documents` enabled - Simulate the reception of a DTE XML via the fetchmail server - Observe the error: "NotNullViolation: null value in column 'journal_id'" opw-5950116 opw-6111041 Forward-Port-Of: odoo/enterprise#112168
This update resolves a stability issue in the AI composer by ensuring focus events are correctly passed to the base handler. Previously, a patch prevented this, leading to crashes when the AI composer triggered focus. This change maintains the expected behavior and prevents disruptions to the mail composer.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#114013 Forward-Port-Of: odoo/enterprise#113763
This update resolves an error that occurred when creating appointments without a designated organizer. The fix prevents a template rendering issue that arose when the system incorrectly expected a user ID, ensuring appointments can now be saved successfully.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update resolves an issue where the checkout process became unresponsive when using the Avatax module for Brazilian taxes. The previous implementation was causing unnecessary external API calls and unhandled errors, disrupting the order confirmation flow. This fix removes the problematic external tax call when not required, restoring normal checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#114109 Forward-Port-Of: odoo/enterprise#112515
This update resolves a crash that occurred when confirming rental orders with kit products using multiple pick locations. The change utilizes a safer method to handle multiple pick transfers, preventing a 'singleton error' and ensuring smooth order confirmation. This improves the reliability of rental order processing.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918
Forward-Port-Of: odoo/enterprise#114020
Forward-Port-Of: odoo/enterprise#112543This update resolves a minor issue that could occasionally cause the Gantt chart to become unresponsive during drag-and-drop operations. The fix ensures that invalid drag attempts are properly prevented, enhancing the overall stability and usability of the chart. This improves the user experience when managing project timelines.
Original PR description
This commit fixes an oversight introduced in https://github.com/odoo/enterprise/pull/106130 regarding the pill dragging safeguard. Previously, the validation check in `onWillStartDrag` correctly halted the drag initialization logic when no valid target was found, but it failed to actually cancel the drag action itself. This commit ensures the failing scenario is virtually impossible so that the fail-safe can be removed. Forward-Port-Of: odoo/enterprise#113438
This update ensures that planning times displayed in the UI and when printed match, resolving a visual inconsistency. Previously, the planning report used a 24-hour format, which has now been corrected to align with the user interface. This improves the clarity and accuracy of planning reports.
Original PR description
Steps to reproduce: - Install the Planning module - Open the Planning app - Click the Print action Issue: Planning slots display in 12-hour format in the UI but print in 24-hour format. Cause: A hard-coded time format was used when printing planning slots. Fix: Remove the explicit format and rely on the locale aware short time format. task-5462276 Forward-Port-Of: odoo/enterprise#113544 Forward-Port-Of: odoo/enterprise#103359
This update resolves an issue where negative numbers in accounting reports (like customer statements) were incorrectly formatted, splitting the minus sign and amount across lines. This ensures that all financial data is displayed accurately and consistently when printing reports, preventing confusion and improving report readability. The fix improves the presentation of financial information.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727
This update resolves an issue where dropdowns within knowledge articles weren't closing when clicking outside the embedded view. The fix adjusts the way the system detects clicks, ensuring dropdowns close as expected. This improves the user experience when working with knowledge articles and list views.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082
This update corrects a bug where customers could incorrectly edit boolean properties within shift worksheets accessed through the Odoo portal. The fix ensures these fields are read-only, preventing unintended data changes and maintaining data integrity. This resolves a visual inconsistency and improves the reliability of portal data.
Original PR description
view of shifts Currently, when a shift with a worksheet template is completed and the customer access its portal view of the shift, if a boolean property was present on the worksheet template then the portal user is able to edit that property. It is only a visual effect, the value is not updated in the db. This commit fix this issue and set the field in readonly mode. Forward-Port-Of: odoo/enterprise#113524
This update resolves an issue with the 'Current Year Retained Earnings' line on the Swiss Balance Sheet. The change adjusts the reporting date range to accurately reflect the fiscal year, ensuring financial reports align with Swiss accounting standards. This improves the reliability of financial data for Swiss clients.
Original PR description
The "Current Year Retained Earnings" (CH_299_A) line on the Swiss Balance Sheet was using the default `strict_range` date scope. This commit forces the `date_scope` to `from_fiscalyear`. task-6119493 Forward-Port-Of: odoo/enterprise#114145 Forward-Port-Of: odoo/enterprise#113920
A technical error was causing reports to fail to display correctly when a custom worksheet was included. This update adds a required 'readonly' attribute to checkbox fields in worksheets, ensuring proper rendering and preventing report errors. This improves the reliability of maintenance reports.
Original PR description
Step to reproduce - install maintenance app with demo - go to settings and enable custom worksheet - open default worksheet and add a the checkbox property field - open a maintenance request, add this worksheet in worksheet field - notice, worksheet is visible in notebook - print maintenance report Observation: - we get a traceback ``` odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the template: KeyError: 'readonly' Template: worksheet.worksheet_template_properties_display ``` Cause: - when rendering checkbox, xml props needs `readonly` key for template "worksheet_template_properties_display" but it is not provided by `format_props` of worksheet module or `_get_props_formatted` of `maintenance_worksheet` module. Fix: - we add readonly attribute (default = False) for all boolean prop opw-6079837 Forward-Port-Of: odoo/enterprise#112661
This update resolves an issue where reports were displayed with an incorrect zoom level, particularly for Swiss Locales. The changes to the report data file have corrected the layout, ensuring accurate and properly scaled reports for users in Switzerland. This improves the user experience and data accuracy.
Original PR description
The reports appear to be zoomed in. Fix the reports layout. task-6053938
This update restores the ability to assign analytic distributions directly when creating write-offs during reconciliation, a feature removed in Odoo 16.3. Previously, users had to manually reset and repost entries, which is now simplified by adding a dedicated field for analytic distribution at the write-off creation stage.
Original PR description
Since 16.3, it is no longer possible to define an analytic distribution when creating a write-off during reconciliation. Earlier, the reconciliation widget allowed assigning an analytic distribution directly to the write-off journal item. With the introduction of the reconciliation wizard in SaaS-16.3, this capability was lost, requiring users to reset the entry to draft, manually set the analytic, and repost it. This commit reintroduces this feature by adding an Analytic Distribution field to the write-off flow, allowing users to define it at creation time, restoring the previous behavior. task-4642990