Daily updates from Odoo
Friday, October 31, 2025
16 changes · 18.0
Enhancements to existing features
The Pakistan payroll localization has been updated with the latest 2026 income tax bracket values. This helps businesses calculate employee payroll taxes in line with the new requirements.
Original PR description
Tax brackets for pakistan localization has been updated to include the new values for 2026.
Resolved issues and error corrections
The update prevents company chart setup from failing when newly introduced Indian tax records are not yet present for an existing company. This helps businesses continue using or configuring Indian localization without unexpected errors after stable legal tax updates.
Original PR description
If new taxes are introduced in stable (for legal reasons), and for Indian localisation we create new fiscals position for branch In such that case the new taxes will be not updated for the current company in such that case it will be lead to traceback with External ID not found for taxes. In this commit we add a new context `raise_if_not_found_ref`, through which if the tax doesn't exists the error is not raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Portal users clicking "Browse Articles" from a Helpdesk help page are now taken directly to the linked Knowledge article instead of an empty knowledge home page. This fixes a navigation issue and helps customers find the intended self-service content faster.
Original PR description
To reproduce: ============= 1. Create a Helpdesk Team linked to a Knowledge Article 2. Access the Help page on website as a portal user 3. Click on "Browse Articles" button -> redirected to empty knowledge home portal view Problem: ======== before this commit, redirection was made through the method `redirect_to_article` which will later call `_redirect_to_portal_view` that doesn't use the `article` parameter anymore as there is a patch on the front side to handle the redirection to the articale through the router, but as the calls are server-side, the patch is not applied and the redirection fails. Solution: ========= instead of calling `redirect_to_article`, directly redirect to the article's `website_url`. opw-5114885
Fixes an issue where updating multiple combo products in an unsaved sales order could cause their related items to appear under the wrong combo. This keeps sales order lines clear and accurate while users adjust quantities before saving.
Original PR description
Steps to Reproduce: - Create a Sale Order containing two combo products placed consecutively. - Change the quantity of the first combo → corresponding combo items update correctly. - Without saving,…
Steps to Reproduce: - Create a Sale Order containing two combo products placed consecutively. - Change the quantity of the first combo → corresponding combo items update correctly. - Without saving, change the quantity of the second combo. - Observe that the combo items now appear misplaced — items from the second combo are inserted before those of the first combo. Issue: - The order of combo items becomes incorrect when multiple combo products are updated consecutively in the same unsaved Sale Order. Cause: - During `onchange`, the `self.order_line` recordset reflects the *in-memory order of applied commands* rather than the database `sequence` field because they are not saved in the DB during the edition. - Each `onchange` rebuilds `order_line` using concatenated command lists (`delete + create + update`), So when multiple combos are modified without save, newly created combo items are appended according to command evaluation order — not by logical grouping. - This causes combo items to shift relative to their parent combo lines. Solution: - Restrict the recomputation of order lines to non-combo lines by filtering out combo item lines during the rebuild. As combo items will always be in their desired sequence. - This ensures that combo items always stay under their respective parent combos and their sequence is preserved, regardless of the order in which combos are updated. opw-5148770 Affected Version:18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes Stripe payments in Point of Sale so tips added after payment are handled correctly. Payments are now properly captured and adjusted, preventing failed or blocked future tipping for restaurant and POS customers.
Original PR description
Since [^1], tip after payment has been broken for stripe as `_update_payment_line_for_tip` is no longer called anywhere. This means that all payments were put in as uncaptured and no future tipping would work. This PR fixes it by using the "new" send_payment_adjust method like ayden to guarantee the payments are properly handled. Note that this is solved by wrapping `capturePayment` into a new method `capturePaymentStripe` to keep the stable policy. A followup PR will move the data back to `capturePayment` in master with the new parameters. opw-5121568 [^1]: 9c37f42ef4e23372f5e2bdbb956b625b3a47d8e1
Fixes an error that occurred when users tried to split more than one Manufacturing Order at the same time. This helps manufacturing teams complete bulk actions from the order list without hitting a system traceback.
Original PR description
Steps to reproduce: - Create two Manufacturing Orders - From the list, select them and click on cog -> Split Issue: A traceback appears, as we try to insert `res.users` records in the database rather than their id. Since #154607, the wizard's `counter` has its default set to 2. However, when opening the wizard with multiple MOs at once, even if the `counter` isn't displayed, the details will be computed for each MO. This didn't cause issue in previous versions as we always went through a `web_save` that sent their ID, but now its possible to have this whole process server-side at the creation of the wizard, exposing the error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where purchase order tax totals could fail when multiple currencies were involved. The calculation now uses the currency from the current purchase order, preventing errors and helping users view accurate tax totals reliably.
Original PR description
On the tax computation, when trying to compute the total tax, customer was having an error " Expected singleton: res.currency(1, 69) " As Odoo is trying to get the currency of all the records instead of the one in the current order opw-5177551
Customers will now receive email notifications when Gelato sends an order status update. This fixes a communication gap so buyers are kept informed about progress on their orders.
Original PR description
Fix not sending the email to customer, when order status update was received from Gelato. opw-4962878
The self-ordering menu mode has been fixed so customers can browse the menu as intended. This helps restaurants avoid confusion or interruptions when customers use mobile self-ordering without placing an immediate order.
Original PR description
Menu mode was broken in self ordering. This commit fix it.
The Journal Report now keeps its Global Tax Summary in sync when users change the rounding unit. This prevents mismatched figures between the main report and tax summary, improving confidence in financial report presentation.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#94660
Portal users can no longer change the customer field on project tasks, preventing them from accidentally removing the customer and being unable to restore it. The fix also avoids an access error when portal users create new tasks with a default customer.
Original PR description
Since the user can only set himself as customer for task in the portal view, we removed this option in order to avoid issues on the customer side. E.A. setting the customer to False, then save, and being unable to put back the original customer. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200366
New field service tasks created from the portal now automatically use the current user as the customer when no customer is provided. This prevents task creation issues caused by a missing required customer and makes the process more reliable across related field service workflows.
Original PR description
When creating a new FSM task in the portal view, the current user will now be set as default user instead of False. The fix is done to be more generic. The customer field is mandatory on fsm tasks, but there is no restriction on it in the backend side. So we might encounter a similar issue again. With assigning a default user for fsm tasks at the creation, we ensure that the field is always set. Forward-Port-Of: odoo/enterprise#80770
Company logo fetching for partner autocomplete now uses the updated logo.dev service through Odoo's IAP service instead of loading logos directly in the browser. Logos are no longer shown during search selection and are fetched only during enrichment, making the process more centralized and reliable.
Original PR description
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231397
Subscription invoices now keep recurring delivery charges at their full fixed amount when billing periods are prorated. This prevents customers from being undercharged for shipping when subscriptions are aligned to calendar billing.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a subscription with delivery product. 2. Select align to calendar in the recurring plan 2. Add shipping method by assigning a delivery product with recurring_invoice. 3. Create an invoice with prorated Issue: - Delivery products are considered service-type products and their price was prorated in invoice. Cause: - The proration logic treated delivery lines like normal recurring service products, instead of keeping their fixed charge. Solution: - Exclude delivery products from proration by setting their period ratio to 1. Co-authored-by: Darshan Patel dvpa@odoo.com Co-authored-by: Federico Braidi brfe@odoo.com task-4662188
Turkish withholding e-invoices sent through Nilvera now include the VAT percentage in the tax details. This ensures the VAT amount is displayed correctly on the generated PDF, reducing confusion for customers and accounting teams.
Original PR description
Before this commit: For withholding invoices, the VAT percentage was not included inside the <cac:TaxTotals> node, due to this, the VAT amount was not displayed in the PDF in Nilvera. After this commit: The VAT amount is shown correctly in the <cbc:Percent> node inside the <cac:TaxTotals> node and percent amount appears correctly in the PDF. task-5225600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
The media dialog no longer offers Dailymotion or Youku embed options where they can create broken video content due to platform changes. Users will see a more accurate list of supported video platforms, reducing the chance of adding videos that do not work properly on websites.
Original PR description
Specification: Improve `VideoSelector` Component. After this PR: - Dailymotion has deprecated its legacy embed endpoint starting September 23, 2024. Removed support for embedding Dailymotion videos in the media dialog. - Embedding Youku videos via iframe has become unreliable and no longer functions properly in the media dialog. Removed support for Youku embeds to prevent broken video content. - The supported platforms string now correctly lists YouTube, Vimeo, and Dailymotion, Instagram as supported platforms. task-4855038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214296