Thursday, November 13, 2025
40 changes · 19.0
Enhancements to existing features
The website generator now verifies a website URL before sending a request to create a site. This helps block invalid or blocked addresses early, reducing unnecessary processing and avoiding failed scraper attempts.
Original PR description
This PR adds the client side verification of an url for the request we make to generate a website using the website scraper. **The goal is to filter all the unwanted requests (invalid urls, banned urls) before launching the scraper process.** The check is done on the IAP server, and retrieved on the DB. The reason is that we don't want to send a request directly from the db [as this was already discussed](https://github.com/odoo/enterprise/pull/92724). Since the IAP server is also the one that will eventually do the scraping request, it also makes more sense that it is the one to check (to avoid the case where odooDB has access to an URL and IAP server does not).
We removed the warning that compared HSN codes with product type, and now the product type is inferred directly from the HSN. This reduces unnecessary alerts during invoicing while still stopping invoices when the HSN is missing or invalid, helping users complete entries more reliably.
Original PR description
With this **PR**, we remove the warning about mismatches between HSN code and product type. From now on, the product type will be derived directly from the HSN code: if the HSN starts with '99', it will be considered a 'service'; otherwise, it will be treated as 'goods'. This simplifies the user experience by reducing unnecessary warnings. This will also cover cases where the product is service but the HSN is of goods for e.g. Job Work, Discount Line etc. Additionally, invalid/missing HSN on invoice line will now raise a blocking warning. **task**-5061450 Community PR - https://github.com/odoo/odoo/pull/227879
This update makes Indian invoicing easier by removing confusing HSN mismatch warnings and automatically determining whether an item is goods or a service from its HSN code. It also enforces required HSN entries and automatically shortens overly long product descriptions for e-invoicing and e-waybill submissions, helping avoid file rejection while alerting users when changes are made.
Original PR description
**[IMP] l10n_in_*: streamline HSN warnings** - With this PR, we remove the warning about mismatches between HSN code and product type. From now on, the product type will be derived directly from the…
**[IMP] l10n_in_*: streamline HSN warnings** - With this PR, we remove the warning about mismatches between HSN code and product type. From now on, the product type will be derived directly from the HSN code: if the HSN starts with '99', it will be considered a 'service'; otherwise, it will be treated as 'goods'. This simplifies the user experience by reducing unnecessary warnings. This will also cover cases where the product is service but the HSN is of goods for e.g. Job Work, Discount Line etc. - Additionally, invalid/missing HSN on invoice line will now raise a blocking warning. **[IMP] l10n_in_*: truncate product descriptions for e-invoicing** - Product descriptions in invoice lines must comply with character limits for e-invoicing and e-waybill: - E-invoicing: maximum 300 characters - E-waybill: maximum 100 characters for both product names and descriptions - Descriptions exceeding these limits are automatically truncated in the generated JSON. A user alert is displayed during sending to notify about any truncation. **task**-5061450 Enterprise PR - https://github.com/odoo/enterprise/pull/95108
The Point of Sale screen now shows a "force done" option when a payment line gets stuck waiting for a terminal response. This helps cashiers keep serving customers instead of being blocked by an unresponsive payment device.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user. Forward-Port-Of: odoo/odoo#235244
Resolved issues and error corrections
Live chat windows will now only auto-open for people who are actually part of the conversation. This prevents unrelated agents from being interrupted by chats they are not responsible for, while still keeping the right people alerted when action is needed.
Original PR description
Before this commit, when live chat had new messages, all agents including non-members had auto-open of chat window when conversation is not in chat hub. This is meant to make agent active or assigned to conversation to be explicitly aware of conversation and action is needed. However non-members should not have auto-open of chat window since their are not liable. This commit fixes the issue by limiting the auto-open of chat window of livechat on new message for users that are member of conversation.
Editing a message with line breaks now keeps the full original content, including the first line. This fixes a display and saving issue that could cause part of a message to disappear after edits.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/231004 Before this commit, when editing a message with at least 1 line, the 1st line was removed after edition. Steps to reproduce: - type message with…
Follow-up of https://github.com/odoo/odoo/pull/231004 Before this commit, when editing a message with at least 1 line, the 1st line was removed after edition. Steps to reproduce: - type message with line breaks: ``` line1 line2 line3 ``` - posts message - start editing of message - add "edit" in its own line in-between line1 and line2: ``` line1 edit line2 line3 ``` - save the edition => message saved has lost the 1st line. The resulting message is: ``` edit line2 line3 ``` This happens because message with line breaks are formatted with `<br/>`: ``` line1<br/>line2<br/>line3 ``` When message is edited with new content: ``` line1<br/>edit</br>line2<br/>line3 ``` The resulting content was: ``` <br/>edit</br>line2<br/>line3 ``` This happens because the html of body has no wrapped tag and consists of just text nodes joined by `<br/>`. While client-side DOM would say each `<br/>` are children (and text nodes are not), the `etree` lib that is used to parse the html has different definition of children: ``` <br/>edit # 1st child <br/>line2 # 2nd child <br/>line3 # 3rd child ``` Parsing of body as html is used to insert the "(edited)" label at the end, attempting to insert in the last children for having the label inline to text content otherwise at the end. When producing the resulting body with "(edited)" label, only the children were joined. Therefore the resulting body was produced: ``` <br/>edit</br>line2<br/>line3<span.o-mail-Message-edited/> ``` Where the `.o-mail-Message-edited` represents the "(edited)" that is rendered on template for translation and style. `line1` is missing because this is not a child: this is text content before the 1st child. This `line1` should still be present in resulting string. This commit fixes the issue by adding missing `tree.text` to the resulting message body with "(edited)" label, which is the text content that is present before the 1st child, i.e. the `line1` in example above.
This update fixes how Swiss bank transfer files are generated so they match the bank’s expected XML structure. It prevents files from being rejected by banks that do not yet support the newer payment format, while keeping the previous behavior only when explicitly enabled.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542 Forward-Port-Of: odoo/enterprise#99005 Forward-Port-Of: odoo/enterprise#98918
This update prevents the website editor from showing an error when someone presses Delete without an active text selection. It improves stability during normal editing, especially when working with embedded content like videos.
Original PR description
If the selection of the document is not set and the user presses the delete key, the delete handler of the list plugin throws an error. Steps to reproduce (in 19.0, where the issue was discovered): - Open website builder - Drop the video inner snippet in the header - Double-click & drag from the video to just outside the video - Click once on the video - Press "delete" - Bug: Traceback task-5186954 Forward-Port-Of: odoo/odoo#232643
This update corrects spreadsheet input styling so missing or invalid fields are always shown clearly. It also prevents dark mode styling from unintentionally changing the spreadsheet layout, keeping the interface consistent and easier to use.
Original PR description
Following the style revamp of the o-spreadsheet lib, we introduced a class o-input (differs from odoo o_input) in order to avoid collision with the odoo classes which tend to be altered in dark mode which spreadsheet does not support. However, we still relied on the default behaviour of odoo classes to mark specific inputs as invalid or missing. This commit ensures that missing/invalid are always marked as such while make preventing the dark mode to break the default layout. Task-4878174 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#235236 Forward-Port-Of: odoo/odoo#234517
The product markup used for search engines now follows the website’s tax display setting, so it matches the price customers see on the shop page. This avoids inconsistencies between the visible price and the structured data used by search engines.
Original PR description
## Version
18.2+
SEO Schema refactoring from task-3866937
## Issue
The markup always contains the price without taxes, no matter the website settings for pricing display (with or without taxes).
## Steps to reproduce
- Go to Website settings:
- Choose "Taxes Included" for "Display Product Prices".
- Got to the shop and select any product on which taxes apply (e.g. Customizable Desk):
- Open console and execute `JSON.parse(document.querySelectorAll('[type="application/ld+json"]')[1].innerHTML)[0]['hasVariant'][0]['offers']['price']`;
- The found price and the displayed price (visible on the page) are different
## Fix
Allow tax inclusion based on parameter to mimic template's behavior on variants too depending on the website.
https://github.com/odoo/odoo/blob/52a6d88a188d5456262428847aed229f117da8ed/addons/website_sale/models/product_template.py#L377-L430
opw-4923780
Forward-Port-Of: odoo/odoo#235106
Forward-Port-Of: odoo/odoo#225577This update fixes an issue in BACS batch files where certain payment amounts could be written with the wrong pence value because of rounding errors. It ensures the exported amount matches the actual payment, preventing incorrect bank instructions.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
The website builder’s dropdown for selecting related options now correctly shows the full set of available choices when changing a selection. This fixes a filtering issue that could hide one of the expected options, making it easier for users to edit visibility settings without confusion.
Original PR description
With the initial [website builder refactor], only 4 options appeared in the `many2x` dropdown when user try to re-select. This commit fixes the issue so the dropdown now fetches all required options through passing domain in rpc call instead of filtering after rpc call this makes sure we only fetch required data by avoiding already selected ids. Steps to Reproduce: 1. Open the website builder. 2. Drop any snippet onto the page. 3. Set the visibility option to conditionally. 4. In the UTM medium dropdown, select any social media option. 5. Try changing the selection again. 6. Only 4 options are shown. Expected: Dropdown should always display 5 options. [website builder refactor]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 Forward-Port-Of: odoo/odoo#227383
This change corrects how inventory valuation is recorded when a subcontracted product is delivered by drop shipment. It prevents the system from leaving behind stock value that could distort future cost calculations, especially for products using FIFO pricing.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644 Forward-Port-Of: odoo/odoo#234573 Forward-Port-Of: odoo/odoo#233041
This change corrects how attachments are linked when sending messages and emails, so files are attached to the right records more reliably. It helps prevent attachments from being filtered out incorrectly during common workflows like mail templates, invitations, and scheduled messages.
Original PR description
Description of the issue/feature this PR addresses: Because `_search` is used, we need to set the context to ignore that added search filter. 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 prevents PDF attachments from being included in Turkish e-invoice payloads sent to Nilvera. It resolves failed submissions for invoices that were generated before being sent through the integration, improving reliability for customers using this e-invoicing format.
Original PR description
## Description of the issue/feature this PR addresses: Nilvera rejects E-Invoices if the PDF attachment of the invoice is included in the XML payload. ## Current behavior before PR: When an e-invoice XML is generated, it correctly follows the UBL 2.1 standard, which includes the PDF as an attachment. However, when the user later tries to send this XML to the Nilvera integration, the request fails because Nilvera does not expect the PDF attachment in the payload. ## Desired behavior after PR is merged: After this fix, if the Customer's e-invoice format is set to **Türkiye (UBL TR 1.2)**, the PDF attachment will be skipped during the XML generation to ensure compatibility with Nilvera. task-5169400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents a timing issue in Knowledge where an article could fail to open correctly after reorganizing items in the sidebar. As a result, users should now see the expected article stay selected and displayed, making editing flows more reliable.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
When users select several transaction lines and create a statement from the list view, the starting balance is now computed correctly. This fixes a mistake caused by missing line references after a prior interface refactor, so the displayed figures are accurate again.
Original PR description
When selecting multiple lines and doing a statement in the list view. The balance start was wrong because the computation relies on the active_ids that wasn't correctly filled. The reason is that during the refactoring: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 We actually remove a custom widget allowing to pass the active_ids. task-5245426 Forward-Port-Of: odoo/enterprise#99013
Opening Studio from a calendar view now works even when the calendar is based on a field that has grouping rules. Previously, this could cause a crash; the fix ensures the view opens normally and improves reliability for users customizing calendars.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#99254 Forward-Port-Of: odoo/enterprise#98903
The stock report now shows the correct total value and average cost when a specific warehouse is selected. This fixes a mismatch where quantities were filtered by warehouse, but their value was still calculated for all warehouses combined.
Original PR description
### Steps to reproduce: - In the settings enable "Multi-steps routes" - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Create a new storable product with…
### Steps to reproduce:
- In the settings enable "Multi-steps routes"
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse
- Create a new storable product with a product category:
- Costing Method: AVCO
- Inventory Valuation: Perpetual
- Change the cost of your product to 10 and put:
- 10 units in the stock of WH1
- 1 unit in the stock of WH2
- Inventory > Reporting > Stock
- Select WH2 in the left panel filter
#### > The total value is still 110 and avg cost is 110.
### Cause of the issue:
Selecting warehouses on the left panel of the report alters the context to set a `warehouse_id`:
https://github.com/odoo/odoo/blob/16dc62e9a14f84b4953fb9b39e4ad71ec454faff/addons/stock/static/src/views/search/stock_report_search_panel.js#L23-L26
https://github.com/odoo/odoo/blob/16dc62e9a14f84b4953fb9b39e4ad71ec454faff/addons/stock/static/src/views/search/stock_report_search_model.js#L37-L45
However, while the `qty_available` of the product is context dependant:
https://github.com/odoo/odoo/blob/16dc62e9a14f84b4953fb9b39e4ad71ec454faff/addons/stock/models/product.py#L146-L150
The methods used in the `_compute_value`to compute the corresponding values corresponding to this qty are not:
https://github.com/odoo/odoo/blob/16dc62e9a14f84b4953fb9b39e4ad71ec454faff/addons/stock_account/models/product.py#L137-L160
opw-5181954
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue that could block employees from activating an expense card. The card setup now handles missing or already-set language preferences safely, so activation completes without an error.
Original PR description
Currently an error occurs when user tries to activate a stripe card. Steps to replicate: - Install `hr_expense_stripe_demo`, `l10n_be`, and `hr_payroll` with demo data. - Use ngrok to portforward…
Currently an error occurs when user tries to activate a stripe card. Steps to replicate: - Install `hr_expense_stripe_demo`, `l10n_be`, and `hr_payroll` with demo data. - Use ngrok to portforward localhost to the public internet and open the link. - Switch to My Belgian Company. - `Settings > Expenses > Expense Card > Agree to T&C > Save > Click Connect`. - Select `Use Test Phone Number > Use Test Code > Save For Later`. - Create a new Employee named `Test` and click `Create User` (provide an email). - Under the `Personal` tab, set the value for the `Payslip Language` field. - Go to `Expenses > Cards > New`, assign Cardholder as `Test`, and save. - Click `Activate`, fill in the required fields, and save. - The error will appear. Error: `KeyError: False` Cause: - The error occurs because line [1] attempts to remove the `False` item from the `preferred_langs` OrderedSet. - Line [1] was added as a guard to remove any `False` value from `preferred_langs`, this occurs when an employee has no language set and hence it will be assigned as False. - However, if the employee has a language selected, there is no `False` value in the `preferred_langs` set, causing line [1] to raise a `KeyError: False`. Solution: - Using the python method `discard()`, we can safely remove any False value and function wont raise any error if False is not found in the `preferred_langs` OrderedSet. [1]: https://github.com/odoo/enterprise/blob/e1d8b1316ce822055a1b42c7f5893cfd1a3dd8a5/hr_expense_stripe/wizard/hr_expense_stripe_cardholder_wizard.py#L176 sentry-6975780020
This update corrects how global filter values are converted inside spreadsheets. It prevents Excel exports from failing when filter data is prepared in the wrong shape, so exports should now complete reliably.
Original PR description
The helper `getFilterCellValue` would sometime returning POJOS, sometimes a matrix of POJOs. This made the excel export crash, as it expected a matrix. Task: [5153124](https://www.odoo.com/web#id=5153124&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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
The bank reconciliation screen now keeps showing reconciliation model buttons and partner counts when users move through paginated records. This fixes an issue where these details disappeared after the first page, helping users reconcile transactions without interruption.
Original PR description
Issue: when navigating through paginated records in the bank reconcilliation widget the functions `computeReconcileLineCountPerPartnerId` and `computeAvailableReconcileModels` were not re-executed. This caused reconciliation model buttons and partner counts to disappear on pages after the first. steps to Reproduce: 1 - In a database with >80 records to reconcile and pre-existing reconciliation models: 2 - Go to Accounting -> N to reconcile button. 3 - In Kanban view expand a record to view reconciliation model buttons (displays correctly). 4 - Navigate to the next page. - From the second page onward, reconciliation model buttons and partner counts are not displayed. fix: on top of the `onWillStart` hook, which runs at the view is first rendered, I added `onRootLoaded` to ensure computations run whenever the dependencies change, updating the widget correctly on pagination. opw-5083877 Forward-Port-Of: odoo/enterprise#98127
This change fixes an issue where some redirect URL fields could appear empty and show no suggestions when creating a new website rewrite. The update ensures the needed route data is generated correctly, so users can pick a URL as expected.
Original PR description
Since commit: https://github.com/odoo/odoo/commit/5ef007a2116e528b796ebe80fb291ba5f1a94c8f#diff-6b066af44f014202eb84d27b3eb63c8aee3e7643e6f814dd4169d0940d763536 _search_display_name is not getting…
Since commit: https://github.com/odoo/odoo/commit/5ef007a2116e528b796ebe80fb291ba5f1a94c8f#diff-6b066af44f014202eb84d27b3eb63c8aee3e7643e6f814dd4169d0940d763536 _search_display_name is not getting called, the reason is when name_search is called with blank value then domain [('display_name', 'ilike', '')] is converted to [(1, '=', 1)] so _search_display_name is not getting called, this only happens when name_search is called with blank value.
The website.route have overridden _search_display_name where we have logic to generate website routes by calling refresh method.
steps to produce: Go to Website -> Redirects -> Create new Rewrite Then select Action = '308 Redirect / Rewrite' and then click on URL from field you will get blank result, dropdown will not have anything.
The reason is name_seach is called with blank value and hence domain is ultimately converted to [(1, '=', 1)] and due to this _search_display_name is not getting called, as refresh method is called from _search_display_name so it will not be called.
With this commit, we have implemented name_search instead of _search_display_name for this special case where we are generating database records when result is blank.
Task-5159334
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 refreshes Odoo’s spreadsheet component to the latest version, bringing several bug fixes and performance improvements. It helps prevent chart crashes, improves handling of filters and special sheet names, and makes spreadsheet interactions feel smoother and more reliable for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/18ac688d1 [REL] 19.0.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/18ac688d1 [REL] 19.0.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f172166e7 [FIX] TopbarMenu: specify `isReadonlyAllowed` [Task: 5245432](https://www.odoo.com/odoo/2328/tasks/5245432) https://github.com/odoo/o-spreadsheet/commit/f548e0337 [FIX] range: invalid sheet name with special character [Task: 5125762](https://www.odoo.com/odoo/2328/tasks/5125762) https://github.com/odoo/o-spreadsheet/commit/f3ddc9d59 [FIX] composer: set editionMode to inactive when composer is unmounted [Task: 5149215](https://www.odoo.com/odoo/2328/tasks/5149215) https://github.com/odoo/o-spreadsheet/commit/a36de18d0 [FIX] filter menu: truncate long filter values [Task: 5219611](https://www.odoo.com/odoo/2328/tasks/5219611) https://github.com/odoo/o-spreadsheet/commit/93ba425db [FIX] chart: add placeholder for axis title input [Task: 5187080](https://www.odoo.com/odoo/2328/tasks/5187080) https://github.com/odoo/o-spreadsheet/commit/bd19f6c53 [PERF] zones: faster isZoneInside [Task: 5213090](https://www.odoo.com/odoo/2328/tasks/5213090) https://github.com/odoo/o-spreadsheet/commit/9f2fb3c22 [PERF] Renderer: speed-up box generation [Task: 5213090](https://www.odoo.com/odoo/2328/tasks/5213090) https://github.com/odoo/o-spreadsheet/commit/108241aef [FIX] charts: crash when converting empty chart to scorecard/gauge [Task: 5181741](https://www.odoo.com/odoo/2328/tasks/5181741) https://github.com/odoo/o-spreadsheet/commit/126d89eb8 [FIX] charts: fix zoomable scatter chart [Task: 5143146](https://www.odoo.com/odoo/2328/tasks/5143146) https://github.com/odoo/o-spreadsheet/commit/7ecb6f3fd [IMP] tests: add zoomable chart plugin tests [Task: 5143146](https://www.odoo.com/odoo/2328/tasks/5143146) https://github.com/odoo/o-spreadsheet/commit/4e3d5cb7a [MOV] tests: move zoomable chart tests to a dedicated folder [Task: 5143146](https://www.odoo.com/odoo/2328/tasks/5143146) https://github.com/odoo/o-spreadsheet/commit/f2afcc63c [FIX] Package: update owl to 2.8.1 [](https://www.odoo.com/odoo/2328/tasks/) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Searching records through a user's linked employee could fail when the system checked employee details the user is not allowed to access. This update makes that search work correctly again, so task and employee filters return the expected results.
Original PR description
Searching tasks with domain `user_ids.employee_id.department_id` is failing because of access rights to the `hr.employee` model. There are multiple issues: First a hack is present to cast a Domain to a list. This was required because the same domain object was used for both `hr.employee` and `hr.employee.public` and was not supported in early versions of the Domain object. This is no longer needed, so we can remove it. Then the search fails on searching `res.users.employee_ids`. On user model, `employee_id` is translated into a `employee_ids`. Then `department_id` is an inherited field, so it gets transformed into a search on `current_version_id`. However since the user does not have access to `hr.employee`, we run that search on the public model which does not have a `current_version_id` field! We remap that condition to a condition on 'id' which will be simplified. task-5259549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change stops tax records from being created twice when tax templates are initialized for branch companies. It ensures taxes are only loaded for the main company, which helps keep accounting setup consistent and avoids duplicate entries.
Original PR description
Adds parent_id check on the domain to ensure taxes are only loaded for root companies. This prevents duplicate tax creation on branch (child) companies when initializing tax templates. task-5176333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233818 Forward-Port-Of: odoo/odoo#232679
This update fixes an issue where an already saved payment method could no longer be selected when registering a payment for an invoice. It ensures the system looks for payment methods linked to either the company or the invoice contact, so customers can keep using previously stored payment details without interruption.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order for a company partner; 2. create & copy a payment link; 3. open payment link in new session; 4. using demo provider, make the payment & save payment details; 5. add an invoice address to the company partner; 6. create an invoice for the company partner using the invoice address; 7. confirm invoice; 8. click "Register Payment"; 9. select "Demo" as payment provider. Issue ----- The saved payment token cannot be selected. Cause ----- Before commit 75f4008, the company partner was used to search for tokens in the payment register wizard. After the commit, the the invoice partner is used, making it impossible to select previously accessible payment tokens. Solution -------- Search payment tokens linked to either partner. opw-5193718 Forward-Port-Of: odoo/odoo#235368 Forward-Port-Of: odoo/odoo#234173
When a user deletes a rating-related message, the rating summary cards on the page are now updated immediately. This keeps the displayed feedback accurate in portal and website views, avoiding stale ratings after a removal.
Original PR description
*: portal, portal_rating, website_slides PR #221050, makes it possible to properly remove a message in the portal and PR #216044 retrieves the rating cards feature. There is an overlap between what these two PRs do. When a user removes a rating message and there is a rating cards feature on the page, it should be updated. Most of the remove method changes are indeed what we did in forward port of #221050 (#222517). task-5106543 Forward-Port-Of: odoo/odoo#235137 Forward-Port-Of: odoo/odoo#224258
This change prevents an error when approving time off for employees who do not have a working schedule. The system now uses the employee’s own time zone as a fallback, so leave validation completes normally instead of failing.
Original PR description
Currently, if we try to validate a leave for a fully flexible employee (employee without a working schedule), we get a traceback when fetching the timezone from the working schedule. To rectify this issue, we default to the timezone of the employee. Forward-port of https://github.com/odoo/odoo/pull/222634 opw-5253846
This change prevents marketing automation activities from crashing when a duration or interval value is cleared. It keeps the activity summary working smoothly by handling missing values safely instead of raising an error.
Original PR description
Currently, an error occurs when removing the interval type or validity duration type in a marketing automation activity. This happens when the system tries to compute the "Activity Summary", which…
Currently, an error occurs when removing the interval type or validity duration type in a marketing automation activity. This happens when the system tries to compute the "Activity Summary", which expects valid selection values but receives False. **Steps to Reproduce:** 1. Install Marketing Automation. 2. Create a new campaign and click on "**Add new activity**". 3. In the "Trigger" field, remove the duration (e.g., "Hours"). **Error:** `KeyError - False` **Cause:** At [1], it tries to get the label from the selection dictionary using the value of `interval_type` or `validity_duration_type`. When either field is `False`, it causes a KeyError. **Fix:** This commit prevents the error by; - Setting an empty summary when required selection values are missing. - Returning 0 for interval standardized when interval type is not set. [1] - https://github.com/odoo/enterprise/blob/bb92db89d3fc1f654dfdff9b2e334b13d81cb7ab/marketing_automation/models/marketing_activity.py#L228-L229 sentry-6957343166
Rental stock availability is now calculated correctly when part of a rental order has already been returned. This prevents customers from seeing too much stock as available and helps avoid overbooking rented products.
Original PR description
### Issue: Due to this bug, virtual available is not calculated correctly when there are rental orders with some returned lines. #### To reproduce: 1- Create a storable rental product with 10 units in stock. 2- Enable the 'Rental Transfer' setting. 3- Create a rental order with two lines: - line 1: 4 units - line 2: 1 unit 4- Confirm and pick up order lines 5- Return the line with 1 unit 6- Create another order: it must show 6 available but 7 is shown #### Cause: This is caused due to filter on lines in `_get_virtual_unavailable_qty_in_rent` which filters lines with `order_id.rental_status`. However this filter misses the lines which have different status than the `order_id`. In #88689, `rental_status` field is added to `sale_order_line`. Using the `sale_order_line.rental_status`, we can ensure only line with status in `return` and `pickup` are considered. opw-5185084
This update brings back the Save button and the trusted-order behavior in Point of Sale. It restores the intended workflow for stores that rely on approved orders, helping prevent disruptions at checkout and in restaurant operations.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229335 Forward-Port-Of: odoo/odoo#200567
This update prevents an error that could appear when users click on a Bento block in the Website editor. It ensures the block’s border and shadow settings load correctly, improving editing stability and avoiding disruptive tracebacks.
Original PR description
Steps to reproduce: =================== 1- Go to Website → Add a Bento block. 2- Click on the block. → A traceback occurs. Cause: ====== The Bento Border XML references `BorderConfigurator` and `ShadowOption`, but these components were never registered in the `BentoBorderOption` definition. https://github.com/odoo/odoo/blob/43654a2a967cb330d65ae0d163a3436462c12c8c/addons/website/static/src/builder/plugins/options/bento_border_option.xml#L8 Solution: ========= Register BorderConfigurator and ShadowOption as components of BentoBorderOption to ensure proper initialization. opw-5234406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves the point of sale flow when the connection to the blackbox is interrupted during order syncing. If an order could not be signed correctly, it is now returned to draft so the cashier can try again later instead of being blocked by the error.
Original PR description
When trying to sync orders while being offline, a `ConnectionLostError` is raised. This error was not handled in the pos_blackbox_be module. Now, if an order was not signed correctly by the blackbox, we put its state back to "draft", allowing the cashier to retry later (when the connection to bbox is re-established). Forward-Port-Of: odoo/enterprise#98946 Forward-Port-Of: odoo/enterprise#98778
This update corrects the numbering and layout of sale order and invoice reports for German templates. Line numbers now appear on the actual product lines, and section rows are aligned properly, making printed documents easier to read and more consistent.
Original PR description
**BUG 1:** ---- **Steps to reproduce:** - Install `sale_management` and `l10n_de` modules with demo data. - Set the company to a DE company - From setting activate `Show Position Column in Reports`…
**BUG 1:**
----
**Steps to reproduce:**
- Install `sale_management` and `l10n_de` modules with demo data.
- Set the company to a DE company
- From setting activate `Show Position Column in Reports` option
- Create a sale order with multiple products and add some section lines
- Notice that the sequence number only appears on section lines, not on product lines
**Issue:**
- Line numbers are coming to section line instead of product lines in the sale order report.
**Cause:**
- Issue occurs form this [Commit](https://github.com/odoo/odoo/pull/224219/commits/10d349f07ab1852141945775e4acdd26a83670dc)
- The `Xpath` used in the inherited template no longer matches due to changes in the base report structure,
resulting in numbering being applied only to section lines.
**Solution:**
- Update the `Xpath` expression to correctly target the updated template structure
so that sequence numbers are displayed for all sale order lines.
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/75089f85-e942-487d-b097-813fb3fbae59" />
After:
<img src="https://github.com/user-attachments/assets/3049f390-8aff-4493-9030-a0416b925d25" />
</details>
---
**BUG 2:**
----
**Steps to reproduce:**
- Install `sale_management` and `l10n_de` modules with demo data.
- Set the company to a DE company
- From setting activate `Show Position Column in Reports` option
- Create an invoice with multiple products and add some section lines
and print invoice
- Notice that the alignment of the section is misplaced.
**Issue:**
- Notice that the alignment of the section is misplaced — the amount should be
on the right side, below the “Amount” column.
- The same issue occurs in the Sale Order as well.
**Cause:**
- Added one extra column ‘Position’ in the line, but the section doesn’t have it
causing misalignment between the line and section.
**Solution:**
- Added an XPath for the empty column to resolve the position misalignment issue
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/522b0f2c-c18f-4457-aad1-7edc9b23754a" />
After:
<img src="https://github.com/user-attachments/assets/cc771b3c-80d4-4746-8d7e-ad7c57321b32" />
</details>
---
opw - 5147198
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix restores the ability to adjust quantities on transfer lines for tracked products when they are not part of subcontracting. It removes an unnecessary limitation in regular warehouse operations and makes day-to-day stock handling faster and easier.
Original PR description
Issue Before This Commit: ----- - When subcontracting was enabled, users were unable to edit the quantity of traceable products directly on transfer lines, even if those products were not part of any…
Issue Before This Commit: ----- - When subcontracting was enabled, users were unable to edit the quantity of traceable products directly on transfer lines, even if those products were not part of any subcontracting flow. This causes unnecessary limitations in normal warehouse operations. Steps to Reproduce: ----- - Install the `mrp_subcontracting` module. - Create a transfer containing a traceable product (lot/serial tracked). - Confirm the transfer (_Mark as Todo_). - Try to edit the quantity directly on the transfer line. - Notice that the field is non-editable, even though the transfer is not part of a subcontracting process. Cause of the Issue: ----- - The quantity field was made globally read-only for tracked products in this [`PR`](https://github.com/odoo/odoo/pull/220383/files#diff-a5b7491ccd078355b6edcbc19b7f85e3847c65c4f953457dd5e668e86299119cR18-R20). With This Commit: ----- - Users can now edit quantities of traceable products on transfer lines when they are not used in subcontracting. - This helps streamline regular transfer operations by allowing quick quantity adjustments without affecting subcontracting flows. Task - 5169885
When users open a scoped app link, the system now redirects them to the matching page instead of sending them back to the app home screen. This makes app links behave more reliably and preserves the page state the user expected to see.
Original PR description
This commit fixes the '/scoped_app' redirection to '/odoo' without loosing the history state. Previously, when opening a route such as '/scoped_app/discuss', the webclient would use an empty state and redirect to the home screen with '/odoo' instead of redirecting to '/odoo/discuss'. Two tests have been added in router to assert the different redirection behavior when using scoped apps from the browser instead of a standalone app. task-5159471 Forward-Port-Of: odoo/odoo#234946
Orders are now synchronized one at a time instead of in large batches. This reduces the risk of timeouts, lost orders, or incomplete synchronization, especially when orders need extra processing like invoicing. Coupon program confirmation in loyalty is also updated to work correctly with this new flow.
Original PR description
`syncAllOrders` method is now splitting the list of orders to synchronize them one by one. This allows to have better control over each order synchronization and error handling. Some customer were experiencing issues when synchronizing too many orders at once, leading to lost orders or orders not being synchronized properly. For example, synchronizing orders that needs to be invoiced takes too long and can lead to timeout issues. By synchronizing orders one by one, we ensure that each order is properly synchronized before moving to the next one. --- Modification in `pos_loyalty` module to adapt to this change: The `confirm_coupon_programs` method is now called for each order individually, instead of being called once for all orders in the `payment_screen`. This ensures that coupon programs are confirmed correctly for each order even when orders synchronization is delayed Forward-Port-Of: odoo/odoo#234622 Forward-Port-Of: odoo/odoo#232073
This update prevents an error when older payments are added to a payment batch. If a payment was created before a certain migration and was missing its end-to-end identifier, the system now generates one automatically during export so the batch can be created successfully.
Original PR description
…ayments The migration script [1] for the end-to-end feature creates the `end_to_end_uuid` field even when `account_online_payment` is not installed. In such databases, the field is added but remains NULL for existing payments. If these legacy payments are later added to a batch, a traceback occurs because the batch logic assumes that `end_to_end_uuid` is always set [2]. This commit generates a UUID on the fly when exporting a payment whose `end_to_end_uuid` is empty, ensuring that batch creation works correctly even when `account_online_payment` was not installed. [1]: https://github.com/odoo/upgrade/blob/ed83d47b2aaa63113ea86ea83d1ca2c886f60063/migrations/account_iso20022/saas~18.5.1.0/pre-migrate.py#L10 [2]: https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/account_iso20022/models/account_journal.py#L289 no task-id
The Journal Audit report now shows the same draft entries in the list and in the review view. This fixes a mismatch that could make a journal appear to have items to review even when nothing was displayed after opening them, improving reliability for accounting teams.
Original PR description
* In a new journal, create a draft entry * Open the journal audit: Accounting > Review > Journal Audit * Activate the "With draft Entries" option. * The journal should display 1 entry to review * Click on the review button, there is nothing to display We should be consistent in the filters selected is the search view and what is displayed on the report.