Daily updates from Odoo
Navigate
Branch
Saturday, July 12, 2025
20 changes
18 changes
Enhancements to existing features
Expense receipt scanning now identifies more useful descriptions, such as merchant or venue names, instead of broad categories like food or parking. This makes expense records clearer for employees and reviewers, reducing manual corrections and improving reporting quality.
Original PR description
The detection of the description has been improved in the latest version of the expense OCR API. It now actually detects a description (restaurant name, fuel station name, etc) instead of predicting a category ('food', 'parking', 'gasoline', etc).
Task [link](https://www.odoo.com/odoo/project/2068/tasks/4623180)
task-4623180
Forward-Port-Of: odoo/enterprise#89898
Forward-Port-Of: odoo/enterprise#89448This update adapts enterprise spreadsheet documents and timesheet analysis reporting to work with the latest pivot table foundation. It helps keep reporting screens compatible and reliable after the underlying reporting technology changes.
Original PR description
See the community commit. https://github.com/odoo/odoo/pull/194413
Tests were updated to match the latest chart side panel behavior in Documents Spreadsheet. This helps ensure users keep their place while scrolling, switching tabs, and opening or closing sections, making chart editing feel more consistent.
Original PR description
… behavior Update test cases to reflect recent UI changes in the chart side panel: - Tabs are now sticky while scrolling - Scroll position is preserved when switching tabs - Expanded/collapsed section state is retained Task: 4752564
IoT communications now include a unique reference for each request and response. This helps ensure the system matches each device reply to the correct request when multiple actions happen at the same time, reducing the chance of incorrect callbacks.
Original PR description
We now generate a unique identifier we provide both longpolling and websocket requests and responses to ensure we don't callback for the wrong response if two requests are made simultaneously. Forward-Port-Of: odoo/enterprise#89950
Profit and loss reports that group by analytic accounts now avoid processing unnecessary empty analytic-plan rows. This reduces report loading times significantly on large accounting datasets, with benchmarked improvements of about twice as fast.
Original PR description
Description ----------- For the P&L report, a view of the `account_analytic_line` is created to mascarade as `account_move_line` for the reporting engine. The `analytic_distribution` is takens from…
Description ----------- For the P&L report, a view of the `account_analytic_line` is created to mascarade as `account_move_line` for the reporting engine. The `analytic_distribution` is takens from the plans of the analytic lines. This is done by collecting all potential plans a line can be associated with and *unnesting* them into the main table. Unnesting creates a duplicate of the row for each possible value of the analytic plans. This can quickly balloon the row count of the view, depending on how many plans are present. This also creates a duplicate row when the line isn't associated with a specific plan, adding the value `NULL` for the `analytic_distribution`. This commits filters out the `NULL` values of the array of plans before unnesting into the main table. Since on average an analytic line is associated with a few plans, this prevents the significant growth of the view, leading to more reasonable performance. Benchmark --------- On a database with ~700k AAL and ~600k AML for 2025, opening the P&L report with a grouping by analytic accounts, took: | Accounts count | Before | After | |----------------|----------|----------| | 1 | 10.3 sec | 4.76 sec | | 5 | 51 sec | 20.8 sec | | 10 | 96 sec | 41.7 sec | | 15 | 2:26 min | 1:04 min | | 20 | 3:15 min | 1:25 min | So roughly a ~2x improvement on average. Reference --------- opw-4845164 Forward-Port-Of: odoo/enterprise#89630
Resolved issues and error corrections
The Italian point of sale flow now makes sure the invoice option is selected before an order is validated, avoiding a validation error that blocked completion. A small duplicate line was also removed from the UrbanPiper POS integration cleanup.
Original PR description
## After this commit: - It ensure invoice checkbox is selected before validation, preventing the error and allowing the order to validate correctly. - Removed repeated line in `pos_urban_piper`. Runbot [link](https://runbot.odoo.com/odoo/runbot.build.error/159985) Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4916349) runbot-159985 task-4916349 Forward-Port-Of: odoo/enterprise#90018 Forward-Port-Of: odoo/enterprise#89486
Companies using separate email alias domains can now send attachments to accounting journal email aliases without triggering a multi-company error. This ensures vendor bills and other accounting documents are created and parsed correctly in the right company folder.
Original PR description
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with…
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias. The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question. steps to reproduce: 1. clean DB with documents_account installed 2. create a 2nd company "company 2" 3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com" 4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2 5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company 6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com) 7. send an email with attachment to that alias -> you will get a multi-company error After this commit ------------------ Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected. opw-4727873 opw-4655559 opw-4746321 opw-4766895 Forward-Port-Of: odoo/enterprise#89411 Forward-Port-Of: odoo/enterprise#84997
The Spanish Model 349 BOE report no longer includes correction lines for bills that were created and fully cancelled within the same reporting period. This prevents unnecessary or misleading entries in official tax report exports while preserving expected corrections for older-period bills.
Original PR description
# How to reproduce the issue On a **l10n_es** fiscal position: - Create a bill for the current period and then create a credit note for this bill. - In the tax report, under model 349, download the BOE report. Since the bill has been fully canceled within the same period, no rectification line should appear in the BOE report (correct behavior). - Create a bill from a previous period. - Create a credit note for this bill in the current period. - Download the BOE report from model 349. A rectification line appears for the previous period bill, which is expected. However, a rectification line also appears for the current period bill, which is incorrect, as the bill was canceled within the same period. This commit prevents moves from the current period from being included as rectification lines in the BOE report. opw-4895636 Forward-Port-Of: odoo/enterprise#89624 Forward-Port-Of: odoo/enterprise#89382
Barcode scanning for product packaging now correctly updates the existing receipt line instead of creating a duplicate line. This helps warehouse teams keep receipts accurate when scanning packs that represent multiple units.
Original PR description
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable…
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable "Units of Measure & Packagings" - Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional) - Inventory > Configuration > Product > Units & Pacakagings - Click on pack of 6 > Packaging Barcodes > New - Create a new one for your product - Create and confirma receipt for 6 units of your product - Go to the barcode app and scan a pack of 6 #### > A new line 1 pack of 6 was created rather than updating the already existing one. ### Cause of the issue: When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753 ### Note: This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466 ### opw-4866981 Forward-Port-Of: odoo/enterprise#89583 Forward-Port-Of: odoo/enterprise#88494
This update corrects an automated test used to verify rental product comparisons in the webshop. It helps keep quality checks reliable so future changes are less likely to be blocked or incorrectly flagged by a test issue.
Original PR description
See https://runbot.odoo.com/odoo/error/229766
This fix restores missing parts from a previous AI tools refactoring that were lost during rebasing. It helps ensure AI responses and error messages are posted correctly, reducing the risk of failed or confusing AI interactions for users.
Original PR description
The ai tools declaration and usage is refactored here: d37b87a8f270fc72f1c77c25aa11f40db19e866a However, some parts of the code were missing because of rebase errors. This commit corrects the errors.
Subscription pricing or availability rules that depend on a minimum product quantity are now only applied once that quantity is reached. This prevents customers or sales teams from seeing rules intended for larger orders too early, improving quote and checkout accuracy.
Original PR description
Rules applicable above a specific product quantity should not be considered unless the minimal quantity is reached. Forward-Port-Of: odoo/enterprise#89637
When an employee offer starts in the future, the related payslip is now created starting on that same contract date instead of the current month. This prevents payroll documents from being generated for a period where the contract is not yet active, reducing errors in salary package workflows.
Original PR description
When creating an offer with a contract date start in the future, the payslip created is still set at the current month, so the contract is outside the payslip. This is fixed by creating a payslip with date_from equal to the contract_date_start. Task: 4903936 Forward-Port-Of: odoo/enterprise#88910
The Belgian payroll double holiday pay report now uses a more accurate document name instead of referring to the 13th month. This helps payroll teams and employees identify the correct report more easily and avoids confusion between different payment types.
Original PR description
Originally, the name structure for double holiday follows "13th Month -[Legal Name] -[year]". It has been renamed to "[Payslip name]- [Legal Name] -[year]" . Forward-Port-Of: odoo/enterprise#88732
This fixes an issue where automated bank statement processing could use the wrong company context in multi-currency setups. It helps prevent incorrect currency calculations that could create unbalanced accounting entries.
Original PR description
Before this commit when the cron was triggered in a multi currency environment, the self.env.company could be a different one from the one of the statement line that would cause problem when computing the suspense amount since the currency_rate would be different. In this example: - 2 companies one in EUR, one in USD - On the USD company do a transaction - the cron is trigger with the self.env.company as the EUR one - It will do a partial reconcile with an invoice in EUR - The amount currency of the suspense will be computed by doing the balance * the currency rate. Since the company is the EUR one, the rate is not one and the open currency amount is wrongly computed - This leads to an error of unbalanced move no task id Forward-Port-Of: odoo/enterprise#89244
Appointment request notifications now include CC contacts when manual confirmation is enabled. This ensures relevant people are informed as soon as a booking request is submitted, especially for resource-based appointments where no staff member may otherwise receive a confirmation email.
Original PR description
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go…
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521 Forward-Port-Of: odoo/enterprise#88042 Forward-Port-Of: odoo/enterprise#86710
Code cleanup and technical improvements
The Belgian payroll export to SD Worx has been reorganized to align with other payroll export tools. This should make the feature easier to maintain and more consistent for future updates, with limited direct impact on day-to-day users.
Original PR description
The commit aims to refactor the Export to SD Worx module to follow other export modules in style and functionality Task: 4886460
This update removes an outdated internal query-building method and replaces it with the newer standard approach across several business apps. Users should not see functional changes, but the cleanup helps keep accounting, reporting, projects, quality, knowledge, and sales commission features easier to maintain and less prone to future issues.
Original PR description
odoo/odoo#218019
2 changes
Enhancements to existing features
Bank reconciliation now loads potential journal items much faster for company-filtered searches. This improves responsiveness for users working with very large accounting datasets, reducing a reported query from about 50 seconds to about 3 seconds in the tested case.
Original PR description
This fix aims to avoid a subquery in the main query and instead use a
IN clause to improve search performance.
On a database with over 37 million journal items, before the fix, the
query to load the 40 potentials journal items to reconcile in the bank
reconciliation widget took around 50 seconds; after the fix, it take
only 3 seconds (with only 1 company to filter).
Subquery when 'child_of' is used:
```
...
AND (
"account_move_line"."company_id" IN (
SELECT
"res_company"."id"
FROM
"res_company"
WHERE
("res_company"."parent_path" LIKE '1/%')
)
)
```
Query after the fix:
```
...
AND ("account_move_line"."company_id" IN (1))
```
opw-4896863
Forward-Port-Of: odoo/odoo#218034This update adds automated checks for key passkey journeys such as registration, login, verification, and deletion. These tests help reduce the risk that future authentication changes accidentally break passkey access for users.
Original PR description
The one big beautiful test suite written for passkeys Not tested yet: renaming passkeys, not sure if this is worth testing