Tuesday, August 19, 2025
83 changes
15 changes
New functionality added to Odoo
Restaurants using Odoo's UrbanPiper integration can now offer Wolt as a delivery provider. This expands available delivery channel options and may help businesses reach more customers through Wolt.
Original PR description
Following this commit: - Integrated Wolt as delivery provider in pos_urban_piper. task-4882282 Forward-Port-Of: odoo/enterprise#88222
Enhancements to existing features
Email processing now avoids loading large unnecessary message data when handling mail records. This reduces memory pressure and lowers the risk of out-of-memory failures, especially when processing large email volumes.
Original PR description
Modifications are made around read, filtered, list comprehension. The read function usually does not prefetech fields other than stated. But in this case, since the fields are related fields from…
Modifications are made around read, filtered, list comprehension. The read function usually does not prefetech fields other than stated. But in this case, since the fields are related fields from another model, The fields of the other model are prefeteched. This includes the body which can be very big in size and cause an out of memory error. Filtered does not need other fields and keeps them unnecessarily in cache. List comprehension where it has a reference to specific field inside the model also triggers the prefetecher. Benchmark: | |Number of queries| SQL time| Python time|| |-------|----------------------------|----------------|---------------|-| |with prefetch| 82| 1.887 | 7.898| Out of memory| |Without prefetch| 120| 0.385 | 5.973| | The benchmark with the prefetch was done locally with increasing the memory limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211075 Forward-Port-Of: odoo/odoo#183893
Resolved issues and error corrections
Fixed an issue that could block visitors and portal customers from opening the online shop when product categories were shown in the sidebar. The shop now ignores hidden or empty categories during sidebar display, preventing error pages and keeping the browsing experience available.
Original PR description
## Version 18.4+ ## Steps to reproduce - On the `/shop` page, in editor mode: - Select the product display block; - Enable `Categories` display and set it to `Sidebar`; - Disable the option `Collapse…
## Version 18.4+ ## Steps to reproduce - On the `/shop` page, in editor mode: - Select the product display block; - Enable `Categories` display and set it to `Sidebar`; - Disable the option `Collapse Category Recursive`; - Open a new incognito window (or use a Portal user). - Try to access `/shop`. ## Issue When the category display is set to `Sidebar` collapse and some categories have unpublished products, the `ir.rule` introduced in commit 120a7633505891ba3e02e879f0c1a8287a690456 prevents Public and Portal users from accessing the shop. This results in a 403 or 500 error due to inaccessible child categories being used in the recursive sidebar rendering. ## Cause Commit 120a7633505891ba3e02e879f0c1a8287a690456 added a rule to hide empty categories from Public and Portal users by restricting access to categories where `has_published_products = True`. However, the sidebar template continues to loop over all `child_id`, including categories filtered out by access rules. Since Public and Portal users no longer have access to empty categories, this results in access errors during template rendering. opw-4937000
7 changes
New functionality added to Odoo
Odoo Point of Sale now supports Wolt as an additional food delivery provider through the UrbanPiper integration. This gives restaurants more delivery platform coverage and can help reach more customers from the same POS workflow.
Original PR description
Following this commit: - Integrated Wolt as delivery provider in pos_urban_piper. task-4882282 Forward-Port-Of: odoo/enterprise#88222
3 changes
Resolved issues and error corrections
This fix ensures Odoo consistently waits for file uploads to finish before users can send messages or manage attachments. It prevents confusing behavior such as attachments being deleted too quickly or messages failing when sent with the Enter key while an upload is still in progress.
Original PR description
\* = im_livechat, website_slides Not waiting for the uploading state to be resolved can lead to unexpected behavior, such as deleting the attachment immediately when clicking on the delete button rather than showing the confirm dialog. This might also prevent the composer from being sent if the attachment is still uploading. This is checked when checking the enabled state of the send button when clicking on it, but it is not checked when pressing enter directly. Some tests also checked uploading was finished but didn't target the correct attachment. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/enterprise/pull/92620
Belgian Annual Accounts exports from the General Ledger now generate an XML file instead of a fixed-format TXT file. This better matches official formatting needs and supports richer details such as account codes, debit and credit values, multilingual descriptions, and metadata for downstream processing.
Original PR description
The previous Annual Accounts export in the General Ledger generated a TXT file with a fixed column order, which did not meet the structural or formatting requirements for downstream usage. This commit replaces the TXT export with an XML export conforming to the official format, including fields such as account code, debit, credit, multilingual descriptions, and metadata. task-5005345 Forward-Port-Of: odoo/enterprise#92454 Forward-Port-Of: odoo/enterprise#92071
This fixes a loophole that allowed employees to create time off requests from a shortcut even when the time off type required an approved allocation. Requests now follow the same allocation checks everywhere, helping prevent unauthorized leave balances and keeping HR records accurate.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves. - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222050 Forward-Port-Of: odoo/odoo#208214
The website editor now waits for a clicked navigation link to finish loading before opening edit mode. This prevents the editing sidebar from appearing on the wrong page and avoids editor breakages when adding content immediately after navigating.
Original PR description
Following the [html_builder refactoring], we could start editing right after we clicked to navigate to another page, and the editor wouldn't wait for the new iframe, which isn't the expected behavior. Steps to reproduce the issue: - Open website - Click on any nav link, e.g. contact us and click edit right away => Sidebar opens before the contact us page is opened. This is not an expected behavior and also if we try to drop a snippet - the editor breaks. This commit follows the [html_builder refactoring]. Related to task-4367641 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb
Fixed an issue that could prevent users from opening filtered repair order lists from the Inventory dashboard. Repair orders are now matched against the correct scheduling date and filtered properly when multiple date categories are involved.
Original PR description
The _search_date_category method was using the incorrect field 'scheduled_date' instead of 'schedule_date', which broke the domain logic. This commit also wraps individual domain clauses in an expression.OR(...) to ensure proper filtering across multiple date categories, in line with the updated ORM search behavior (task-4150178). Caused by: https://github.com/odoo/odoo/commit/92301a5b300dec1ddfca44dc35318b83d67c56fa This fix aligns `_search_date_category` logic in repair to match what is done in mrp & stock. https://github.com/user-attachments/assets/e45791c3-feaf-4d52-9f63-6ff43fb84ca8 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222256
Fixed an issue where Attendance kiosk mode could show all check-in options for a company even when only Barcode/RFID was configured. This happened for website-linked public users without passwords, and the kiosk now avoids treating those users like trial-database users.
Original PR description
### Steps to reproduce: - Install Attendance and Website modules - Have a company 'Company A' - Create a new company 'Company B' - Set the Attendance kiosk mode to 'Barcode / RFID' for both companies…
### Steps to reproduce: - Install Attendance and Website modules - Have a company 'Company A' - Create a new company 'Company B' - Set the Attendance kiosk mode to 'Barcode / RFID' for both companies - Update all websites to be related to Company B - Go to the Kiosk mode for Company B - Notice it makes you choose between the 3 check in types while we only chose 'Barcode / RFID' ### Cause: When openning the kiosk mode it will check if the database is a trial one or if the user doesn't have a password and if so we assume that the database is a trial one. If it is a trial database we set the kiosk mode as 'settings' which shows all check in types when openning the kiosk mode. https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L101-L102 https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L185-L196 When creating a new company and set website for it we create a public user for this company and normally we don't set password for this user as no one is gonna login using it. ### Fix: We check if the user doesn't have a password and if he is not a public user. As we assume that if he is a public user he won't have a password anyways. opw-4916329 Forward-Port-Of: odoo/odoo#220355
Fixed an issue during checkout where submitting the address form could send shoppers to the wrong page if the submit button contained a link. This helps keep customers in the intended checkout flow and reduces failed or confusing purchases.
Original PR description
On checkout step /shop/address, if you have an href on the button, during the post to /shop/address/submit, you will be redirected in GET to the href value. opw-discord-internal Forward-Port-Of: odoo/odoo#220165
Razorpay payment providers can no longer be enabled and published without the required account credentials. This prevents businesses from accidentally offering a payment option that is not ready to process transactions.
Original PR description
## Version 17.0+ No OAuth in 16.0 ## Issue Razorpay can be enabled and published without being properly configured. ## Steps to reproduce - Go to `Payment Providers` and open `Razorpay`; - Set the state to `Enabled` and publish without providing any credentials. ## Fix Added constraints and revised account linking logic, similar to Stripe. Based on 1b6a7aeb245f0007675943ed7aacf5064e46fe61 suggested by ALSH. opw-4922315 Forward-Port-Of: odoo/odoo#222530 Forward-Port-Of: odoo/odoo#219943
Grouped outgoing bill payments now keep the full combined memo from each individual payment. This ensures suppliers receive the expected payment communication and avoids confusion caused by missing or altered memo details.
Original PR description
The payment memo of grouped bills should always consist of the concatenation of individual payments memos. This commit is a partial revert of the changes done in this PR https://github.com/odoo/odoo/pull/162762 The original task was intended to improve internal workflows and should not have impacted payment communications to suppliers. task-4936572 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223256 Forward-Port-Of: odoo/odoo#218787
OCR processing now correctly replaces default “Untitled Expense” names with the detected expense name, even when translations are involved. This prevents newly scanned expense documents from keeping generic names and improves test coverage to avoid regressions.
Original PR description
The combination of the following recent changes prevented the OCR from filling the name of the expense: - New expenses are named "Untitled Expense {date}" by default instead of the name of the…
The combination of the following recent changes prevented the OCR from filling the name of the expense:
- New expenses are named "Untitled Expense {date}" by default instead of the name of the attachment (see commit odoo/odoo@ca1f644).
- The OCR doesn't override the name if it's not set to the default value (see commit 5c813dc).
The first commit didn't update the default expense name that was used in the OCR code, it was still computed from the attachment name.
After the second commit, the OCR couldn't fill in the name of the expense anymore, since it was expecting the name to be the attachment name, but it was "Untitled Expense {date}" instead.
This is fixed by checking that the expense name contains "Untitled Expense" (and taking translation into consideration).
This commit also improves the tests in multiple ways:
- For the `test_auto_send_for_digitization` test, it now mimicks an upload of the document to force the creation of the expense with the default name, this should prevent this from happening again.
- It now uses an actual PDF document instead of "fake" attachments.
- Minor clean up.
task-[4684825](https://www.odoo.com/odoo/project/967/tasks/4684825)
Forward-Port-Of: odoo/enterprise#92324Employees can no longer create time off requests that require an approved allocation by using the Time Off smart button. This closes a workflow gap so absence requests follow the same eligibility rules everywhere they are created, reducing payroll and leave balance inconsistencies.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 Forward-Port-Of: odoo/enterprise#91798 Forward-Port-Of: odoo/enterprise#89975
Payments made from the customer portal for subscriptions are now properly linked to the invoice created during checkout. This ensures users can see the payment from the invoice, improving payment traceability and reducing confusion during billing follow-up.
Original PR description
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated -…
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated - Notice there is not 'Payments' smart button ### Cause: Since https://github.com/odoo/enterprise/pull/77432/commits/02f72f94b7c996fa19c6bfc70a704d27aa677245 we stopped creating the invoice before the payment and the transaction in the controller and we let _post_process do this invoice creation. So the invoice actually gets created after the payment not before and when preparing the payment values the invoice_ids will be False https://github.com/odoo/odoo/blob/6c88e6ffd2c906b72b31d3c34ad3d6da5efba204/addons/account_payment/models/payment_transaction.py#L155-L170 Then we create the invoice for the transaction and we don't propagate it to the payment. https://github.com/odoo/enterprise/blob/20fd574367757c06f30c344056e8b8d91ba8244c/sale_subscription/models/payment_transaction.py#L72-L84 ### Fix: Link the payment to the invoice after creating the invoice and link it to the transaction. opw-4867631 Forward-Port-Of: odoo/enterprise#91690
Egyptian payroll now applies the exempt amount before calculating income tax. This helps prevent employees from being charged too much tax in payroll calculations.
Original PR description
Issue: - The income tax calculation in Egyptian payroll did not properly account for the exempt amount. - This could result in over-calculating tax for employees by not applying the exemption. Fix: - Updated the 'Taxable Amount' salary rule to correctly apply the exempt amount before tax is calculated. Task-4815156 Forward-Port-Of: odoo/enterprise#86395
Enhancements to existing features
Paid invoices now reactivate eligible churned subscriptions even when payment is made manually or by bank transfer, not only through the customer portal. This helps keep subscription status aligned with customer payments while respecting the allowed automatic closing window.
Original PR description
Before: - A subscription is reopened only when a customer pays through the portal. - Manual payments do not reopen the subscription. - invoice is paid but subscription remains churned. After: - Subscriptions now reopen when invoice paid through bank transfer. - Additionally, reopening is the subscription will only reopen if the next_invoice_date is within the allowed automatic closing limit (next_invoice_date >= today - automatic closing limit). Impact: - Paid invoices now always bring the subscription back to active status task-4277444 Forward-Port-Of: odoo/enterprise#92367 Forward-Port-Of: odoo/enterprise#73136
Resolved issues and error corrections
Files added through the email wizard when sending Sign requests are now included in the outgoing email. This prevents missing documents and restores the expected sending experience for users.
Original PR description
Issue: * When users added attachments in the mail wizard (e.g., from the Sign module), the files were saved in the backend but not included in the outgoing email. Steps to Reproduce: 1. Edit a Sign template and click the Send button. 2. In the wizard, click on the Attachments button and select a file. 3. Press Send. 4. The email is sent, but the selected attachment is missing from the Sign request mail. Fix: * Adjusted the logic to correctly include attachments added through the wizard in the final email. Impact: * Users can now successfully send attachments added via the mail wizard. * Restores expected behavior and prevents missing documents in email. task-5002652
Belgian payroll exports now check required work entry codes before generating files. This prevents failed exports and gives users clear warnings so missing setup can be fixed earlier.
Original PR description
Before this commit no usererror was raised when the work entry type has no group s code defined which caused the export to fail. This commit adds a check at generation time for the work entry type to have a group s code defined task-4241431 Forward-Port-Of: odoo/enterprise#71454
Subscription payments made through the customer portal are now correctly linked to the invoice created for that subscription. This ensures users can see the payment from the invoice, improving visibility and reducing confusion during billing follow-up.
Original PR description
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated -…
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated - Notice there is not 'Payments' smart button ### Cause: Since https://github.com/odoo/enterprise/pull/77432/commits/02f72f94b7c996fa19c6bfc70a704d27aa677245 we stopped creating the invoice before the payment and the transaction in the controller and we let _post_process do this invoice creation. So the invoice actually gets created after the payment not before and when preparing the payment values the invoice_ids will be False https://github.com/odoo/odoo/blob/6c88e6ffd2c906b72b31d3c34ad3d6da5efba204/addons/account_payment/models/payment_transaction.py#L155-L170 Then we create the invoice for the transaction and we don't propagate it to the payment. https://github.com/odoo/enterprise/blob/20fd574367757c06f30c344056e8b8d91ba8244c/sale_subscription/models/payment_transaction.py#L72-L84 ### Fix: Link the payment to the invoice after creating the invoice and link it to the transaction. opw-4867631 Forward-Port-Of: odoo/enterprise#91690
Egyptian payroll now applies the exempt amount before calculating income tax. This helps prevent employees from being charged too much tax and improves payroll accuracy.
Original PR description
Issue: - The income tax calculation in Egyptian payroll did not properly account for the exempt amount. - This could result in over-calculating tax for employees by not applying the exemption. Fix: - Updated the 'Taxable Amount' salary rule to correctly apply the exempt amount before tax is calculated. Task-4815156 Forward-Port-Of: odoo/enterprise#86395
This fixes an error that could block reconciliation when a vendor bill with multiple installments was paid through separate batch payments. The system now ignores installments that were already reconciled, allowing later payments to be matched normally.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: *…
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: * Vendor: [any] * Payment terms: [the created payment term] * Amount: 1000 - Confirm the bill - Pay the first installment from the bill (i.e. 200) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -200 - Reconcile the statement with the batch payment - From the bill, pay the second installment (i.e. 800) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -800 - Reconcile the statement with the batch payment **Issue:** The following UserError is raised: "You are trying to reconcile some entries that are already reconciled." **Cause:** When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used. However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled. It should not be reused when reconciling the second batch payment. **Solution:** Exclude reconciled payment term lines when reconciling a batch payment. opw-4830185 Forward-Port-Of: odoo/enterprise#91367
This fix restores the review summary information shown in portal rating areas, so customers and visitors can see rating feedback as expected. It also updates related portal and website modules plus tests to prevent the issue from returning.
Original PR description
*: portal_rating, rating, test_mail_full task-4853416
Inter-company customer invoices now correctly display lot and serial numbers for delivered products. This helps businesses keep accurate traceability records when selling between companies in the same Odoo environment.
Original PR description
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2 (`partner_id`) - Validate the delivery (using SN001) - Create and confirm the invoice associated to the SO. - Print the delivery #### > The lots and serial numbers are not displayed but they would be for any other customer type. ### Cause of the issue: Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location. opw-4962700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr