Daily updates from Odoo
Thursday, March 5, 2026
45 changes · saas-19.1
New functionality added to Odoo
This update incorporates the Central Bank of Uzbekistan as a source for real-time currency rates. This change ensures Odoo Enterprise complies with local regulations and provides more accurate currency conversions for transactions involving Uzbekistan.
Original PR description
## Description of the issue/feature this PR addresses: This PR adds the Central Bank of Uzbekistan as a provider for currency update task-id - 5917344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#108059
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 expands the 'Unpaid' filter in the vendor bill section to now display draft bills alongside posted bills. This allows users to see all outstanding bills, regardless of their payment status, improving visibility and streamlining payment management. A technical update ensures journal entries are correctly filtered, maintaining data accuracy.
Original PR description
In this commit: - Updated the `Unpaid` filter to show draft bills in addition to posted bills. The filter now includes all non-cancelled bills with payment status `Not Paid` or `Partially Paid`. - Backported the logic from 18.0 to ensure journal entries are filtered out by checking that type is not equal to `journal_entry`. task-5900283 Forward-Port-Of: odoo/odoo#251208 Forward-Port-Of: odoo/odoo#247179
This update enables cashiers to record multiple payments for a single order in Point of Sale. Previously, users were limited to one cash payment line, causing issues when multiple people paid at different times. This change improves the user experience and accurately reflects payments made in a group setting.
Original PR description
Before this commit: ============ - The user is not able to process multiple cash payment lines. An error pop-up appears saying `There is already a cash payment line.` After this commit: ============ - The user can process multiple cash payment lines. Use Case: ----------- - If a group of people goes to a restaurant and one person leaves earlier, he decides to pay $10 at the cashier and leave. When the others pay later, the cashier will see that $10 has already been paid and can add another cash payment line for the remaining amount. Task-5969853 Forward-Port-Of: odoo/odoo#250639
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
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 adjusts the Romanian tax reporting (l10n_ro_saft) to align with recent changes in the core Enterprise version (CE). The update removes outdated tax codes and adds new ones, ensuring accurate reporting for Romanian businesses. This ensures compliance with current tax regulations.
Original PR description
Some taxes were no longer needed in CE, so they needed to be removed task-5411745 Forward-Port-Of: odoo/enterprise#109507 Forward-Port-Of: odoo/enterprise#106127
This update adjusts the salary scale parameters used in the Odoo Enterprise’s Belgian payroll module (l10n_be_hr_payroll). Specifically, the base salary figures for the first year of employment and overall salary scale values have been updated to reflect the latest regulations as of January 1st, 2026. This ensures accurate payroll calculations for Belgian employees.
Original PR description
. Update cp200_salary_scale_first_year values for 01/01/2026 . Update cp200_salary_scale values for 01/01/2026 task-5485636 Forward-Port-Of: odoo/enterprise#107473
This update enhances the point-of-sale (POS) system by allowing for easier customization of the ticket screen. The changes enable developers to add specific styling classes to the ticket screen, providing greater flexibility for tailoring the user interface. This improves the system's adaptability to different business needs and branding requirements.
Original PR description
See odoo/enterprise#94390 Forward-Port-Of: odoo/odoo#226447
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" />
This update refines the payroll schedule wizard for Belgian companies, restricting its use to only employees within Belgium. It removes a redundant field and improves the user interface with added spacing, resulting in a cleaner and more intuitive experience for HR staff managing Belgian employee schedules.
Original PR description
- Show the “Working Schedule Change” wizard only for employees belonging to Belgian companies. - Remove the “Post Change Contract Creation” field from the working schedule change wizard. - Add extra right padding to the warning alert in the time-off section for improved UI spacing. task-5367812 Forward-Port-Of: odoo/enterprise#101013
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
A minor bug causing test failures in the stock module has been resolved. The fix ensures the database is fully updated before deleting zero inventory quantities, preventing unpredictable test results. This improves the reliability of our stock management testing.
Original PR description
In Signal app, the test `test_set_inventory_quant_to_zero` was failing randomly when asserting that the quant no longer exists after calling `_unlink_zero_quants()`. All required conditions for deletion were met: - inventory_quantity == 0 - user_id is False - quantity == 0 - reserved_quantity == 0 The method `_unlink_zero_quants()` performs a raw SQL query to select zero quants. Since raw SQL does not trigger an automatic ORM flush, the quant state could be out-of-sync with the database at the time of the query, making the deletion non-deterministic. Add an explicit `flush_all()` before calling `_unlink_zero_quants()` in the test to ensure the database reflects the latest ORM state and avoid random failures. Runbot-241210 Forward-Port-Of: odoo/odoo#252006
A previous bug prevented users from correctly updating both the last month and last day of their fiscal year when managing multiple companies. This update corrects the underlying code to ensure constraints are checked after all changes have been applied, resolving the validation error and allowing for accurate fiscal year settings.
Original PR description
Having a parent company and a chid company selected, and changing both the last day and the last month of the fiscal year as the same time raises a ValidationError. This is because in this case, in the write we successively modify each changed delegated fields from root company to the branches. Then, when checking the constrains we loop through all delegated fields and check if the value of the branches are the same as the root company. This check triggers the error as all values are not set yet. By using a write on branches for all changed delegated fields instead of a simple assignation, the constrains check occurs once all the value have been updated. Steps: - Have a root company and a branch - Select both in company selector - Go to Accounting configuration - Change fiscalyear last month AND ast day at the same time - Save -> ValidationError in `_check_root_delegated_fields` opw-5431145 Forward-Port-Of: odoo/odoo#251941 Forward-Port-Of: odoo/odoo#241413
This update resolves a technical error that prevented users from correctly ordering stock when using the replenishment multiple feature. The fix corrects a calculation error within the stock management system, ensuring accurate order quantities are generated for replenishment rules. This improves the reliability of stock ordering processes.
Original PR description
Backport of: https://github.com/odoo/odoo/commit/fe806166968d55a70f5bf335dcb3633e18d8ecc7 Steps to reproduce: - Create a storable product “P1”: - UoM: Unit and Pack of 6 - Purchase tab: add any vendor - Go to Replenishment and create a new rule: - Product: P1 - Min: 10 - Max: 100 - Replenishment Multiple: Pack of 6 - Select the line and click “Replenish” → “Order to Max” Issue: A traceback is raised: “TypeError: unsupported operand types in: uom.uom(2,) - 4.0” In `_get_qty_to_order`, we compute the quantity to order and then adjust it according to the replenishment multiple, but we try to Subtract the rounded remainder from the uom (which is a recordset) instead of the quantity (which is a float). opw-5947919 Forward-Port-Of: odoo/odoo#251338 Forward-Port-Of: odoo/odoo#250608
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#251509This update resolves a technical issue preventing the holiday tour from functioning correctly within the calendar view. The fix ensures the tour consistently displays and operates as intended, improving the user experience. This change was identified and addressed through automated testing.
Original PR description
This fix adjusts the tour in `test_hours_time_off_request_calendar_view` as it was failing in some cases. runbot error 237682 Forward-Port-Of: odoo/odoo#249458 Forward-Port-Of: odoo/odoo#249267
This update fixes an issue where payslips weren't generating correct work entries for employees with no recorded working hours. The change ensures that all employees, including those with flexible work arrangements, receive accurate payslips. This improves payroll accuracy and reporting.
Original PR description
**Version:** - 19.0 **Steps to reproduce:** - Create an employee. - Leave the Working Hours field empty. - Set the contract dates and a wage. - Create a payslip using the smart button. **Issue:** - Worked day lines are empty for flexible employees when the payslip is created from the smart button. **Cause:** - Flexible employees were being skipped because their working hours were empty, which results in work entries not being generated. **Solution:** - Updated the condition to also generate work entries for flexible employees. Task-5431870 Forward-Port-Of: odoo/enterprise#103101
A 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
This update corrects a visual issue where the 'invalid locators' alert was appearing incorrectly within a form due to an outdated website view. The fix ensures the alert is displayed correctly after the 'Be aware' alert, resolving a potential user experience problem. This change improves the clarity and usability of the application.
Original PR description
The XPath `//div[hasclass('alert-info')]` used to insert the invalid locators warning matches multiple elements since the website module has another `alert-info` div inside the visibility field:…
The XPath `//div[hasclass('alert-info')]` used to insert the invalid locators warning matches multiple elements since the website module has another `alert-info` div inside the visibility field: https://github.com/odoo/odoo/blob/31c199f3d19b8f9c54d582b6a5c4684e1ed38d0a/addons/website/views/website_pages_views.xml#L221
<img width="1065" height="633" alt="image" src="https://github.com/user-attachments/assets/dab8955c-d01b-4682-871a-b7499ed99297" />
<img width="1427" height="986" alt="image" src="https://github.com/user-attachments/assets/a05efb5d-254b-4e3a-ad14-530ae6718be6" />
On databases created before the invalid locators feature was added, the website inherited view has a lower ID than the web one, so it is applied first. This causes the XPath to match the wrong element and places the warning in the middle of the form fields instead of after the "Be aware" alert. This is not reproducible on runbot since fresh databases always have the correct ID ordering.
<img width="2291" height="956" alt="image" src="https://github.com/user-attachments/assets/fc7eee11-c66e-4d84-b827-f2ed61c76a97" />
We now target the correct alert div that is a direct child of the sheet element. Hence, the inheriting order no longer affect the location of the warning.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251631This update resolves a rare issue in the Gantt view that could cause it to crash when users interact with search filters. The fix prevents a race condition that occurred when a search dropdown closed while a pill was being hovered, ensuring smoother operation and preventing unexpected errors.
Original PR description
This commit fixes a traceback in the Gantt view caused by a race condition during search operations. If a user clicks a search dropdown item located directly above a task pill, and that search filters out the underlying pill, a `pointerenter` event can fire on the pill just as the dropdown closes. Because the search amy already be applied, the renderer could lose track of the pill, causing the handler to crash when trying to access it. This commit adds a safety check to the event handler to exit early if the hovered pill is no longer found in the renderer. Forward-Port-Of: odoo/enterprise#109545