Daily updates from Odoo
Wednesday, September 24, 2025
43 changes · saas-18.4
New functionality added to Odoo
Adds support for Danish companies to register with Nemhandel and exchange electronic invoices and credit notes through the AS4 network. This enables compliant OIOUBL-based invoicing directly from Odoo, improving access to Danish public and business e-invoicing workflows.
Original PR description
Following Peppol, to send to IAP to our proxy Allow to register to Nemhandel. Alow to send and receive OIOUBL Invoices and Credit Notes through the AS4 network. task-3524121 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227968 Forward-Port-Of: odoo/odoo#219886
Enhancements to existing features
The model selector can now be configured to show more items at once. This lets Documents display its full list of available models without changing behavior in other areas.
Original PR description
In Documents, we have a static list of 9 items to show with this widget. As there is no "Search more" available, and we're in stable, this is the minimal change to not change behavior. Task-5075200 See related ENT PR (includes an integration test). Forward-Port-Of: odoo/odoo#226608
The Documents details panel now displays the full static list of available model labels instead of leaving users to infer hidden options. This makes selection clearer and reduces confusion because search is not available for this list.
Original PR description
As the list is static and there are only a few and searching for more is not supported, this enables to show all labels so that users don't have to guess what is available or not. Task-5075200 Forward-Port-Of: odoo/enterprise#94180
Resolved issues and error corrections
Fixed an issue that could block sending certain Colombian electronic invoices when a debit note reference was missing. This prevents users from hitting an error during invoice email submission and improves reliability for Colombian localization workflows.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763
Users applying unsupported filters to image or other binary fields will no longer encounter an unexpected error. The system now records the issue as a warning instead, helping keep filtering workflows stable while still flagging the invalid condition for follow-up.
Original PR description
Currently, an error occurs when user tries to apply an invalid filter on any binary field.
Steps to replicate:
- Add a filter like [('image_1024', 'in', [])] in the custom filter where the image exists(eg, Products) and save.
- Error triggered.
Error:
`ValueError: Binary field stored in attachment, accepts only existence check; skipping domain in condition ('image_1024', 'in', OrderedSet(['']))`
Cause:
- The system encountered an error when users attempted to apply invalid filters on binary fields (e.g., image_1024). The error occurs when operators like 'is in' with empty string values ('') are used, as binary fields are stored as attachments only support existence checks.
Solution:
- Changed the `_logger.exception` to `_logger.warning`.
sentry-6236134077
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFleet manufacturer pages now count only active vehicle models, so totals better reflect the models currently in use. Users can also filter vehicle models to find archived records when needed, improving record visibility without affecting daily workflows.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
This update fixes a failing automated test for Hong Kong payroll accounting related to leave generation changes. It helps keep payroll file validation stable and reduces the risk of blocked releases due to test failures.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902 Forward-Port-Of: odoo/enterprise#95084
The follow-up report no longer crashes when users load more entries for customers with many invoices. This helps accounting teams reliably review customer payment follow-ups without interruption.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103This update refreshes the spreadsheet component and fixes an issue when sorting certain array formulas. Users should see more reliable spreadsheet behavior when working with formulas and sorted data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0c9130545 [REL] 18.4.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e9cb9e1b9 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update prevents crashes for public users browsing with older Safari versions by adding missing browser support needed for translation caching. Visitors on Safari before version 17 should now be able to load pages normally instead of encountering failures at launch.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228120
Journal entry numbers can no longer be changed directly from the Accounting list view when entries are not in draft. This helps prevent accidental changes to posted or confirmed accounting records and keeps financial records more reliable.
Original PR description
**Issue** It was possible to edit the journal entry number in the list view even when the entry state was not 'draft'. **Steps to Reproduce** 1. Go to Accounting > Accounting > Journal Entries. 2. Select any journal entry. 3. Double-click on the Journal Number field and attempt to edit it. **Root Cause** The 'name' field in the list view did not have a readonly attribute, allowing inline editing regardless of the journal entry's state. Opw-5009421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224475
This update fixes an internal test for journal reports that could fail when Czech localization was installed. It makes the validation adapt to the actual payment reference value, improving build reliability without changing user-facing behavior.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
Italian electronic invoices marked as TD01 are now kept as the correct invoice type when imported as vendor bills. This prevents purchase invoices from being mislabeled as TD05, improving accounting accuracy and compliance with Italian e-invoicing rules.
Original PR description
**Issue** When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing. **Steps to Reproduce** 1. Install Accounting, l10n_it and l10n_it_edi 2. Go to…
**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.
**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05
**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891
**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.
opw-4931438
Forward-Port-Of: odoo/odoo#219310Refreshing appointment time slots now handles cases where no resource is selected. This prevents errors during slot refreshes and helps users continue booking appointments smoothly.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
This fix makes website theme palette testing more dependable by ensuring asset reloading happens at the right time. It reduces intermittent test failures, helping maintain confidence in website theme changes without affecting end users.
Original PR description
The goal of this commit is to fix an undetermined bug in the theme tab palette tests. Sometimes, ‘reload assets’ occurred before the end of the test. We will therefore wait to go through ‘reload assets’ before the end of the test in order to make it deterministic. Error: https://runbot.odoo.com/odoo/error/232650 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
This change fixes a randomly failing accounting test by removing an invalid check and adding safeguards for future localization data. It helps keep automated validation stable and ensures new fiscal position data does not introduce unsupported domestic matching cases.
Original PR description
#### Issue: `test_domestic_fp` randomly fail #### Cause: While computing domestic fiscal position, there are 2 fiscal position candidates for being domestic as they got the same `sequence` and no `country_id`. It happens randomly that the second one is fetch instead of the first one. #### Solution: The failing assert checks a case that doesn't exist in any fiscal position data. Therefore, this commits remove this part of the test, but add a warning in `test_all_l10n` to ensure this case won't happen in new data. runbot-231686 This PR is linked to [this PR](https://github.com/odoo/odoo/pull/224599) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226336
This update removes a fixed year from automated point-of-sale test data so invoice settlement checks continue to work over time. It helps prevent false test failures and keeps the Spanish point-of-sale validation process stable without changing user-facing behavior.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 enterprise PR: https://github.com/odoo/enterprise/pull/93166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224171
This fix removes a fixed calendar year from a point of sale test that selects invoices for settlement. It helps keep automated checks reliable over time, reducing false failures that can slow down delivery.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171 Forward-Port-Of: odoo/enterprise#93166
Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. This prevents loss of ticket history and blocks merges when selected entries belong to different tickets, reducing reporting and billing mistakes.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
Fixed a typo that caused lock date warning messages in accounting reports to display list items with incorrect indentation. This makes the message clearer for users when report external values cannot be modified due to lock dates.
Original PR description
[FIX] account_reports: typo in error message typo in generation of error message saying that lock dates are blocking the modification of a report external value See odoo/enterprise#92949 Forward-Port-Of: odoo/enterprise#95175
This fix makes Ctrl+Backspace behave consistently in the HTML editor across Firefox, Safari, and Chrome. Users editing text will get the expected deletion result at paragraph boundaries, reducing confusing browser-specific behavior.
Original PR description
**Current behavior before PR:**
In Firefox or Safari, `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` ends up with `<p>abc []</p>` which is different o/p than Chrome (`<p>abc def[]</p>`).
This happens because Firefox's Selection.modify("extend", "backward|forward", "word") behaves differently than Chrome when the cursor is at the start or end of a block (or in an empty block). This behavior breaks the output when pressing ctrl + backspace.
**Desired behavior after PR:**
This PR ensures that in such case deletion behavior is same across browsers as Chrome. In other words `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` should be `<p>abc def[]</p>` .
task-5055135
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226040Fixes the Swiss ISO20022 payment export so generated XML files match current Swiss bank validation requirements. This helps businesses using Swiss batch payments avoid rejected vendor payment files and related payment delays.
Original PR description
Since July, the iso20022 payment method is to not be accepted by some Swiss banks anymore. How to reproduce? Install account_iso20022 and enable batch payments in the accounting settings. Configure your journal adding the payment method "Swiss ISO20022" in the outgoing payments and setting the XML format as "pain.001.001.09". Pay a vendor bill using the "Swiss ISO20022" payment method. Go to the journal payment, select the previous payment and create a batch. On the batch payment, you can find the XML file which is not validated by Swiss banks. test validation on: https://ubs-paymentstandards.ch/login opw-4976852 opw-4675667 opw-4996910 opw-4895258 opw-5006895 task-id: 5000729 Forward-Port-Of: odoo/enterprise#94940 Forward-Port-Of: odoo/enterprise#92532
Automation rule setup now avoids carrying over a hidden setting that caused archived records to appear in related selection dialogs. This keeps record searches cleaner and prevents users from accidentally selecting inactive records while configuring automations.
Original PR description
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the…
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the action_server_ids.resource_ref search view dialog. - Steps to reproduce: - have base_automation installed - create an automation rule targeting the res.users model - add an Update server action targeting the Partner field - in the resource_ref autocomplete, click on Search More... - the search view dialogs displays archived records **After** - we chose to instead have a default filter in the base_automation_act action to include archived records by default. As the context key to activate the default filter starts with 'search_default_', it is already cleared from the context when opening the form view (standard behavior). - when you reproduce the same steps as before, the archived records are no longer displayed in the search view dialog. **Additional Note** This fix requires to upgrade the base_automation module. opw-4886487 Forward-Port-Of: odoo/odoo#225146
The Point of Sale payment screen now correctly disables the Validate button on mobile when no payment method is selected. This helps prevent checkout mistakes and keeps mobile payment behavior consistent with expected cashier workflows.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. task-id: 5072759 enterprise PR: https://github.com/odoo/enterprise/pull/94100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228057 Forward-Port-Of: odoo/odoo#225917
The Point of Sale payment screen now correctly prevents mobile users from validating an order when no payment method is selected. This helps avoid incomplete or incorrect payment flows and keeps mobile checkout behavior consistent with expectations.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#95227 Forward-Port-Of: odoo/enterprise#94100
Users can now enter a checkout time directly from the attendance Gantt popup when an attendance is still open. This fixes a display issue that hid the checkout field and forced users to use another form to complete the attendance record.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
Chilean electronic delivery guide XML now shows the quantity actually delivered instead of the quantity originally requested. This prevents customers and compliance documents from showing overstated product quantities when only part of an order is delivered.
Original PR description
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered…
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE. **Steps to Reproduce** 1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock. 2. Create and confirm a new Sale Order. 3. Click on the Delivery smart button. 4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder. 5. Generate the Delivery Guide. 6. Open the generated DTE XML and observe that the quantity is incorrect. **Root Cause** The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount. **Fix** Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE. Opw-4892276 Forward-Port-Of: odoo/enterprise#89633
Products using the Barcode Database will no longer have existing eCommerce descriptions replaced by information from barcode lookup results. This protects manually written product content while still allowing missing details to be filled in automatically.
Original PR description
Scenario: - enable "Barcode Database" in general settings - set an eCommerce description on a product - set a barcode in the database on that product (eg. 799439112766) Result: the eCommerce description has been overwritten by the barcode lookup result. Fix: do like other _update_product_by_barcodelookup methods and only update value that are not yet set. Note: also fixes the return of the overridden methods. opw-5061231 Forward-Port-Of: odoo/enterprise#94098
Fixed an issue where closing the currency rate filter could try to update an accounting report after the report view had already been closed. This prevents an unexpected error and keeps users from seeing a crash when navigating away from reports.
Original PR description
For the currency rate filter, applyFilters is called when the dropdown is closed. It might heppen that we have the dropdown open then we click on something that trigger the destruction of the report view but that still trigger applyFilters which try to apply filter on a destroyed component which is illegal. To prevent this we check if the component is destroyed before reloading the controller. Forward-Port-Of: odoo/enterprise#94313
The Belgian POS fiscal reports and invoice views no longer show the warning "THIS IS NOT A VALID VAT TICKET". This avoids confusion because the warning is only relevant for POS receipts that are not final VAT tickets, not for reports or invoice views.
Original PR description
- Remove the message "THIS IS NOT A VALID VAT TICKET" from the invoices and POS daily reports views. This message is only necessary on POS receipts that are not final TVA tickets. task-id: 5013860 Forward-Port-Of: odoo/enterprise#92287
Fixed an issue where the command palette could crash when a task or project status field had no available options. Users can now continue working normally; the unavailable action is simply hidden instead of causing an error.
Original PR description
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks…
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks - Create a new task with the new created project - Then using the keyboard shortcut ctrl + k for command search, an error occurs **Cause:** - When the `stage_id` statusbar had no possible values, `this.getAllItems()` returned an empty array. - The command `isAvailable` unconditionally accessed `this.getAllItems().at(-1).isSelected`, which is undefined, causing a crash.[see](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L147-L148) **Fix** - Add safe check in the command action so it does not attempt to select a non-existent "next" item. **Result** - The command palette no longer crashes when the `stage_id` field has no available items. Instead, the command is simply unavailable. opw-5084130 upg-3130405 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228130 Forward-Port-Of: odoo/odoo#227440
This fix passes the needed action identifier into the web view context so Odoo Studio can tell whether an action may be edited. It helps prevent incorrect editing availability in Studio without changing normal user workflows.
Original PR description
This information is required so that the studio can determine whether the action can be edited. opw-5066488 Forward-Port-Of: odoo/odoo#227264
Barcode transfers now keep kit components separate from the same component added independently when lot tracking is used. This prevents incorrect grouping in the barcode flow and avoids unnecessary backorders after users enter the correct quantities.
Original PR description
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating **Steps to reproduce:** - create two products tracked by lot (comp A and comp B) - set an on hand quantity for both - create a storable product (final product) and create a BOM - in the BOM add comp A and comp B - create an internal transfer for 1 final product and 1 comp B - click on "mark as todo" - open this transfer in barcode, we see that the two lines from the comp B are grouped - scan the source location, click on +1 and +2 button to fulfill the quantities and validate **Current behavior:** a backorder is created **Expected behavior:** no backorder should be created as we entered the right quantities of the picking **Cause of the issue:** the lines from comp B should not have been grouped in the barcode picking. When doing the same scenario but with product not tracked those lines are not grouped opw-4998766 Forward-Port-Of: odoo/enterprise#93947 Forward-Port-Of: odoo/enterprise#93262
This fix prevents website editing actions from trying to load administrator-only view data for non-admin users. Website editors can now update the menu bar without encountering an access error, improving reliability for day-to-day site management.
Original PR description
Scenario: - get a user with "Editor and Designer" and no admin rights - with this user, edit the website and change the menu bar Result: A traceback error is shown with this access error the logs: You do not have enough rights to access the field "visibility_password" on View (ir.ui.view). Please contact your system administrator. Operation: read Groups: allowed for groups 'Role / Administrator' Issue: In 9830f77d827c6efeb5f796caac604904350f5a80 the method ir.ui.view()._get_combined_archs was changed to prefetch more fields than before, but prefetching the "visibility_password" field was causing an access error when checking if we had access to it. Fix: prevent prefetching restricted fields. Note: the added test without the fix, fails because of the security warning error, and having the custom view still disabled. opw-4935489
This fixes an issue where users could not add a custom field from the optional columns menu in Knowledge article lists. The change ensures Studio correctly recognizes when the action can be edited, restoring the expected customization flow.
Original PR description
Steps to reproduce ================== - Install knowledge, web_studio - Go to knowledge > Articles - Click on the optional columns dropdown - Click on "Add Custom Field" => This action is not editable by Studio Cause of the issue ================== Since https://github.com/odoo/odoo/pull/205129/commits/c18e93191c516f6e37093f068e8934cba8495891 the event ACTION_MANAGER:UI-UPDATED is triggered before the list renderer has a chance to register for it. Solution ======== We don't actually need to listen to that event to get the info we need. The action xml_id was missing, but it was added in the view subenv config. opw-5066488 Forward-Port-Of: odoo/enterprise#94794
The Point of Sale now applies the same fiscal position tax rules as the accounting backend. This prevents customers from seeing one tax-inclusive price at checkout while the confirmed order shows different tax details later.
Original PR description
If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on…
If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on the order line and the price unit and price with taxes are different (although no tax recorder on the line). Steps to reproduce: ------------------- * Create a fiscal position and assign no tax to it * On the pos config, add this fiscal position and the domestic one to the available fiscal positions * Open pos session * Select a product that has a 15% tax * Change the fiscal position to the one just created > Observation: We still see that the tax is computed based on the 15% * Pay the order * Go see the order in backend > Observation: price unit: 100, no tax, price with taxes 115 Why the fix: ------------ A recent refactoring happened on the accounting side related to fiscal positions: https://github.com/odoo/odoo/commit/9a97157920c845120861dda49d81d3150e015974 https://github.com/odoo/odoo/blob/e284dfd80bde632e6446fc0b8d3276689da35200/addons/account/models/partner.py#L155-L163 The behavior after this refactoring is the following: When changing fiscal position: - If the original tax is available for the fiscal position, we use it - If the original tax is not available but the fiscal position has an available tax that is set to be replacement for the original one, we use the replacement tax - If the original tax is not available but the fiscal position has an available tax which is NOT a replacement for the original one, we keep the original one - If the fiscal position has no tax available, we remove the tax In this fix we apply the same logic inside the pos. Without the fix we would keep the original tax in the frontend but when passed in the backend the tax with fiscal position was recomputed with the logic from accounting. This explained the difference we observed. opw-4978056 Forward-Port-Of: odoo/odoo#223164
Brazilian service invoices using Avatax now clear taxes before calculating installment details. This prevents invoice rejection caused by mismatched installment and line totals, helping affected invoices process correctly.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95269 Forward-Port-Of: odoo/enterprise#85108
This update makes Odoo IoT boxes more reliable during upgrades and startup, preventing blank screens after checkout and avoiding future connection issues. It also ensures the IoT box remains reachable on the network and can correctly switch to the intended Odoo version.
Original PR description
This PR is made of 3 small commits: - `[FIX] iot_drivers: fix blank homepage after checkout` Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can…
This PR is made of 3 small commits: - `[FIX] iot_drivers: fix blank homepage after checkout` Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can end up with the old Python code running but the updated JS code loading in the browser. This can lead to a blank screen as a traceback occurs trying to read the MAC address. We fix this in two ways: - A quick fix, which is just making the JS code robust to the missing value to avoid crashing. - A proper fix that will require a new image, as it modifies the `odoo.service` file to add `rc-local.service` as a dependency. This means Odoo will not start until `rc.local` has finished executing. - `[FIX] iot_box_image: set http_interface explicitly` From Odoo 19.0, a warning is logged when your `http_interface` config setting is not explicitly set. From Odoo 20.0, the default value will change from `0.0.0.0` to `127.0.0.1`, which would break the IoT box as it would only listen to localhost requests. To fix this we explicitly set the `http_interface` value to `0.0.0.0` in `odoo.conf` so that the IoT box will listen to all requests. - `[FIX] iot_drivers: use FETCH_HEAD when checking out` The current 25.07 IoT box image cannot checkout to 19.0 databases due to an issue where the `git reset origin/19.0 --hard` command fails. In the other places where we use `git reset` in the IoT box this was fixed by using `FETCH_HEAD` (an alias for the last branch that was fetched). In this commit we apply the same fix to the `upgrade.py` checkout. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The online shop price range filter now uses the corrected search term when a customer's query is automatically matched to a similar product term. This keeps price filtering available and accurate after typo-tolerant searches, improving the shopping experience.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545
Forward-Port-Of: odoo/odoo#228203
Forward-Port-Of: odoo/odoo#226059Sales order invoiced amounts are now calculated using only real invoice lines, excluding section headers and note lines. This prevents display-only content from affecting financial totals, keeping sales reporting aligned with accounting behavior.
Original PR description
When computing the invoiced amount for a SO, ignore the invoice's lines of `display_type` equal to `line_note` and `line_section` This matches the accounting features which always ignore such lines. **Current behavior before PR** Method `_get_sale_order_invoiced_amount` includes display lines. **Desired behavior after PR is merged** Method `_get_sale_order_invoiced_amount` ignores display lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228146
This fix prevents an error when users open sale order line details from a product form that includes invoice lines. It improves stability for customized product and sales workflows, especially when using Studio-created related views.
Original PR description
…in a dialog Steps to reproduce ================== Prerequisites: Having a product with an SO and an Invoice confirmed. Steps: - Open Product Variant Form - Open Studio - Add new O2M to SOL: Product (Sale Order Line) - Edit subview form - Add invoice_lines - Quit Studio - Click on SOL on Product view → It crashes => TypeError: can't access property "context", ctx.env.searchModel is undefined Cause of the issue ================== In form view dialogs, we don't have a search model Solution ======== We should use the context from the current record opw-4921186 Forward-Port-Of: odoo/enterprise#95259
Czech VAT return entries without a partner VAT number are now consistently reported in section A5, regardless of invoice amount. Entries under special VAT regimes for travel services or margin schemes are also placed in A5, improving compliance with Czech reporting rules.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787 Forward-Port-Of: odoo/enterprise#92833
Customers who add items without choosing a pickup point will now have the checkout page's default pickup location properly applied. This prevents confusing checkout failures where a visible pickup location appeared selected but the order could not proceed to payment.
Original PR description
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user…
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values. This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case. [This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it. Refactored the test cases to avoid the redundancy in the setup process. Steps to reproduce on runbot: 1. Set the pick up in store as the default delivery method by updating the sequence 2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here 3. Go to the cart and click checkout 4. The default pickup location will be set here 5. Click on Confirm 6. An error will appear saying the location was not set opw-4954187 [This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227826