Sunday, April 19, 2026
13 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 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 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 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 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
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