Thursday, March 5, 2026
17 changes · saas-19.1
New functionality added to Odoo
This update introduces the ability to integrate with popular food delivery platforms like GrabFood and GoFood directly within the point-of-sale system. This allows restaurants to seamlessly manage orders from these platforms, streamlining their operations and improving customer service.
Original PR description
Introduction: This commit integrate with multiple platform order platform in SEA. This commit also implement a skeleton code base for future adding additional platform order provider. As of now, we included GoFood and GrabFood to begin with. Features list: - Skeleton code for platform order - GrabFood integration - GoFood integration task-4215826 task-3726824 Forward-Port-Of: odoo/enterprise#94390
Enhancements to existing features
This update speeds up testing for the Stock Barcode module by moving company creation steps to a setup class. This significantly reduces test execution time, particularly when running tests for related modules like Sale Timesheet. The change addresses a performance bottleneck identified during testing.
Original PR description
TestBarcodeClientAction [setup is quite slow](https://runbot229.odoo.com/runbot/static/build/102958171-master/tests/profile/profile_2.html#localProfilePath=1), especially because it creates a company. In addition in all classes extending this one, we spend at least 6 minutes on this line. (when testing sale_timesheet -> !stock_barcode_mrp_subcontracting) This commit proposes to move at least the company creation in a setupclass. It would be great to move all the setup in the setupclass but the tests are failling when doing so and could be achieved by a member of the stock_barcode owner team. Tests based on this setup should be a few minutes faster with this change. Forward-Port-Of: odoo/enterprise#109509
Resolved issues and error corrections
This update fixes an issue in the batch transfer report where product lines were scattered, making it difficult for operators to quickly locate items. The report now sorts move lines by product, grouping similar products together for faster and more accurate picking. This reduces operator time and minimizes the risk of missed items.
Original PR description
Issue Before This Commit: ======================= In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document…
This update addresses changes required by the new format for Spanish tax reports (l10n_es_reports). Specifically, a new field for petrol has been added, and the arrangement of certain Casillas has been adjusted to align with the updated reporting requirements. This ensures compliance with Spanish tax regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#109260
This update enhances the poll experience by displaying the poll's end datetime when you hover over the 'Remaining Time' text. This allows users to set reminders and proactively manage participation, ensuring timely responses and maximizing poll engagement.
Original PR description
This commit adds showing of datetime when the poll will end when mouse-hovering on the Remaining time text of the poll. This is useful to put a reminder for later just before the poll ends, let's say to see if involvement is fine or we need to push pressure for people to vote. <img width="555" height="255" alt="Screenshot 2026-03-04 at 12 55 44" src="https://github.com/user-attachments/assets/19ef91a1-ea52-475a-86e1-acc16e18fe98" />
Issue Before This Commit: ======================= In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`. Steps to Reproduce: ======================= - Install the `stock_picking_batch` module. - Create `multiple deliveries` with several `common products`. - Add these deliveries to a batch transfer and print the batch transfer report. - Observe that product lines are ordered by location and then by picking. Cause of the issue: ======================= The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document. After This Commit: ======================= In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable. TaskID-5379367 Forward-Port-Of: odoo/odoo#241809
This update resolves an issue where commission reports were incorrectly calculating amounts due to JavaScript's handling of large integer IDs. By ensuring the full ID is always used, the system now accurately reflects commission amounts, preventing data conflicts and ensuring correct reporting across different currencies.
Original PR description
In commission report, we need unique ids for achievements and commissions. We avoid using row_number because it becomes really slow when the amount of records increases. That's why we need reliable unique ids, build from the account move line/sale order line/sale order log, user_id, commission rules. As it represents a lot of information stored inside a unique integer, bigint are necessary. It works great in python because int() can be used to handle bigint but JavaScript is not great with that. It will cast the value sent by the ORM silently and as a result, when the ORM is called back by the JS framework, it will pass a truncated id that either conflict with another record or may not exists (ids are generated using recipe). This commit ensure that the full id is always accessible and is used to browse records when the framework js contact methods. task-5973128
This update corrects a bug related to invoice date calculations for users in Saudi Arabia. Previously, invoices created around midnight in SA time could be incorrectly dated in the future, leading to rejection by ZATCA. This fix ensures invoices are always dated correctly relative to Saudi Arabia's time zone.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250999 Forward-Port-Of: odoo/odoo#246311
This update fixes an issue where POS discounts weren't being applied correctly when orders were modified. By updating the global discount automatically, the system now ensures accurate discount calculations across all POS transactions, improving the customer experience and reducing potential errors.
Original PR description
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 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#241605
This update fixes an issue where POS discounts weren't being applied correctly when orders were changed. The update now ensures discounts are consistently applied across the entire order, improving the accuracy of POS transactions. This resolves a previous bug related to refunding discounts.
Original PR description
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479
This update optimizes the HTML editor's performance by reducing unnecessary layout recalculations. Specifically, the code now prioritizes reading layout information before making changes to the DOM, leading to a smoother and faster editing experience. Additionally, updates to the editor's hints and power buttons are now delayed to prevent excessive UI updates.
Original PR description
Description of the issue this PR addresses: I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations.…
Description of the issue this PR addresses: I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations. This PR reorders the logic so geometry is read first and DOM mutations are applied afterwards, reducing the number of forced reflows and significantly improving performance. II. Debounce `updateHints` and `updatePowerButtons` to avoid excessive UI updates on frequent selection changes. Introduce `debounceHints` and `debouncePowerButtons` editor config options so debouncing can be disabled in tests for deterministic behavior. III. Introduce READ helper for withSequence to explicitly order resource handlers so DOM reads run before DOM mutations. Before: <img width="1705" height="399" alt="image" src="https://github.com/user-attachments/assets/2fca797a-0311-4c4a-9063-2051934baa7c" /> After: <img width="1490" height="343" alt="image" src="https://github.com/user-attachments/assets/0f295969-b962-4190-a7f9-fe5366d7fafd" /> task-5499625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249785 Forward-Port-Of: odoo/odoo#244478
This update corrects a discrepancy in the Romanian tax reports, ensuring they accurately reflect the latest VAT rate changes (19% to 21% and 5%/9% to 11%). The fix includes adding missing taxes and setting unused taxes to inactive status to maintain report accuracy and avoid potential user disruption.
Original PR description
Romanian VAT has increased from 19% to 21% and from 5%/9% to 11%, some taxes were added previously to the module but they were not reflected in the tax report, also other taxes were missing in order for the report to replicate the current up to date version issued by the romanian government. Forward-Port-Of: odoo/odoo#251978 Forward-Port-Of: odoo/odoo#241529
This update corrects a recent issue in the l10n_ch_hr_payroll module by reintroducing the calculation of contractual annual wages. This ensures accurate payroll processing for employees in Switzerland, aligning with current tax regulations and improving financial reporting. The change impacts employee compensation calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#109264 Forward-Port-Of: odoo/enterprise#109228
This update optimizes the ZATCA journal onboarding process by reducing memory usage. Previously, a lengthy check looped through all journal entries, causing errors with large volumes of data. Now, the check directly targets relevant documents, significantly improving performance and stability.
Original PR description
Behavior before: Sanity check looped over all account moves of the journal, filtering in Python for ZATCA documents. This caused memory errors when the journal had hundreds of thousands of moves. Behavior after: The check now searches directly on l10n_sa.edi.document with a domain that filters only relevant moves with state 'to_send', reducing memory usage and avoiding Python-level loops. Root cause: Loading all moves and their One2many edi_document_ids in memory for filtering caused excessive memory usage and MemoryError on large journals. OPW-5972073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251732
This update fixes an issue where SMS reminders weren't being sent for calendar events synced with Google or Microsoft. The change ensures that Odoo correctly handles SMS notifications for these events, aligning with the intended behavior of delegating email reminders to Google. This improves the reliability of reminders for all synced calendars.
Original PR description
SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google. Reproduction steps: * Create a calendar event in Odoo with an SMS…
SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google. Reproduction steps: * Create a calendar event in Odoo with an SMS reminder. * Sync the calendar with Google. * Wait for the reminder to trigger. * Observe that no SMS is sent by Odoo. Cause: The event reminder scheduled action groups events by alarm type and calls `_get_events_by_alarm_to_notify`. For Google-synced events, `_get_notify_alert_extra_conditions` blindly excludes any event with a `google_id`, assuming Google will manage all reminders. This exclusion is incorrect for non-email alarms (e.g. SMS), which must still be handled by Odoo. Fix: The alarm type is propagated through the context so Google-specific exclusions only apply to email reminders. This restores SMS notifications while preserving the existing behavior for emails. A context key is used for stability; a proper method argument will be introduced in master. opw-5172958 Forward-Port-Of: odoo/odoo#251742 Forward-Port-Of: odoo/odoo#241026
This update fixes an issue where the system incorrectly treated re-deliveries as returns, resulting in only one shipping label being generated. Now, when returning multiple packages, the system accurately recognizes and processes all incoming shipments as returns, ensuring proper label generation and delivery tracking.
Original PR description
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery -…
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery - Multiple packages - Validate transfer - Return - Validate IN - Return again - Add the UPS under the "additional info" tab - Ensure still multiple packages - Validate OUT Cause ----- When preparing the shipping data, we go through https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121 which leads us to do https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155 so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`. https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58 From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns. ----- Ticket: opw-5866100 Forward-Port-Of: odoo/odoo#250724 Forward-Port-Of: odoo/odoo#246946
This update fixes an error in how the cost of goods sold (COGS) is calculated for kits. Previously, the COGS was incorrectly double-counted due to a calculation issue. This change ensures accurate COGS reporting for kits, preventing overstatement of costs.
Original PR description
Bug introduced by: 341928ca477843d92bf7a084f738cf9dcfd3593a Steps to reproduce: - Create a storable product “C1” - Cost: $1 - Create a storable product “P1” - Type: Kit - Category: AVCO - BoM: -…
Bug introduced by: 341928ca477843d92bf7a084f738cf9dcfd3593a
Steps to reproduce:
- Create a storable product “C1”
- Cost: $1
- Create a storable product “P1”
- Type: Kit
- Category: AVCO
- BoM:
- Component: C1 (qty: 20)
- Create a sale order for 1 unit of P1
- Confirm the SO
- Validate the delivery
- Create and post the invoice
- Check the journal items
Problem:
The total COGS posted is $400 instead of $200.
When posting the invoice, `_get_cogs_value` is triggered. It retrieves the price unit of each component based on the stock move quantity of the sale order:
https://github.com/odoo/odoo/blob/963bdc5d8a7cc7d3235a52ac2a2282d95a0da400/addons/sale_mrp/models/account_move.py#L39
However, since commit: https://github.com/odoo/odoo/commit/341928ca477843d92bf7a084f738cf9dcfd3593a#diff-bb93bc1c1d7fd07978c5081adc6dc21dc3eb4c37b5e8f44342fe34b61ee060b5R44
, `_get_price_unit` returns the total cost of the component required to produce one kit (i.e., 20 units * $1 = $20).
Later, `_get_cogs_value` multiplies this value again by the component quantity defined in the BoM (20), resulting in a double multiplication: (20 units * $1) * 20 = $400
opw-5946749
Forward-Port-Of: odoo/odoo#251509A recent update caused a disruption in SEPA direct debit payments, preventing users from completing transactions. This fix addresses a missing data element within the payment provider configuration, resolving the error and restoring functionality. The change was introduced following another update and is now corrected.
Original PR description
Issue: --- The SEPA direct debit is broken. Steps to reproduce: --- 1- Enable SEPA direct debit in payment providers. 2- Add something to cart and try paying using SEPA direct debit. You get the error: `payment.provider object has no attribute company.` Cause: --- This is introduced after #250326. opw-5993720 Forward-Port-Of: odoo/enterprise#109672