Daily updates from Odoo
Sunday, April 19, 2026
28 changes · master
New functionality added to Odoo
This update separates stock management logic into a dedicated module, offering enterprise users greater control over whether they use point of sale with stock operations. The changes also adjust other modules to avoid unnecessary dependencies on the stock module, streamlining the system and improving performance. This enhances the overall POS experience for our business customers.
Original PR description
Similarly to `point_of_sale` and `pos_stock`; This commit moves the complex stock logic to its own module, to give enterprise users the flexibility of using point of sale with or without stock operations. This commit also adapts modules that might need `pos_stock_enterprise.` While some other modules don't need the stock module, so their xpaths and methods were modified to prevent depending on `pos_stock` (or `pos_stock_enterprise`) when its not needed. Task: 5418116
This update introduces a live map feature for planning managers, allowing them to see the real-time locations of technicians during interventions. The system uses automatic tracking with refresh capabilities for accurate location updates, enhancing operational visibility and efficiency.
Original PR description
# [IMP] planning: compute for user_ids in planning slot mock This commit adds the compute method on the user_ids field in planning slot. # [IMP] planning_field_service: introduce semi-live map In…
# [IMP] planning: compute for user_ids in planning slot mock This commit adds the compute method on the user_ids field in planning slot. # [IMP] planning_field_service: introduce semi-live map In this commit, we implement a semi real-time system for tracking technicians. In the new "Live Map" menu, planning managers will be able to view the live locations of their technicians having an intervention scheduled at the moment. The system is semi-live: geolocation is updated in the background while the user is active on the page, allowing managers to view their latest locations. However, the map does not update automatically, managers have to refresh the page or reopen the view to fetch and display the latest coordinates. A tracking watch starts automatically when a user signs in or completes an intervention, provided that the geolocation feature is enabled in the settings and that they have authorized location tracking on their device. Importantly, the watch is only triggered if the person performing the action is one of the users assigned to the slot. This behavior is also applied to the geolocation logged in the chatter. For security purposes, the watch is automatically stopped either by refreshing the page, closing it, or one hour after the last intervention assigned to the user. Finally, a cron is executed every day to erase all geolocations that are dated more than one day ago. On the map, the planning manager also has the opportunity to hover the users' markers. The popup displays the latest tracked location of the technician. # [ADD] planning_field_service_hr_attendance: enhance live map integration This new bridge supplements the live map by adding conditions to start and stop tracking of technicians. In other words, it improves the coverage of the real-time geolocation tracking natively available in `planning_field_service`. Namely: - Start watching position on check-in - Stop watching position on check-out - Automatic check-out also removes tracked position - Tracking automatically resumes when opening the database, if the user is checked-in and previously had a watch running The last point is particularly important, so to resume the watch if the technician closed its device during the intervention. task-5259200
Enhancements to existing features
Financial reports now include a default way to compare results by ledger on Balance Sheet and Profit and Loss reports. The option appears only when it is useful, and users can open the group setup directly from the report filter for easier discovery and management.
Original PR description
1/ Upon installing the accounting app, create a default horizontal group by ledgers, available on the Balance Sheet and P&L, the generic ones and all those from installed localizations. 2/ Make this horizontal group visible in the filter only when it is functionnaly relevant, i.e. when at least one explicit ledger exists. 3/ Make the horizontal group tag clickable, leading to the form view of the horizontal group. task-6101452
This update consolidates partner identifiers across all Odoo localizations into a single, standardized JSON field. This simplifies data management, improves validation accuracy, and reduces redundancy, leading to a more efficient and reliable system for managing business partner information. This is a key step towards a larger refactor of identifier management.
Original PR description
First part. task-5013950
This update simplifies the creation of Spanish tax reports (303 and 347) by automatically displaying key information. Specifically, the 'exonerated from 390' field is now visible on the print BOE wizard for relevant periods, and a new grouping is added for audit operations in report 347, streamlining the reporting process.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#114142 Forward-Port-Of: odoo/enterprise#108057
This update adjusts how public holidays are calculated on termination payslips. It now considers whether an employee worked less than a month or at least one month before their departure, impacting holiday pay eligibility. This ensures accurate payroll processing for employees leaving the company, aligning with Belgian regulations.
Original PR description
When an employee is leaving the company, if there are public holidays - in the 14 days following the end of contract, if the employee worked less than a month in the company - in the 30 days following the end of contract, if the employee worked at least one month in the company except if the employee found a new job before. In practice we don't pay them by default except if the employee explicitly ask for it. Task: 6007823
This update simplifies the Balance Sheet report to clearly separate Earnings and Equity, enhancing financial reporting clarity. The changes improve the presentation of key account pairs used for earnings allocation, particularly in the standard and US versions of the report. This provides a more straightforward view of financial performance.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852 Forward-Port-Of: odoo/enterprise#114060 Forward-Port-Of: odoo/enterprise#112499
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