Thursday, March 5, 2026
34 changes · saas-19.1
Resolved issues and error corrections
A test was failing due to a time zone discrepancy in the planning module. The fix corrects a calculation that incorrectly shifted dates based on the server's time zone setting, ensuring consistent test results. This prevents disruptions to the planning functionality.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e
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…
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 filtering by 'Analytic Distribution' in Journal Entries and Purchase Orders was returning incorrect results. The fix ensures that 'is set' and 'is not set' filters work as expected, accurately displaying records with and without an analytic distribution. This improves data accuracy and reporting.
Original PR description
**Problem:** When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results. When the filter is 'set' it returns all…
**Problem:** When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results. When the filter is 'set' it returns all records (even the ones without an analytic distribution) and when the filter is 'not set' it returns no records (even the ones without an analytic distribution). **Steps to reproduce:** 1) Go to Accounting > Journal Entries. 2) Apply a filter for Invoice lines > Distribution Analytic Account. 3) Select "is set" or "is not set". 4) Check records. Issue is also reproduceable on Purchase Orders. **Cause:** The `_search_analytic_distribution` method did not correctly handle the case when the value is [False], so it results in an invalid Query. **Solution:** - We need to handle the case when we have False in the value on it's own. opw-5478688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251816 Forward-Port-Of: odoo/odoo#247777
A test failure related to invoice data formatting was resolved. The fix ensures the correct invoice data is used in a key export process, preventing potential errors and ensuring consistent invoice generation for Turkish VAT invoices. This improves the reliability of the e-invoice export functionality.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task Forward-Port-Of: odoo/odoo#251885 Forward-Port-Of: odoo/odoo#232105
This update resolves a problem preventing the correct generation of CSV reports for Peru-specific accounting. The fix addresses an incompatibility with a recent Python update, ensuring reports are now created without errors. The change also streamlines the CSV configuration process for improved efficiency.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109437
Forward-Port-Of: odoo/enterprise#109081This update expands the color field options within the Odoo Gantt editor to include all integer fields from the underlying model. Previously, only fields directly visible in the view could be selected. This change improves the editor's flexibility and allows for more comprehensive visualization of task data.
Original PR description
Before this commit, only fields already present in the view were selectable for the color field in the gantt editor. After this commit, all int fields of the model are available task-5981029 Forward-Port-Of: odoo/enterprise#109189
This update fixes an issue where VIES validation errors caused errors in the system. The team has broadened the exception handling to catch all `zeep` errors, preventing tracebacks and ensuring accurate VAT number checks. This resolves a previous problem impacting OCR invoice updates.
Original PR description
Catch all `zeep` exceptions instead of only `zeep.Fault`. On 14th of February 2026, the VIES service wasn't working properly, they were returning invalid XML in their response. This caused the `check_vies` call to raise a `zeep.XMLSyntaxError` which wasn't caught, causing a traceback every time VIES was used to validate a VAT number. opw-5938723 (OCR couldn't be refreshed on an invoice because it tried to create a partner from its VAT number and it couldn't be checked with VIES). Forward-Port-Of: odoo/odoo#250123 Forward-Port-Of: odoo/odoo#249853
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 ensures the Odoo command-line interface consistently uses the correct data directory, regardless of user configuration. While the preferred method is using the odoorc configuration file, this change enforces the use of the data directory for the odoo-bin module, providing a more reliable setup.
Original PR description
The prefered way is to use the odoorc config file, but some plateforms let their users configure their config file, but --data-dir should be enforced by the plateform. Forward-Port-Of: odoo/odoo#251937
This update fixes an issue where large company logos on customer documents were overlapping with important address information. By adding a maximum width constraint to the small company logo, the document layout is now cleaner and more professional, ensuring key customer details are always visible. This improves the overall presentation of customer documents.
Original PR description
**Description of the issue/feature this PR addresses:** Similar issue described in: https://github.com/odoo/odoo/pull/249432 Since there is no `max-width` defined for `o_company_logo_small`, if a user uploads a large logo, the customer address overlaps with the company details. This can be tested by previewing the document with a large logo. <img width="684" height="449" alt="image" src="https://github.com/user-attachments/assets/aa2ac10b-cb0f-448a-ade3-6e7bb8b1fcff" /> **Current behavior before PR:** <img width="681" height="383" alt="image" src="https://github.com/user-attachments/assets/cf7d5740-db51-43e3-b8f6-70325e9e28c0" /> **Desired behavior after PR is merged:** <img width="505" height="307" alt="image" src="https://github.com/user-attachments/assets/b175a06a-cde0-4808-a1fb-276fd96272c3" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @ForgeFlow Forward-Port-Of: odoo/odoo#251976
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 fixes a technical issue within the mass mailing module that prevented certain elements from being correctly displayed. The change ensures that a key method is interpreted correctly, improving the overall reliability and accuracy of the mass mailing process. This ensures consistent and accurate email campaigns.
Original PR description
Description of the issue/feature this PR addresses: This PR makes sure `isSelectionInEditable` is correctly checked in `EmptyNotEditableElementsPlugin`. `isSelectionInEditable` is a shared method previous code interpreted it as property. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251744
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 fixes an issue where duplicate Dimona activities were being created in the payroll system, particularly when updating employee versions. The change ensures that Dimona activities are only created once, streamlining payroll processing and preventing potential data inconsistencies. This improves the reliability of the Belgian payroll calculations.
Original PR description
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on…
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually `_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. [tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380) Forward-Port-Of: odoo/enterprise#109304 Forward-Port-Of: odoo/enterprise#96423
This update resolves a problem where Odoo couldn't send email templates without a linked record. A recent change in the Odoo codebase caused this to fail. This fix ensures email templates can now be sent correctly, regardless of whether a record is associated with them.
Original PR description
Add explicit support for sending an email template with no actual record, i.e., calling `template.send_mail(False)`. This used to work but now fails since https://github.com/odoo/odoo/pull/227477. task-6000637
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
A technical issue causing the Activity Logs report to appear incorrectly in the Sign Template list view has been resolved. The fix corrects a misconfiguration in the report's model, ensuring it now displays within the Sign Request view and prevents errors.
Original PR description
Version: - saas-18.2 Issue: - The "Activity Logs" report was showing in the Sign Template list view. When clicking it, a traceback occurred because the report tried to read a `sign.request` record from a `sign.template` context. Cause: - The report model was set to `sign.request`, but the`binding_model_id` was set to `model_sign_template`. - This mismatch caused the report to appear in the wrong place. Solution: - Updated the `binding_model_id` to `model_sign_request` so the report now appears in the Sign Request view, which matches the report model and prevents the error. task-5984137 Forward-Port-Of: odoo/enterprise#109171
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 issue where the system was incorrectly returning multiple bank records when a company contact had the same account number on multiple child contacts. This ensured accurate bank information is displayed and used within the Odoo system, preventing potential data inconsistencies.
Original PR description
The function `_find_or_create_bank_account` is expected to return one or no record at all. In the case of child contacts, it is possible that the same account number was set on multiple records, leading the function to return multiple banks. Forward-Port-Of: odoo/odoo#251733
A bug was causing the task list to display duplicate 'New' and 'Create New' buttons, leading to confusion and potential duplicate task creations. This fix removes the duplicate buttons by preventing the ProjectTaskTemplateDropdown component from rendering in dialog contexts. This ensures a cleaner and more intuitive task creation experience.
Original PR description
Steps to Reproduce --- 1. Enable Task Dependencies in Project settings 2. Create project with no task templates 3. Open task form -> Blocked By tab -> Add a line 4. Observe duplicate "New" and "Create New" buttons Issue --- - The task list view displays both “New” and “Create New” buttons, resulting in duplicated creation actions. Current Behaviour --- - Two different creation buttons are displayed simultaneously Expected Behaviour --- - Only a single “New” button should be displayed Root cause --- - ControlPanel refactoring removed props.showButtons without adding !env.inDialog check to task views. Fix --- - Add !env.inDialog check , this prevents the ProjectTaskTemplateDropdown component from rendering in dialog contexts, eliminating the duplicate button issue. Related - https://github.com/odoo/odoo/pull/220325 task - 5403917