Daily updates from Odoo
Thursday, March 5, 2026
264 changes
35 changes
New functionality added to Odoo
This update introduces the ability to integrate with popular food delivery platforms like GrabFood and GoFood directly within our point-of-sale system. This allows restaurants to seamlessly manage orders from these platforms, streamlining their operations and improving customer experience.
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 enhances the HR payroll user interface by adding a placeholder to the 'struct_id' field. This improves usability by guiding users to select the correct pay category, making the system easier to navigate and reducing potential errors. The change is a simple UI improvement.
Original PR description
- The 'struct_id' field lacked a placeholder, making the UI less intuitive for users. - Added 'placeholder="Choose a pay category"' to improve the user experience. Task: 5960838
This update ensures invoices sent to French, German, or Belgian customers comply with the latest regulations for Factur-X and ZUGFeRD formats. It also adapts invoice formats for B2B and B2G transactions in Germany, using ZUGFeRD for business-to-business and XRechnung for business-to-government invoices, improving clarity and accuracy.
Original PR description
Updating the FacturX format (France)/ ZUGFeRD format (Germany) to respect the new norms: Factur-X 1.07.3 EXTENDED and ZUGFeRD 2.3.3 EXTENDED. Add the differentiation between these two formats in the customer interface, even if they point to the same value in the code. It clarifies things for the customer, things are called by their name. Also, in Germany, for B2B invoices (peppol EAS = 9930), use ZUGFeRD, but for B2G invoices (peppol EAS = 0204), use XRechnung. Adaptation of the default values in the partner form according to this statement. For French and German companies that are sending invoices to French, German or Belgian customers, changed the default format of invoice sent to be compliant to PDF/A-3 norms. task-5266286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252018 Forward-Port-Of: odoo/odoo#237091
This update speeds up testing for the Stock Barcode module by optimizing the initial setup process. Specifically, the creation of a company, which was a significant bottleneck, has been moved to a setup class. While fully moving all setup to the setup class initially caused test failures, this change represents a key improvement in test execution time.
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 enhances the Point of Sale (POS) system by adding a class name to the ticket screen, allowing for easier customization and future improvements. This change, stemming from a previous enterprise-level update, streamlines the development process and provides a more flexible foundation for future POS enhancements. It's part of a larger effort to improve the POS experience.
Original PR description
See odoo/enterprise#94390 Forward-Port-Of: odoo/odoo#226447
This update adjusts the salary scale parameters used in the Odoo Enterprise's Belgian payroll module. Specifically, the starting salary values for 2026 have been updated to reflect current Belgian tax regulations. This ensures accurate payroll calculations for our Belgian clients.
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
Resolved issues and error corrections
This update improves the Gantt editor within Odoo Enterprise by allowing all integer fields to be used with the color selection feature. Previously, only fields directly visible in the editor's view could be chosen. This change provides greater flexibility for visualizing project timelines and tasks.
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 enables cashiers to record multiple payments for a single order in the Point of Sale system. Previously, users were limited to one cash payment line, causing issues when multiple people paid separately. This change improves the user experience and accurately reflects scenarios like groups paying together.
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 corrects an issue where the display of shift durations in the Planning app was inaccurate when shifts spanned across multiple days. Specifically, the system incorrectly truncated shift names when the duration was less than 3 hours. The fix removes outdated logic related to snapping to the grid, ensuring accurate shift duration display across all durations.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109397 Forward-Port-Of: odoo/enterprise#107233
This update fixes a limitation where managers needed a specific group to access their team's voip call records. By changing the access rule to the standard 'group_user' group, all managers now automatically have access, simplifying permissions and improving usability. This ensures consistent access for managers without requiring additional group assignments.
Original PR description
voip_hr defines a record rule that gives managers access to their subordinates' voip.call records. However, this rule is linked to the group 'hr.group_hr_user', which is not granted to all managers. This commit links the rule to the base.group_user group instead, so that all managers can access their subordinates' records without the need for an additional group. [Task-5363640](https://www.odoo.com/odoo/project/5778/tasks/5363640). Forward-Port-Of: odoo/enterprise#100691
A test related to video calls in the Odoo chat window was failing intermittently. This change ensures the test receives the correct data at the start, preventing a delayed data fetch that caused the video to not display properly. This fix addresses a technical issue without impacting the core call functionality.
Original PR description
Test `auto-focus participant video in one-to-one call in chat window` failed non-deterministically at the following step: ``` .o-discuss-CallParticipantCard[aria-label='Batman'] video ``` This issue…
Test `auto-focus participant video in one-to-one call in chat window` failed non-deterministically at the following step: ``` .o-discuss-CallParticipantCard[aria-label='Batman'] video ``` This issue happens because very late in test there's a debounced store fetch of `channels_as_member` from receiving a new message, a call notification, and these store data contain outdated rtc session data, some of which are on `camera_is_on` being `false` instead of `true` that is simulated just prior to the failing step that expects showing of video stream on UI. This commit solely fixes the test by forcing a `channels_as_member` fetch at the very beginning of the test, as to prevent risk of such a late fetch of store data that contains the outdated rtc session data. Note that this test shows a genuine problem and there's ongoing work to solve it (see Task-4966085). This commit merely fixes the test to not show this problem that is out-of-scope of the intent of the test. Fixes runbot-error-240554
This update fixes an issue where clicking an icon within a link's popover didn't work as expected. The fix ensures that link popovers open and function properly when a user clicks on an icon inside the link, improving the user experience for links containing icons.
Original PR description
Problem: When a link contains an icon, clicking on the icon does not properly open the link popover. The popover opens and immediately closes. Cause: The logic for opening the link popover does not handle the case where the selection is not collapsed and is around an icon inside a link. This scenario was not covered in the existing conditions. Solution: Handle the non-collapsed selection case similarly to images: if the selection is around an icon inside a link, the link popover should open correctly. Steps to reproduce: - Add a link. - Insert an icon inside the link. - Click on the icon. - Observe that the link popover opens and closes immediately. task-5921393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue in the India payroll localization where a download button remained visible when the payment mode was set to 'Manually'. The fix ensures the button is hidden correctly, preventing confusion for users. This change improves the user experience for employees using the India payroll system.
Original PR description
Problem ------------------ When the user selects the "Manually" payment mode in the employee payslip, there is nothing to download but the download button is still visible. Affects all companies but only when the India Payroll localization is enabled. Objective -------------------- The Payslip Payment Wizard for the India payroll localization changed the conditions to hide the download button, so when the localization is enabled, all views are overwritten and the button becomes visible for all companies when "Manually" payment mode is selected. Solution ---------------------- Add the manual payment mode to the list of conditions to hide the download button in the l10n_in_hr_payroll localization. Task: 5975685
This update resolves an issue where the Odoo tour would sometimes fail to start after a browser refresh. The change adds a simple delay to ensure the tour is fully loaded and registered before execution, resulting in more reliable tour functionality. This improves the overall user experience and test stability.
Original PR description
Add a `waitUntilTourRegistered` helper to ensure a tour is present in the client-side registry before starting it. After a browser refresh, the tour definition may not yet be loaded when execution resumes. This could cause the tour to abort because it is triggered before being registered. The new helper waits up to 5 seconds for the tour to be available, preventing race conditions and improving test stability. 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
A test failure related to invoice data formatting was resolved. The fix ensures the correct invoice data is used in a key process, preventing potential errors and ensuring proper invoice generation for Turkish VAT invoices. This improves the reliability of the invoicing system.
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 fixes a potential issue with how the Odoo command-line interface handles data directories. While the recommended method is using the odoorc configuration file, this change ensures that the `--data-dir` option is consistently enforced by the platform, providing greater stability.
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 corrects a minor display issue with employee names in the HR module. Specifically, it ensures that the help text associated with employee name fields is correctly copied, improving the user experience and data consistency. This change is a simple fix to enhance readability.
Original PR description
Copy string and help field attributes for virually related employee fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251809
This update resolves an issue preventing the export of Eco-Voucher reports from the Belgian payroll module. The change addresses a technical update related to versioning changes, specifically removing a deprecated 'state' field and aligning it with the new version module. This ensures accurate Eco-Voucher reporting for Belgian companies.
Original PR description
Since the switch from contracts to versions, exporting Eco-Vouchers to excel has not been functional, this commit fixes this. **Steps to reproduce:** - Open Payroll App as a Belgian company - Under Reporting Menu, select Eco-Vouchers - Try exporting with XLSX **Issue:** Since introduction of versions, version module does not contain state field anymore which was present in contracts **Fix:** Removed the state field and replaced it with the corresponding field in version. task:5163668 Forward-Port-Of: odoo/enterprise#109500 Forward-Port-Of: odoo/enterprise#97375
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 critical 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 invoicing in Saudi Arabia. Previously, invoices created with a date and time in SA could be incorrectly set to a future date, leading to rejection by ZATCA. This fix ensures invoices are always created with a valid date and time, respecting Saudi Arabian time zones.
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 a rounding discrepancy in early payment discounts, specifically when 'Always (upon invoice)' cash discount tax reduction is used. Previously, discounts were calculated line-by-line, leading to minor discrepancies. This change ensures discounts are rounded globally for accurate calculations, improving financial reporting.
Original PR description
**PROBLEM** There is a rounding issue with early payment discount when cash discount tax reduction is set to always (upon invoice). The move.line created for the discount is computed by applying the discount to each line, rounding each line individually. But the early payment discount is computed by rounding globally. **STEP TO REPRODUCE** 1. Create a payment term, with early discount of 1%, and cash discount tax reduction set to 'Always (upon invoice)'. 2. Create an invoice with 4 identical lines, unit price 4.76€ and tax 15%. 3. set the payment term on the invoice and save. 4. Go to journal item, early payment discount is 0.20€. 5. toggle discount_amount column on the the journal item tab. 6. notice on the last line, that balance - discount_amount = 0.19€ instead of 0.20€ opw-5865308 Forward-Port-Of: odoo/odoo#251138 Forward-Port-Of: odoo/odoo#247996
This update resolves an issue where sales staff couldn't change or reset payment tokens in subscriptions due to an access error. A recent change in how Odoo calculates payment token display names triggered this error. This fix ensures that the display name for payment tokens is correctly computed, allowing users to manage their payment information as intended.
Original PR description
Use case: - install `payment_sepa_direct_debit` module. - As salesman go to a subscription and try to change/reset the payment token field. When trying to get the values of the `payment_token_id` fields [`name_search()` call] an `AccessError` is raised saying that we don't have access to `payment.provider` model. Since odoo/odoo@a3eef91230e0, fetch() do compute fields, so for payment token this means that `display_name` will be computed without su=True flag, thus it may raise an `AccessError` if accessing some payment provider fields. So this commit force building token display name as sudo, to ensure it can be correctly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251996
This update fixes an issue where taxes weren't correctly applied when the tax's fiscal position was set to 'all'. The change ensures that taxes with this setting are now applied appropriately, aligning with expected behavior. This resolves a discrepancy between the sales order's fiscal position and the actual tax application.
Original PR description
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case…
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder. 2- Set Domestic FP to be applied automatically, and set the country to `US`. 3- Create a Partner with `US` country_id. 4- Create a product, and apply the created tax to sale taxes. 5- Create a SO with created partner and the created product. 6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic. Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp. ### Cause: In this line, if no `tax_ids` is set, it means fp has not tax_ids: https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158 However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation. In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped. ### Fix: This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set. ### Remark: In this fix we rename `TestInvoiceTaxes._create_invoice` to `_create_invoice_taxes_per_line` to avoid override of `AccountTestInvoicingCommon._create_invoice`. This is already done on saas-19.1+. opw-5463245 Forward-Port-Of: odoo/odoo#251872 Forward-Port-Of: odoo/odoo#244155
This update fixes an issue where the price per unit was incorrectly displayed in the shopping cart when products were purchased with packaging. The fix ensures that the price per unit accurately reflects the product's price divided by the actual quantity purchased, resolving a discrepancy in the displayed cart totals. This improves the accuracy of pricing information for customers.
Original PR description
Issue: --- Due to this issue, price per unit is not shown correctly in case of packaging. Steps to reproduce: --- 1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1. 2- Create a…
Issue: --- Due to this issue, price per unit is not shown correctly in case of packaging. Steps to reproduce: --- 1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1. 2- Create a packaging of 0.5 kg, and add it to product in Sale tab. 3- Navigate to the shop and add 0.5 kg of the product to cart. 4- Navigate to the cart. Expected: The line price/unit should be 2.60/kg. Current outcome: It's shown 1.30/kg. Cause: --- Currently `_get_base_unit_price(product_price/line.product_uom_qty)` is shown to user as price/unit. `product_price` is calculated using `_get_cart_display_price()` which returns each line's `subtotal` or `total`. In our case, it will be `_get_base_unit_price(1.30/1)`, having base_unit_count set to 1, we will have 1.30 which is wrong. Fix: --- We would need to divide the line price by `product_qty` instead of `product_uom_qty`. Then in our example we would have: `_get_base_unit_price(1.30/0.5) = 2.60`. opw-5973097 Forward-Port-Of: odoo/odoo#251860 Forward-Port-Of: odoo/odoo#251501
This update optimizes the ZATCA onboarding process for journals by reducing memory usage. Previously, a lengthy check looped through all journal entries, causing errors with large volumes of data. Now, the system directly searches for 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 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 Swiss businesses using this module, aligning with local tax regulations and improving financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#109264 Forward-Port-Of: odoo/enterprise#109228
This update optimizes Odoo's database queries by preventing unnecessary SQL generation, particularly for complex field relationships. Specifically, the system now avoids generating slow SQL when accessing related fields like email content, improving overall performance and reducing resource consumption. Additionally, certain models with intensive access checks have been optimized for faster processing.
Original PR description
## [FIX] orm: stop generating slow SQL Update the context variable to cover the case where we have a related field such as "mail_message_id.body" which is not ran un sudo. In that case, we don't want to generate the SQL. ## [FIX] orm: _access_domain_heavy Mark some models that have heavy access checks so that they can be handled in a special way for performance reasons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249283
This update fixes an issue where SMS reminders weren't being sent for calendar events synced with Google or Microsoft. The fix ensures that Odoo correctly handles SMS notifications for these synced events, aligning with the intended behavior of email reminders being delegated to Google. This improves the reliability of reminders for all users.
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 resolves a bug where the cursor would disappear when replying in the HTML composer, particularly in Firefox. The fix involves adding invisible characters around mentions to ensure proper cursor movement and text insertion, improving the user experience for composing messages.
Original PR description
In chatter, using "Reply" in HTML composer could focus the composer without giving a usable caret. The inserted partner mention is a non-editable link (`contenteditable="false"`), and selection could end up inside that node, so typing would not insert text. This also fix the related firefox issue: mentions are rendered as `a[contenteditable=false]`. Firefox is stricter than Chrome for carret positions around non-editable inline nodes, so clicking before a mention or moving left from its right edge could make stuck. so we register mention selectors as FEFF providers in the mention plugin. (a feature of html_editor FEFF plugin to add invisible boundary characters around mentions, which gives firefox what it need to move carret around. some tests had to be adapted to take the insertion of FEFFs in the composer text into account task-5262368 Forward-Port-Of: odoo/odoo#250711 Forward-Port-Of: odoo/odoo#250296
A technical issue was causing the Activity Logs report to appear incorrectly within the Sign Template list view, leading to errors. This update corrects a misconfiguration in the report's model settings, ensuring it now displays correctly within the Sign Request view and resolves the underlying error.
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 resolves an issue where filtering by 'Analytic Distribution' (set/not set) in journal entries and purchase orders produced incorrect results or errors. The fix ensures accurate filtering by correctly handling boolean values related to analytic distribution accounts, improving 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) causes a "search domain not valid" error or returns incorrect results.
**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 produces error "search domain not valid". Also reproduceable on Purchase Orders.
**Cause:**
The `_condition_to_sql` method did not handle the `('=', '!=')` operators early enough, so it always went to the "operation not supported" error.
**Solution:**
- We need to move the handling of the operators '=', '!=' early enough in the `_condition_to_sql` method.
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#247777This update fixes an issue where combo product refunds weren't correctly handling orderlines with quantities exceeding the combo's total. Now, the system accurately refunds the full quantity of each item within a combo, regardless of individual orderline amounts. This ensures accurate refunds for complex combo orders, improving the user experience.
Original PR description
When refunding a combo item, the 'To Refund' text would always show the same quantity for all the orerlines as for the combo. But combos could have orderlines with a higher quantity than the combo itself (i.e. 3 menus with 2 burgers each - 6 burgers in total. Now the POS would only let us refund up to the limit qty of the combo, so 3 instead of all 6 burgers) After the fix, we check the quantity of each line in the combo and we refund the full quantity (i.e. if you have a 3 menus with 2 burgers each - 6 burgers in total. The burgers will be divided per combo, so each menu refund will automatically refund 2 burgers.) Task-[5503962](https://www.odoo.com/odoo/project/1737/tasks/5503962) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248212 Forward-Port-Of: odoo/odoo#244702
This update corrects a bug where the system was incorrectly returning multiple bank records due to duplicate account numbers, particularly when dealing with child company contacts. The fix ensures that only one bank record is created, streamlining bank management and preventing data inconsistencies. This improves data accuracy and reliability.
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
This update fixes a technical issue within the mass mailing module that ensured the correct identification of editable elements. Previously, the system incorrectly interpreted a shared method, leading to potential inaccuracies. This change improves the reliability and accuracy of mass mailing operations.
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
Features or functions removed from Odoo
This pull request removes a redundant widget from the account module. It was previously linked to an outdated commit and is no longer needed. This simplifies the system and reduces potential maintenance overhead.
Original PR description
After https://github.com/odoo/odoo/commit/fbbbd3314a1574b1196a59bd4229ee81aa932eb7 , this widget is useless --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
16 changes
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 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
Resolved issues and error corrections
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
7 changes
Enhancements to existing features
This update addresses a significant change in the format required for Spanish VAT reporting (Mod303). Specifically, a new field for 'petrol' has been added, and the arrangement of various data elements ('casillas') has been adjusted to comply with updated tax regulations. This ensures accurate and compliant VAT reporting for Spanish businesses.
Original PR description
The format for 2026 changed quite significantly. There is an extra field for the petrol, which we basically do not touch and a lot of casillas that changed places. opw-5990405 Forward-Port-Of: odoo/enterprise#109503
This update adjusts the salary scale parameters used in Odoo's Belgian payroll (l10n_be_hr_payroll) to reflect changes in Belgian tax regulations as of January 1, 2026. These updated values ensure accurate payroll calculations and compliance with local legislation.
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
Resolved issues and error corrections
A technical issue was causing the Activity Logs report to appear incorrectly within the Sign Template list view, leading to errors. This update corrects a misconfiguration in the report's model settings, ensuring it now displays correctly within the Sign Request view and resolves the underlying error.
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 clarifies the behavior of Helpdesk article searches when using non-root articles as the main article. Previously, searches didn't include descendant articles. Additionally, a minor issue with dropdown display has been addressed to ensure consistent functionality.
Original PR description
*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…
*: website_helpdesk_knowledge
**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help
First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant
Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback
**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.
This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.
The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.
**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.
Also manually reset the attribute for `_onFocusOut`.
related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11
opw-5258607
Forward-Port-Of: odoo/enterprise#107438This update fixes a potential data error that could occur when moving folders linked to accounting settings to the trash. The system now prevents these folders from being deleted during a routine data cleanup process, ensuring data integrity and stability. This resolves a technical issue identified through monitoring and testing.
Original PR description
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``documents_account`` module - Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save > - Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save - Go to Documents > Click on Workspace A > Actions > Move to trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint "documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting" ``` solution: override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings, preventing their deletion during the garbage collection. sentry-7193540869 Forward-Port-Of: odoo/enterprise#109434 Forward-Port-Of: odoo/enterprise#104875
This update resolves an issue where by-products tracked by serial number were incorrectly displaying extra lines in the shop floor manufacturing order views. The fix ensures that by-products only show lines that are manually added, aligning with the intended workflow. This improves the clarity and accuracy of shop floor data.
Original PR description
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295 Forward-Port-Of: odoo/enterprise#103260
This update resolves an issue where the Documents app would crash after deleting a payslip run. The fix ensures that related documents are also deleted when a payslip run is removed, preventing data inconsistencies and improving application stability. This update addresses a technical debt related to how payslips and documents are linked.
Original PR description
### Issue: When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app. ### Steps to reproduce: - Have a…
### Issue: When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app. ### Steps to reproduce: - Have a payslip run with payslips - Go to a payslip, validate and generate the document - Then cancel and reset to draft - Reset the Payslip Run to draft - Delete it - Open the Documents app ### Cause: The payslips are linked to the run with a `ondelete='cascade'` relation. https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113 This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB. ### Solution: Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there. opw-5501061 Forward-Port-Of: odoo/enterprise#109374 Forward-Port-Of: odoo/enterprise#105969
13 changes
Enhancements to existing features
This update simplifies how Odoo creates stock packages during the 'Put in Pack' process. By moving the creation logic into a separate method, it makes customizations easier for users needing to adjust package creation rules. This improves flexibility and maintainability of the stock module.
Original PR description
Move the logic that creates a new 'stock.quant.package' into a dedicated method `stock.picking::_get_put_in_pack_package`. This allows cleaner overrides when custom logic is needed for package creation during the "Put in Pack" process. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249050 Forward-Port-Of: odoo/odoo#247952
This update addresses a significant change in the format required for Spanish VAT reporting, specifically for the 2026 tax year. The update includes a new field for 'petrol' and adjustments to the arrangement of various data elements (casillas). This ensures continued compliance with Spanish tax regulations.
Original PR description
The format for 2026 changed quite significantly. There is an extra field for the petrol, which we basically do not touch and a lot of casillas that changed places. opw-5990405 Forward-Port-Of: odoo/enterprise#109503
This update adjusts the salary scale parameters used in the Odoo Enterprise's Belgian payroll module (l10n_be_hr_payroll). Specifically, the values for January 1st, 2026, have been updated to reflect current salary regulations in Belgium, ensuring accurate payroll calculations. This change maintains compliance with local tax and social security requirements.
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
Resolved issues and error corrections
This update resolves a critical issue where a user's inbox could crash when accessing multiple companies. The fix addresses a permissions problem related to partner access, preventing a scenario where a user's inbox became inaccessible after interacting with a partner in a different company. This ensures stable inbox functionality across all company setups.
Original PR description
### Issue: Due to this bug, user's inbox can crash and become inaccessible by another user. #### Steps to reproduce: 1- Create a db with two companies and sale installed with demo data. 2- Demo user…
### Issue: Due to this bug, user's inbox can crash and become inaccessible by another user. #### Steps to reproduce: 1- Create a db with two companies and sale installed with demo data. 2- Demo user should only have access to company A 3- Demo user preference should be handle in Odoo 4- Admin should access both companies 5- Create a partner called partner_b with company set to company B 6- Using admin create a SO in company B, with the partner_b 7- Send a message (not internal note) in SO chatter, and mention Demo user 8- Login using Demo user 9- Open discuss app. As you see the inbox is not accessible anymore. ### Cause: This is caused because Demo user doesn't have read access to partner_b, as a result `partner_share` cannot be accessed in `_filter_unimportant_notifications`: https://github.com/odoo/odoo/blob/7a02ae3c220dc53ed541f5a1ec88abcd49c3baeb/addons/mail/models/mail_notification.py#L112-L117 opw-5089738 Forward-Port-Of: odoo/odoo#245704 Forward-Port-Of: odoo/odoo#232894
This update fixes a bug where users could cancel subscriptions even if they didn't have access to the associated invoices. Now, a user must view the invoice before they can cancel the subscription, ensuring accurate subscription management and preventing accidental cancellations. This improves data integrity and reduces potential revenue loss.
Original PR description
Before this commit, when a user had access to an invoiced subscription but not to the invoiced, he could cancel the subscription. Step to reproduce: - create a subscription in company A, with a pricelist available in company B. Sales person A belong to company A. - invoice the subscription and confirm the invoice - update the company (company B) and sales person of the subscription (B). The new salesperon don't see the invoice in the stat button. After this commit salesperson B can't cancel the subscription. task-5907345 Forward-Port-Of: odoo/enterprise#108321 Forward-Port-Of: odoo/enterprise#106441
This update resolves a visual discrepancy in the Mass Mailing app's card styling, specifically related to rounded corners and background colors when using the 'Stretch to Equal Height' option. The fix ensures that the card's design accurately reflects the preview, improving the user experience for email creation.
Original PR description
**Steps to reproduce:** - Go to mass_mailing app - Add Columns block with multiple content size - Increase Round Corners (e.g. 20 px) - In "Vert. Alignment" field > Select the "Stretch to Equal…
**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body
**Issue:**
Default table style used for the inline conversion of
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.
This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.
Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0
**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.
Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).
Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.
opw-5218581
Forward-Port-Of: odoo/odoo#242001This update resolves a memory issue that occurred when validating journal entries for ZATCA onboarding. By streamlining the data check process, the system now efficiently handles large journals without running into errors, ensuring smoother onboarding for users in Saudi Arabia. This improvement enhances the overall stability and performance of the Odoo system.
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 system was incorrectly filtering out SMS reminders for these synced events. This change ensures that SMS notifications are consistently delivered for all calendar events, regardless of their sync source.
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 error was causing the Activity Logs report to appear incorrectly within the Sign Template list view, leading to a system error. This update corrects a misconfiguration in the report's model settings, ensuring the report now displays correctly within the Sign Request view and resolves the underlying issue.
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 addresses a change in how Helpdesk articles are searched. Previously, searching from a non-root article would include all descendant articles. Now, searches are limited to the selected article only. Additionally, a minor issue with dropdown functionality has been resolved.
Original PR description
*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…
*: website_helpdesk_knowledge
**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help
First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant
Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback
**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.
This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.
The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.
**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.
Also manually reset the attribute for `_onFocusOut`.
related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11
opw-5258607
Forward-Port-Of: odoo/enterprise#107438This update resolves an issue preventing users from sharing content hosted externally (like Google Drive) through the website's share feature. The fix prevents a browser error caused by a security restriction related to accessing content from different web origins. This ensures the share button consistently works for all content types.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Open any course and add content 3. Select the `Document` type and upload a Google Drive link 4. Save and publish the content 5. Click the "Share" button for this specific content in full screen Issue: - A traceback occurs: `Uncaught Javascript Error > Failed to read a named property 'document' from 'Window': Blocked a frame with origin "http://localhost:3000" from accessing a cross-origin frame.` Cause: - The `_onClickShareSlide` method attempts to calculate the `documentMaxPage` by accessing the internal DOM of the slide's iframe (`iframe.contentWindow.document`). When the content is hosted externally the iframe source is cross-origin. Browsers enforce the Same-Origin Policy. Solution: - Check the origin of the iframe's source URL before attempting to get max page. opw-5422655 Forward-Port-Of: odoo/odoo#250679 Forward-Port-Of: odoo/odoo#241090
This update fixes an issue where meeting dates in the CRM were incorrectly displayed as a day after the scheduled meeting, particularly when using a browser's timezone setting. The fix aligns the displayed date with the user's timezone preference, ensuring accurate meeting scheduling and visibility. This improves the user experience and prevents confusion regarding meeting times.
Original PR description
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) -…
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) - Go to the form view of an opportunity - Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity) - In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00) - Go back to the opportunity for view # The problem The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11 # Why The calendar view uses the browser's timezone to manage the dates. The smart button does not. It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly. The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences. opw-5898520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247984
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed as customer ratings are no longer visible on the website. This change improves the user experience and reduces unnecessary data display.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#100686
1 change
Enhancements to existing features
This update addresses a significant change in the format required for Spanish tax reports, specifically for the year 2026. The update includes a new field for 'petrol' and adjustments to the arrangement of various data elements ('casillas'). This ensures continued compliance with Spanish tax regulations.
Original PR description
The format for 2026 changed quite significantly. There is an extra field for the petrol, which we basically do not touch and a lot of casillas that changed places. opw-5990405 Forward-Port-Of: odoo/enterprise#109503
6 changes
New functionality added to Odoo
This update allows customers to directly buy VoIP phone numbers within Odoo. Previously, this process was manual, and now it's integrated into the platform, streamlining the customer onboarding experience. This enhancement improves convenience and simplifies the setup of VoIP services.
Original PR description
iap-apps: https://github.com/odoo/iap-apps/pull/1370 [Task-5214642](https://www.odoo.com/odoo/project/5778/tasks/5214642)
Enhancements to existing features
This update simplifies the user interface by standardizing the term 'Audit Report' to 'Annual Report'. Previously, the use of both terms created confusion for users. This change improves clarity and user experience within the Enterprise module.
Original PR description
The user interface currently uses both the terms "Audit Report" and "Annual Report", which can be confusing for users. To eliminate this confusion, "Audit Report" will be renamed to "Annual Report". Task-5902500
Resolved issues and error corrections
This update addresses a change in Amazon's SP-API, which is used to automatically update inventory levels between Odoo and Amazon. The system has been upgraded to use a new feed type (`JSON_LISTINGS_FEED`) to maintain compatibility with Amazon's updated API. This ensures continued accurate stock synchronization.
Original PR description
Amazon SP-API is dropping support for the `POST_INVENTORY_AVAILABILITY_DATA` feed type. This was previously used in Odoo to synchronize the stock level with Amazon. This commit upgrades the feed api to use the new `JSON_LISTINGS_FEED` as a replacement. task-3820591
This update resolves a minor issue within the account reports testing suite. The fix ensures that a specific test tour related to audit trails is correctly executed, improving the reliability of our reporting tests. This ensures consistent and accurate reporting functionality.
This update now accurately tracks shipments with multiple delivery orders for Amazon, providing the correct tracking number for each sale order line. Previously, only the first delivery's tracking number was shared with Amazon, leading to inaccurate customer visibility. This enhancement ensures customers receive correct and complete shipment information.
Original PR description
Previously, shipments via multiple delivery orders could not be tracked accurately. Only the tracking number of the first delivery was provided to Amazon, and displayed to the customer. With this commit, deliveries are now split per sale order line, and all tracking numbers are synchronized correctly. task-3062424
This update fixes an issue where document fields referencing related records weren't correctly identified. The change ensures that Odoo accurately represents and manages relationships between documents and other data, leading to more reliable data and improved system performance. This primarily impacts how documents are linked to other modules within Odoo.
Original PR description
See https://github.com/odoo/odoo/pull/196498
14 changes
New functionality added to Odoo
This update introduces support for online food delivery platforms like GrabFood and GoFood within Odoo Enterprise. The changes include a foundational code structure for future platform integrations and initial connections to these popular delivery services, streamlining order fulfillment for restaurants.
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
Enhancements to existing features
This update streamlines the process of setting up tests for key Odoo modules, specifically related to payroll and timesheet management. By centralizing test setup, the team has improved the efficiency and reliability of our automated testing, leading to faster identification and resolution of potential issues.
Original PR description
Forward-Port-Of: odoo/enterprise#109476 Forward-Port-Of: odoo/enterprise#108739
This update adjusts the salary scale parameters used in the Odoo Enterprise's Belgian payroll module. Specifically, the values for the first year of the salary scale (cp200_salary_scale_first_year) and the overall salary scale (cp200_salary_scale) have been updated to reflect the new minimum wage effective 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 logging for the Codabox integration within the Odoo Enterprise system. Specifically, it improves the tracking of transactions related to Codabox, providing the support team with more detailed information to quickly diagnose and resolve any potential issues. This will reduce troubleshooting time and improve the overall reliability of the integration.
Original PR description
This commit will improve the logs of _l10n_be_codabox_fetch_coda_transactions to help the support team to debug possible problem. task-5436868 Forward-Port-Of: odoo/enterprise#108213 Forward-Port-Of: odoo/enterprise#107779
Resolved issues and error corrections
This update resolves a problem where the Stripe payment integration wasn't working correctly for certain locations (like Mexico). The change to default to EUR caused an error when the currency wasn't active, preventing the Stripe account from loading. This fix ensures Stripe functionality is reliably available for supported regions.
Original PR description
**STEP TO REPRODUCE** On a freshdb with only base module. 1. install hr_expense_stripe. 2. install l10n_mx (or any location that's not EU, US or UK). 3. select one of the mx demo company. 4. try opening the invoicing/accounting app. 5. There will be a traceback when loading the stripe account on the dashboard. **CAUSE** https://github.com/odoo/enterprise/pull/108293 changed the default currency from USD to EUR. But EUR could be unactive when searching for it, leading to to stripe_currency_id being empty. opw-59752385
This update resolves a crash occurring when posting expense entries with the Avalara Avatax integration. The change adjusts how Avatax handles expense move types, specifically addressing a 'KeyError' related to 'in_receipt'. This ensures smoother expense processing for US-based employees using Avatax.
Original PR description
Currently, the expenses flow with Avatax integration crashes when posting the expense entry. Steps to reproduce: - Have an employee with an address in the US. - Enable 'Detect Automatically' in the Avalara fiscal position. - Create an expense for the employee, paid by Employee. - Submit > Post Journal entry > Post Expense. Action will be blocked by a traceback reporting error `KeyError: 'in_receipt'` Analysis: After [1] expense journal entries are now 'in_receipt'. The dictionary in account_avatax does not take into account this move type. This provides a fallback to 'Any' for any other move types [1] https://github.com/odoo/odoo/commit/f835ac0c8adb49d04bed746fd624b8976cc32991 opw-5872768
This update corrects a technical issue that was preventing internal users from accessing AI tools within the Odoo Enterprise platform. The fix involved adjusting access permissions to allow internal users to retrieve the necessary tool information, ensuring seamless functionality for AI-powered features. This resolves a reported error during voice transcript commands.
Original PR description
Steps to reproduce: 1. Open any editor and use /voice transcript command. 2. Start recording, say some words, stop recording. 3. Observe the access error on `tool_ids`. The `tool_ids` field on `ai.topic` is restricted to `base.group_system`, preventing internal users from accessing it. The fix is to use sudo to retrieve the available tools. ticket task-5965009
This update resolves an issue where tax report tags were incorrectly sorted, preventing proper auto-completion functionality. The fix ensures tags are correctly ordered, improving the user experience and accuracy of tax reporting. Improved testing has also been implemented to prevent similar issues in the future.
Original PR description
Commit https://github.com/odoo/odoo/commit/db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong Tags must be sorted for the auto complete to work properly Improving tests to catch more errors opw-5415426
This update improves the Gantt editor by allowing all integer fields within a model to be used as color options. Previously, only fields directly visible in the editor's view were selectable. This change provides greater flexibility for visualizing project timelines and tasks.
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 corrects a display error in the Activity Logs report. Previously, the report was incorrectly appearing within the Sign Template list view, leading to an error. The fix ensures the report appears in the correct Sign Request view, improving usability and preventing technical issues.
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 flexible calendar employees were incorrectly displaying unavailable days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the planning process for teams using flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#109422
Forward-Port-Of: odoo/enterprise#105521This update addresses a change in how Helpdesk articles are searched. Previously, setting a non-root article as the main article allowed searching across its entire family of articles. Now, searching only returns the selected article itself. Additionally, a minor issue with dropdown behavior has been fixed.
Original PR description
*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…
*: website_helpdesk_knowledge
**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help
First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant
Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback
**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.
This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.
The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.
**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.
Also manually reset the attribute for `_onFocusOut`.
related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11
opw-5258607
Forward-Port-Of: odoo/enterprise#107438This update corrects a problem with how leave periods are calculated, specifically addressing potential inconsistencies caused by different time zones. By updating the system to use 'request_date_from' and 'request_date_to' instead of 'date_from' and 'date_to', the system now accurately reflects leave periods regardless of user time zone settings.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780 Forward-Port-Of: odoo/enterprise#109233 Forward-Port-Of: odoo/enterprise#108541
A recent update caused a disruption in our SEPA direct debit payment processing. Customers were unable to complete payments using this method due to a technical error. This fix resolves the issue, restoring reliable SEPA direct debit functionality.
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
5 changes
Resolved issues and error corrections
This update resolves an issue where Field Service users couldn't add customers to tasks, resulting in an access error. The fix uses a secure method (sudo) to update partner records during task creation, allowing users to correctly assign customers without restricted access limitations.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Used sudo() in the inverse method to update the partner phone securely, bypassing restricted access. task-5039657
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies. Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration. To prevent this, restrict chart loading to root
Original PR description
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be…
During migration, the `l10n_pl` end-migrate script was loading
for every company using the `pl` chart template, including child companies.
However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.
To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.
**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors
**Traceback**
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
Template._load_data({'account.account': Template._get_account_account('pl')})
File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-196>", line 2, in create
File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
records._ensure_code_is_unique()
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```
**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.
opw-5932421
upg-3895331
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-prThis update prevents Instagram posts from failing due to delays in media processing. By using a scheduled cron job to retry publication, the system now handles temporary processing lags gracefully, ensuring posts are successfully published without impacting server performance. This improves the reliability of Instagram content distribution.
Original PR description
With the current behavior the Instagram API sometimes requires time to process media containers, the media_id is not yet ready on Instagram side, leading to failed posts. To avoid this, we now use an asynchronous flow: If the media container is not immediately 'FINISHED', we store the container ID in `instagram_post_id` (prefixed with `containerIDs-`), set the state to 'posting', and trigger the scheduled cron to retry in 1 minute. The `_cron_publish_scheduled` method has been updated to detect these pending posts and resume the publication attempt so workers remain free while Instagram processes the media. opw-5081325 Co-authored-by: @ushyme
This update fixes an issue where instructions added to Work Orders weren't correctly linked when creating a Manufacturing Order (MO) via the mobile app. The fix addresses a previous change that removed a key data field, preventing the proper connection between the BOM and the MO. This ensures instructions are accurately reflected when creating MOs on mobile devices.
Original PR description
# How to reproduce - Create a BOM for a product with a Work Order - Add instructions to the WO - Using mobile, create a new MO for the product # The problem The instructions are not linked to the MO. This can easily be seen via the shop floor application # Why This issue is identical to https://github.com/odoo/odoo/pull/197889. This commit https://github.com/odoo/odoo/commit/b1ceec4c616d8ad2fee5b0fa1ce76c85cacbb344 removed the operation_id field from the workorder kanban mobile view, which is used in the MO form on mobile. operation_id is then not passed to the server in vals_list when creating the MO but it is required to link the instructions from the BOM to the MO. opw-5950983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where contacts incorrectly remained marked as blacklisted after being removed from the blacklist. The change ensures the displayed status accurately reflects the current blacklist state, preventing user confusion and improving data accuracy. This resolves a potential misunderstanding for users managing employee contacts.
Original PR description
### Issue before this commit: When removing an email address from the blacklist, the contact could still appear as blacklisted when accessed through the Employee>Contacts smart button. ### Steps to…
### Issue before this commit: When removing an email address from the blacklist, the contact could still appear as blacklisted when accessed through the Employee>Contacts smart button. ### Steps to reproduce the issue: 1. Install email marketing 2. Go to Blacklisted email addresses 3. Add a new email (ex. mark.brown23@example.com that is already an user and an employee for My Company (San Francisco)) 4. Check contact cart to see that email is blocked 5. Remove email from blacklist 6. Go through users > employee (with smart button) > contact (with smart button) 7. See that the email continues to be blocked even if it was removed 8. If you refresh it will temporarily fix the problem and also going from home page to contact direclty will display correctly the email that is not blocked ### Cause of the issue: The action opening the related contact inherited a context with active_test=False. As a result, archived records in mail.blacklist (i.e., entries with active=False created after unblacklisting) were still considered during the computation of is_blacklisted, causing the contact to incorrectly appear as blacklisted until the page was refreshed or the contact was opened through another navigation path. ### Reason to introduce the fix: This inconsistent behavior can confuse users and lead them to believe that a non-blacklisted contact is still blacklisted. The change guarantees that the displayed status accurately reflects the actual blacklist state. opw-5952301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
This update fixes a potential issue where users could refund multiple orders through a single refund transaction, leading to errors. The change now restricts refunds to a single order, ensuring data integrity and preventing unexpected system behavior. This improves the stability and reliability of the Point of Sale module.
Original PR description
Before this validation, it was possible to refund multiple orders per refund, but this resulted in a traceback if some orders were invoiced. This validation blocks the possibility of having multiple orders per refund, as in the following versions. opw-4791231
This update clarifies error messages related to stock package consistency checks. Previously, the messages didn't identify the specific problematic package, causing delays for users with large transfers. Now, the error messages pinpoint the issue, enabling customers to quickly diagnose and resolve the problem themselves.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error that was causing debit notes to be rejected by the Italian SDI system. The issue stemmed from a typo in a field related to linked invoices, which prevented the correct XML format from being generated. This change ensures accurate data transmission and compliance with Italian tax regulations.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr