Daily updates from Odoo
Wednesday, August 6, 2025
106 changes
38 changes
Resolved issues and error corrections
Payment receipt PDFs now show the real foreign-currency payment amount after reconciliation. This prevents misleading receipts, such as showing 100 Bs instead of 10,000 Bs when a foreign-currency payment settles a company-currency invoice.
Original PR description
**Steps to reproduce**: 1. Install the `accounting` module. 2. Activate a foreign currency form `Accounting -> Configuration -> Currencies` and fetch its exchange rate. <img width="599" height="267"…
**Steps to reproduce**: 1. Install the `accounting` module. 2. Activate a foreign currency form `Accounting -> Configuration -> Currencies` and fetch its exchange rate. <img width="599" height="267" alt="image" src="https://github.com/user-attachments/assets/34e7c719-20f7-4cd0-a1d6-0e94764461ba" /> 3. Create an invoice using the company’s default currency (e.g., USD). 4. Register a payment using the foreign currency (e.g., VES). 5. Reconcile the payment with the invoice. 6. Print the payment receipt PDF. **Observations**: In the printed PDF, under the `Amount In Currency` column, the amount is incorrectly displayed. For example, suppose `1 USD` = `100 VES`. - An invoice of `100 USD` is created. - A payment of `10,000 Bs` is registered (equivalent to 100 USD). - When the payment receipt is printed, the output appears as: ``` | Invoice Number | Reference | Amount In Currency | Amount | |--------------------|-------------------|--------------------|-------------| | INV/2025/00001 | | | 100.00 USD | | PBNK1/2025/00001 | INV/2025/00001 | -100.00 Bs | -100.00 USD | ``` Here, the `Amount In Currency` for the payment line shows **100 Bs** instead of the correct **10,000 Bs**. **Issue**: The payment receipt uses the `_get_reconciled_invoices_partials()` method to fetch details about reconciled invoices. However, the report incorrectly uses the `amount` field (in company currency) for the `Amount In Currency` column, leading to this mismatch. **Solution**: The report now uses `(debit/credit)_amount_currency` instead of `amount` to correctly reflect the foreign currency values in the `Amount In Currency` column. opw-4898706 Forward-Port-Of: odoo/odoo#221964 Forward-Port-Of: odoo/odoo#219439
This update fixes two web editor problems that could disrupt content editing: pasted list items now keep a correct structure, and bold or italic formatting can be removed even when selected text includes line breaks. This makes editing pasted content more reliable and reduces cleanup work for users.
Original PR description
**Current behavior before PR:** **Issue 1:** - Paste a content with multiple `<li>` elements without `ol/ul` tag, each `<li>` having a paragraph element inside. - Try to create a list from these…
**Current behavior before PR:** **Issue 1:** - Paste a content with multiple `<li>` elements without `ol/ul` tag, each `<li>` having a paragraph element inside. - Try to create a list from these elements. - List is created with wrong element structure. The problem occurs because when pasting multiple `<li>` elements without an `<ol>/<ul>` tag, `sanitizeNode` replaces existing `<li>` elements with new `<p>` elements. Since each `<li>` already contains a `<p>`, this results in paragraphs being nested inside other paragraphs. As a result, creating the list from these paragraphs leads to an incorrect structure. **Issue 2:** If there are multiple paragraph selected along with newline character nodes `(\n)`, it is not possible to remove bold or italic format from selected content using toolbar. The issue happens because `isSelectionFormat` method fails to give correct value if traversed nodes contains one or more newline `(\n)` characters. **Desired behavior after PR is merged:** **Issue 1:** Now, if an `<li>` contains a `<p>`, the `<li>` is unwrapped instead of creating a new paragraph, resulting in a correct element structure when creating a list. **Issue 2:** Now, `\n` nodes are filtered from traversed nodes so that format can be removed from selected content. task-4752385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219461 Forward-Port-Of: odoo/odoo#208127
This fix ensures that when users duplicate a pivot table in a spreadsheet, any matching global filters remain applied to the copy. This prevents duplicated reports from showing unfiltered or misleading data and keeps spreadsheet analysis consistent.
Original PR description
Steps to reproduce: - insert a pivot in a spreadsheet - create a global filter matching one of the pivot fields - use the global filter to restrict the values - duplicate the pivot => the filter is not applied on the duplicated pivot Task:4966634 opw-4950469 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#220996 Forward-Port-Of: odoo/odoo#220588
The invoicing dashboard now uses customer credit notes, rather than vendor credit notes, when calculating key sales views such as top countries, categories, products, and salespeople. It also excludes draft and cancelled entries from Top Invoices, making dashboard figures and drill-downs more accurate for business reporting.
Original PR description
Problem:- In Invoicing Dashboard, in some parts we get wrong values because of wrongly set domain making dashboard consider Vendor Credit Note instead of Customer Credit Note. Before this commit:- - In Invoicing Dashboard, reports Top Countries, Top Categories, Top Products, and Top Salespeople considers Customer Invoice and Vendor Credit Note. - When clicked on Top Invoices, moves in draft and cancel state are also displayed. After this commit:- - In Invoicing Dashboard, reports Top Countries, Top Categories, Top Products, and Top Salespeople considers Customer Invoice and Customer Credit Note only. - When clicked on Top Invoices, moves in draft and cancel state are not displayed. task-4851920 Forward-Port-Of: odoo/odoo#222004 Forward-Port-Of: odoo/odoo#213723
The messaging menu now shows the right helper message when a quick search returns no conversations. This prevents users from seeing conflicting messages and makes it clearer whether there are no search results or no conversations at all.
Original PR description
**Steps to reproduce:** - Open the messaging menu with 20+ threads (quick search btn shows on 20+ threads) - Dismiss (or install) the 'Install Odoo' notification - Dismiss (or allow) the 'Turn on notifications' notification - Use quick search to look for a thread that doesn't exist => Both 'No thread found.' and 'No conversation yet...' messages are displayed This happens due to an incorrectly handled condition. This PR ensures only the relevant message is shown: - 'No thread found.' is displayed when the search yields no results. - 'No conversation yet...' is shown only when the user has no threads at all. <img width="565" height="279" alt="image" src="https://github.com/user-attachments/assets/689bc007-dfb4-4041-8543-18bc4ad2e19d" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221878
This fixes an issue where website editors could accidentally edit the shop sorting control and trigger an error when saving the page. The sorting display remains visible, but is no longer editable in the website editor, preventing save failures for shop pages.
Original PR description
Step to reproduce: - install website_sale - open website -> shop page - open editor, by clicking on `Edit` from right corner observation: - you are now able to edit sort by element - on saving, traceback is received. Issue: After odoo/odoo@9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 , we know make every t-field [editable](https://github.com/odoo/odoo/blob/saas-18.4/addons/html_builder/static/src/core/setup_editor_plugin.js#L23-L36), from `SetupEditorPlugin.setup()` when editing a website. This makes `shop_default_sort` field editable, (which is a sequence field) and tries to update its name/value from `ir.qweb.field.selection()` ,raising traceback on save() Fix: Use t-out instead of t-field, to prevent it from being editable opw-4937025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now chooses the correct Paymob payment method when multiple options share the same gateway type. This helps merchants avoid enabling outdated or unsupported Paymob methods, especially for card payments that should exclude MOTO or authorization-only integrations.
Original PR description
Paymob allows for multiple payment methods to have the same gateway type Which one should be enabled on Odoo is determined based on: 1. The most recently created payment method on the user's paymob account 2. For card: Exclude Integration IDs where integration_type = 'moto' or is_auth = true. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small issue in Odoo's shared date utilities was fixed so time values are converted correctly. This helps prevent incorrect duration calculations in features that rely on this common helper.
Original PR description
'time_to_float' method in the date utils is using 'time' to make its computation but 'time' is actually the type of the parameter (datetime.time). Using the actual duration parameter. related PR: odoo/odoo#207882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures a base system view test is included when localization-specific tests run on their own. It helps catch localization-related issues earlier, reducing the risk of nightly build failures after changes are merged.
Original PR description
This test is not run during the l10n standalone tests leading to error in nightly that are not detected before the merge. 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#219473 Forward-Port-Of: odoo/odoo#219376
The Profiling screen no longer allows creating new profiling records that could generate broken Open links before being saved. This prevents users from hitting an error when clicking a profiling report link on an unsaved record.
Original PR description
Currently, the speedscope URL is generates even for unsaved records and clicking this URL resulted in an error. **Steps to reproduce:** - Open Profiling. - Create new Ir Profile. - Without saving the record, click on the speedscope URL in the 'Open' field. **Error:** `ValueError - invalid literal for int() with base 10: 'NewId_0x789d07a57b80'` **Cause:** The `speedscope_url` compute method [1] generated the URL using a temporary `NewId`. When this URL was accessed, the controller [2] attempted to process it as an integer, which resulted in the error. **Fix:** This fix prevents the creation of new `ir.profile` records. [1] - https://github.com/odoo/odoo/blob/679d99b8bd233a1046e3219ddb3e23e8465f6107/odoo/addons/base/models/ir_profile.py#L109-L112 [2] - https://github.com/odoo/odoo/blob/679d99b8bd233a1046e3219ddb3e23e8465f6107/addons/web/controllers/profiling.py#L33 sentry-6753780250
Products received from purchase orders with a 100% discount are now valued at zero instead of using their standard cost. This prevents overstated inventory value and keeps accounting aligned with the actual purchase price.
Original PR description
**Current behavior:** Receiving some real-time valuated, non-standard cost product from an order with 100% discount will value the product at its `standard_price`. **Expected behavior:** Valuated at 0. **Steps to reproduce:** 1 Create an average cost, real-time valuated product with non-zero `standard_price` 2. Create a purchase order for some of the avco product, confirm and receive 3. Create and post the bill -> check valuation from inventory **Cause of the issue:** Currently from 6ba1106ae we will ignore a 100% discount in calculating `_get_gross_unit_price()`. **Fix:** Return 0 in this method if we are in a 100% discount case. opw-4862883 Forward-Port-Of: odoo/odoo#220998 Forward-Port-Of: odoo/odoo#217726
The editor now properly clears empty nested content blocks that could previously remain after users deleted their content. This prevents leftover invisible structure from interfering with editing features and keeps pages cleaner after content removal.
Original PR description
Problem: In some cases, content with nested `div` elements is added to the editor. These `div`s can break certain editor features and cannot be deleted through the UI. Solution: Add support to remove empty `div` elements when clearing content. Steps to reproduce: - Add `<div><div>abc</div></div>` to the editor - Focus inside and remove all content - The `div` elements remain and are not removed opw-4805901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the missing keypad dropdown in the point-of-sale self-ordering flow. It ensures staff or customers can access the expected numeric input options again, avoiding confusion during order entry.
Original PR description
The forwardport https://github.com/odoo/odoo/commit/621bc2ed48ce4e2486f1604fdfe4d85cc4dc179b introduced a `t-if=!isEditMode` that was making the latest `t-else` statement never reached, thus making `NumpadDropdown` never displayed. Therefore, we simply remove the t-if statement and adjust the xpath inherit to place the `QrOrderButton` just before the `NumpadDropdown` button 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#221642
The website editor now hides the irrelevant theme color tab when configuring the map color filter. This reduces confusion and helps users choose the appropriate custom or gradient color settings for map styling.
Original PR description
The "theme" tab does not make any sense with the color filter option since it will generally apply an opaque color. Only the custom and gradient tabs are relevant. This commit removes this tab for the s_map color filter option. task-4367641
This fix ensures Point of Sale automated tests can run correctly without an internet connection. It helps keep development and quality checks reliable in offline or restricted environments, with no direct impact on day-to-day users.
Original PR description
Ensure hoot tests are correctly running offline. rb-error: 229927 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221268
Employees can now access subtasks in private projects when they should have permission to do so. This prevents legitimate project work from being blocked and adds stronger test coverage for the corrected access scenario.
Original PR description
same as https://github.com/odoo/odoo/commit/0d75ce1d3912bbd94c5ce3bc199b40134dfab69f but different field `has_template_ancestor`. the test was fragile and didn't cover the case correctly, it was improved in this commit. opw-4980443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221728
This update corrects a small typo in the website/page builder's internal warning handling. It helps ensure warning messages are recorded properly in the browser console, making troubleshooting more reliable without changing user-facing behavior.
This fix prevents image editing controls from remaining on screen after an image is deleted. It also ensures the crop tool reliably opens after using image transform, reducing confusing editor behavior for users working with images.
Original PR description
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper…
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper still visible. **Issue 2:** - Go to To-Do and insert an image. - Click on Image Transform, then on Image Crop — observe that Image Crop opens correctly. - Click the Discard button in the Image Crop UI. - Again select the image, click Image Transform, then Image Crop. - Notice that Image Crop no longer opens. ### Description of the issue/feature this PR addresses: - Pressing Backspace removes the image from the editor. - However, the cropper remains open, and focus returns to editable area, allowing to type with the cropper still visible. - Clicking Image Crop while Image Transform was active could destroy both due to async loadBundle() timing. On subsequent attempts, ImageCrop was added before ImageTransform was removed, causing Owl to destroy both in the same frame. ### Desired behavior after PR is merged: - When the image is removed, the associated cropper is also closed. - Clicking Image Crop button while Image Transform is active now works. task-4859869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220477 Forward-Port-Of: odoo/odoo#213914
Changing the journal on a payment no longer automatically replaces the selected partner with the journal company's partner. This lets users manually choose the correct partner when adjusting payment journals, avoiding incorrect payment assignments.
Original PR description
Reproducing steps: - Create a payment and select a journal. - Partner is set to the journal's company partner. - Try to change the journal manually. Before this PR: - Partner is reset to the journal's company partner. - Cannot assign a different journal for the journal's company partner. After this PR: - Removed unwanted compute dependency. - Partner is no longer reset and can be changed manually. opw-4769153 Forward-Port-Of: odoo/odoo#221867
Non-admin accounting users can now print Saudi ZATCA invoices without encountering an error. The fix ensures the invoice QR code can be generated despite restricted access to related electronic invoicing attachments, reducing disruption in day-to-day invoicing.
Original PR description
**Steps to reproduce:** 1. Install Accounting and l10n_sa_edi 2. Switch to a SA company 3. Go to Accounting > Configuration > Journals > Sales > ZATCA > Re-onboard 4. Create or duplicate a customer…
**Steps to reproduce:** 1. Install Accounting and l10n_sa_edi 2. Switch to a SA company 3. Go to Accounting > Configuration > Journals > Sales > ZATCA > Re-onboard 4. Create or duplicate a customer invoice > Confirm 5. Click on blue banner "Process Now" 6. Log in as a non-admin user (e.g., Marc Demo) and Switch to a SA company 7. Go to invoice > Open Same invoice > Click to "PRINT" **Issue:** - A traceback is raised when trying to access the attachment linked to the ZATCA document. **Cause:** - Since commit https://github.com/odoo/odoo/commit/44a4cdb3944a4b722dcfbca5e2947a4372b8501d, access to EDI document's attachment (`attachment_id`) is restricted to users belonging to "Role > Administrator" group (`group_system`). - This was introduced as part of changes from Task [#4341594](https://www.odoo.com/odoo/project/49/tasks/4341594) As a result, non-admin users (even with accounting rights) are unable to access the attachment causing a traceback. **Solution:** - Apply `compute_sudo`to field `l10n_sa_qr_code_str` to bypass the restrictive access rights. So even if for any case any other field causes issues in the future, compute_sudo will take care of it **opw-4923399** Forward-Port-Of: odoo/odoo#219820
Changing the product on a sales quotation line now refreshes the price instead of keeping a previously manually entered amount. This helps sales teams avoid incorrect quotation totals when replacing products in an order.
Original PR description
step to reproduce - Create a quotation, - Select a product - Update the price manually - change the product - The amount stays the same expectation: with change of product in SO, price should also recompute issue: currently,`_compute_price_unit` depends on `technical_price_unit` such that `price_unit` won't update if `price_unit` and `technical_price_unit` are not same. which is the case when price_unit was manually set, regardless of the product https://github.com/odoo/odoo/blob/12ef230df58122fbdac0b4c1b4781c535b8516ba/addons/sale/models/sale_order_line.py#L567-L570 we should reset to original price with change of product opw-4813069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219584 Forward-Port-Of: odoo/odoo#213912
Opening a payment link for an unpaid invoice no longer triggers an error caused by an incorrect amount conversion. This helps customers complete invoice payments smoothly without encountering a technical traceback.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Go to Accounting/Invoicing;
2. open an unpaid invoice;
3. generate payment link;
4. open payment link.
Issue
-----
Traceback on a `ValueError`.
Cause
-----
Commit 5697493e00915 added a `amount and float('amount')`, trying to convert a string into a float.
Solution
--------
Convert the variable into a float instead.
opw-4996783
Forward-Port-Of: odoo/odoo#221914This fixes an inventory issue where changing a product's on-hand quantity to zero did not save correctly, causing the previous stock amount to reappear after refreshing. Businesses can now accurately clear stock levels for products without creating unnecessary zero-quantity inventory movements.
Original PR description
<b>Steps to reproduce:</b> 1) Install stocks 2) Create a product variant with storable true 3) Change the on-hand quantity to some positive value and save 4) Now update the on-hand quantity to 0 and…
<b>Steps to reproduce:</b> 1) Install stocks 2) Create a product variant with storable true 3) Change the on-hand quantity to some positive value and save 4) Now update the on-hand quantity to 0 and refresh the page <b>Issue:-</b> The on-hand quantity doesn't update to 0. <b>Cause:-</b> When the user manually changes the on-hand quantity, an inverse method `_inverse_qty_available` is triggered to create a new stock.quant, but because of this condition, no new quant is created. https://github.com/odoo/odoo/blob/b2e845c46a0b152899ee630770abc15751493069/addons/stock/models/product.py#L236-L238 As a result, the qty_available value will remain same because it will be updated based on the stock.quant's record from the below line. https://github.com/odoo/odoo/blob/b2e845c46a0b152899ee630770abc15751493069/addons/stock/models/product.py#L185 https://github.com/odoo/odoo/blob/b2e845c46a0b152899ee630770abc15751493069/addons/stock/models/product.py#L217 <b>Solution:-</b> We can resolve this issue by modifying the condition in the inverse method to create a new stock.quant if the on-hand qty is 0 or more. Also skip creating a SM with 0 quantity when applying inventory from `_inverse_qty` opw-4761491 Forward-Port-Of: odoo/odoo#208739
The DHL delivery integration now sends commodity code information using the field name expected by DHL's API. This helps avoid shipment creation issues caused by rejected or misread customs data.
Original PR description
Changed the field name in commodityCodes from `code` to `value` to match with DHL API documentation. Check ticket log notes for details of DHL documentation. opw-4892324 Forward-Port-Of: odoo/enterprise#91645
The accountant test tour now waits for the page to settle before clicking key buttons. This reduces intermittent failures during statement creation and helps keep automated checks stable.
Original PR description
Steps --------- 1. Install account 2. Run the following test-tags `.test_accountant_tour` Problem --------- Sometimes, the tour fails in the statement creation step because the "New" button is not correctly pressed. The error does not always occur. Solution --------- Adding some intermediary steps so that the page settles before pressing on buttons. build-error-226436 Forward-Port-Of: odoo/enterprise#91785
This fixes a test failure that could occur when the Accountant app is not installed. It improves reliability of the accounting batch payment test suite without changing business functionality.
Original PR description
**Issue:** "test_partner_account_batch_payments" test may fail when "accountant" module is not installed. **Solution:** Handle the case when "accountant" module is not installed separately as it is done in previous versions. runbot-230480 Forward-Port-Of: odoo/enterprise#91621
This fix ensures that when receiving serial-numbered products in the Barcode app, removing scanned lines targets the correct serial number. It prevents valid serial numbers from being incorrectly marked as already used, reducing receiving errors and rework for warehouse teams.
Original PR description
Steps to reproduce: - Install Purchase, Stock and Barcode apps - Create a product tracked by serial number - Create a PO of this product and confirm it (demand 3) - Open Barcode application for the PO's receipt - Start entering serial numbers for the 3 products - For each line, use the decrement button and remove all 3 lines - Make sure the last removed line is not the first scanned serial - Re-enter the serial number of the last removed line Issue: The parent line of the 3 sublines has the lot_name fixed on the first scanned serial_number. So when decrementing the last_line, it will always use the virtual_id of the first serial_number scanned, leading to decrementing the wrong serial number. It starts showing that the next scanned number is already used, because it wasn't properly removed in the first place. opw-4646765 Forward-Port-Of: odoo/enterprise#88966 Forward-Port-Of: odoo/enterprise#88130
Fixes an issue in Documents where changes made to a folder from the details panel could fail to appear immediately in the search panel or briefly show outdated information. This keeps folder names and related navigation details accurate after users save changes.
Original PR description
Something changed in 18.4 (fw or documents) such that we * sometimes we didn't trigger a reload of the search panel after modifying a folder * sometimes the reload of the searchpanel was triggered *before* the initiation (and return) of the write call, so the search panel was updated with the old values Note that this asynchronous misbehavior was not easily visible in hoot tests, but the call count enables to highlight the problem (and drive a suitable solution). The fix is actually an opportunity to keep reloading the search panel on update inside `update` (i.e., saving) flows. Also last style cleanups in documents_details_panel.js. Task-4992298
Searching for loans in the Loan Analysis view now uses the correct loan label field. This prevents users from seeing an error when looking up loan records and makes the analysis view usable again.
Original PR description
Behaviour before this commit: While searching for 'Loan' in the Loan Analysis view, a traceback appears since the filter_domain for the search is on `name` but `name` is not present in account.loan.line, instead it is `loan_name`. Desired behaviour after this commit: The filter_domain for 'Loan' is updated to search for `loan_name` instead of `loan`, and domain for `display_name` is removed. TaskID:4991369 Forward-Port-Of: odoo/enterprise#91637
Users with the proper Sign permissions can now cancel sign requests linked to salary package offers without being blocked by an unrelated access error. This prevents administrative sign workflows from getting stuck when the user does not have direct access to salary offer records.
Original PR description
After this commit https://github.com/odoo/enterprise/commit/40d3314d1b06c8110b476690d2264e86b3492b3e we are not able to cancel a sign request, if user do not have read/write access on…
After this commit https://github.com/odoo/enterprise/commit/40d3314d1b06c8110b476690d2264e86b3492b3e we are not able to cancel a sign request, if user do not have read/write access on `hr.contract.salary.offer` model **step to reproduce:** - install `hr_contract_salary` - create a new user with following right: `Sign -> Administrator` `Contracts -> Employee Manager` `Recruitment -> Interviewer` - login with test user - open sign -> All Documents (with demo data 2, there should be 2 documents) - try to cancel one of them <img width="1572" height="689" alt="config for user" src="https://github.com/user-attachments/assets/72e89ac7-fed3-4a38-918f-5dbb198bd1e3" /> **Observation:** - even with Admin rights of Sign, we are not able to cancel a sign request and we receive a Access Error `You are not allowed to access 'Salary Package Offer' (hr.contract.salary.offer) records` **Fix:** we use `sudo()` to allow everyone to cancel their sign request opw-4859774 Forward-Port-Of: odoo/enterprise#91471 Forward-Port-Of: odoo/enterprise#89865
This change fixes incorrect asset depreciation schedules for imported assets when prior software used different depreciation amounts. It prevents Odoo from carrying unexpected differences into future periods while preserving corrected remaining and depreciated value calculations.
Original PR description
This reverts commit 79aa48867de14a6d2315ec95b271004084d74b14. A lot of customers reported that the data was wrong in a lot of cases. For instance, when the previous software computed a lower depreciation than Odoo, Odoo was then moving the difference into the next period. The change for the computation of `asset_remaining_value` and `asset_depreciated_value` has been kept. opw-4968367 opw-4977970 opw-4961381 opw-4991216 opw-4965451 Forward-Port-Of: odoo/enterprise#91751 Forward-Port-Of: odoo/enterprise#91723
Bank reconciliation now preserves the original foreign currency amount when recalculated values are close enough, avoiding tiny rounding differences caused by exchange-rate precision. This helps prevent valid invoices from showing incorrect residual differences, such as a one-cent mismatch, during accounting reconciliation.
Original PR description
The aim of this commit is to keep the original foreign amount currency if the computation ends up close enough to it. Before this commit: The reconciliation process was losing so much precision that…
The aim of this commit is to keep the original foreign amount currency if the computation ends up close enough to it. Before this commit: The reconciliation process was losing so much precision that it could mess up the reconciliation of one single invoice. After this commit: We keep the original amount as it is most probably the correct one. Context: With a rate of 1 US$ = 5.421327349 R$ and an invoice of 143.62 R$, we convert the amount in US$ which is 26.491668921649627 US$. As we have to round it for the accounting, we end up with 26.49 US$ as company currency amount, losing the rest of the decimals. During the reconciliation process, we convert back the US$ to R$ ending up with 143.61096147501 R$ that have to be rounded to 143.61 R$. This creates a difference of 0.01 R$ which surfaces later on. Chosen solution: As we still have the original currency amount and the rate, we are able to recompute the raw numbers and we are able to make "fairer" comparison between the amounts. If we can confidently tell that the amounts are close enough, we can just keep the original amount and prevent all those rounding errors to be taken into account. opw-4937508 Forward-Port-Of: odoo/enterprise#91462
A test for down payments in Peru e-invoicing was failing in setups without demo data because the test user lacked the needed sales access. The change adds that access so automated checks run reliably, reducing false failures during validation.
Original PR description
The new downpayment test failed in without demo due to missing sales group on the user. This fix adds the missing group. runbot-230456
Sales achievements recorded on the final day of a commission period are now included in that period's commission calculations. This ensures commission reports reflect the correct achieved amounts and prevents eligible sales from being missed.
Original PR description
**Issue** Achievements realised on the last day of the period were not taken into account (neither in the expected one, or the next period). **Steps to reproduce** - Create a commission plan with a monthly target frequency and an achievement on "Amount sold" - Have a Sale order with a `date_order` on the last day of a month - Click on the "Commissions" smart button to open the `sale.commission.report` list view -> achieved amount for the SO's month is missing. - Click on "Details" for the line -> there should be one `sale.commission.achievement.report` record. **Cause** We were comparing a Timestamp coming from the commission line with the start/end date of the period. To perform the comparison, the date was cast to a Timestamp with 0:00:00 as the hour, resulting in all commission lines on the last day of the period to be missed. opw-4857936 opw-4934168 Forward-Port-Of: odoo/enterprise#91707 Forward-Port-Of: odoo/enterprise#90658
Invoices in the Mexico localization can now be saved when they contain only a section or note line. This removes an unnecessary validation error and helps users create draft invoices with descriptive lines without needing tax details.
Original PR description
Issue: When we try to save an invoice with only a line section or line note, an error is thrown indicating invalid fields: invoice lines. This happens because the `l10n_mx_edi_tax_object` is required on account move lines. Purpose of this PR: Allow for line sections and line notes to be saved without tax objects. Steps to reproduce on Runbot: install l10n_mx switch to MX company and create an invoice with just a line section or line note save Invalid Fields error is raised opw-4987040
Opening a room from the Rooms menu now loads the room page correctly instead of showing a blank screen. This prevents users from being blocked when accessing room details or bookings.
Original PR description
**How to reproduce:** - Go to Rooms menu. - Open any room. - Click on 'Open' button. **Before this PR:** The screen appears blank. **Technical reason:** The issue was introduced by this commit: https://github.com/odoo/odoo/commit/0b6cab2cae6a084a6d2ed9b33d50342c08caa0f6 Here, 'public.interactions' is null because the `interaction_service` acts on `#wrapwrap`, which is not present in the template. As we are now using `#wrapwrap`, we have to keep vertical height as 100% manually. **After this PR:** The screen will load correctly and will no longer be blank. Task-4915155
This fix updates an internal barcode inventory test so it no longer depends on sample data being present. It helps keep automated checks stable and reduces the chance of false failures during release validation.
Original PR description
Add group 'stock.group_production_lot' to user to enable lots/SN runbot-error-230495 Forward-Port-Of: odoo/enterprise#91709
Chilean vendor bills can now be imported by accounting users who do not have administrator rights. This prevents failed imports and ensures bill details are filled in correctly during the import process.
Original PR description
### Issue: Vendor bills are not importing when the user has no administration rights. ### Steps to reproduce: - Install `l10n_cl_edi` and switch to a Chilean company - Create a new user without Administration access rights but with Accounting rights - Switch to this user - Go in Accounting > Vendor Bills - Import a Chilean vendor bill - On the created bill, we can see an error in the chatter, no fields have been filled ### Cause: This [commit](https://github.com/odoo/enterprise/commit/b26a7905cbcbfdb59d55a7ecf9e963e267b8f0a5) aadded a line writing on `l10n_cl_dte_file` but the field is only accessible to [`base.group_system`](https://github.com/odoo/enterprise/blob/bcd42d624587a968ec0b7023855ba4083894baf7/l10n_cl_edi/models/account_move.py#L1071). ### Solution: Use `sudo()` like everywhere in the file. opw-4943499 Forward-Port-Of: odoo/enterprise#91574 Forward-Port-Of: odoo/enterprise#91254
25 changes
Resolved issues and error corrections
The messaging menu now shows the right guidance when quick search finds no matching conversation. Users will no longer see conflicting empty-state messages, reducing confusion while searching their inbox threads.
Original PR description
**Steps to reproduce:** - Open the messaging menu with 20+ threads (quick search btn shows on 20+ threads) - Dismiss (or install) the 'Install Odoo' notification - Dismiss (or allow) the 'Turn on notifications' notification - Use quick search to look for a thread that doesn't exist => Both 'No thread found.' and 'No conversation yet...' messages are displayed This happens due to an incorrectly handled condition. This PR ensures only the relevant message is shown: - 'No thread found.' is displayed when the search yields no results. - 'No conversation yet...' is shown only when the user has no threads at all. <img width="565" height="279" alt="image" src="https://github.com/user-attachments/assets/689bc007-dfb4-4041-8543-18bc4ad2e19d" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221878
Sales orders are now checked with the proper locking rule before being locked. This restores previously missing behavior so subscription-related and similar orders are not locked when they should remain editable.
Original PR description
The diff from this commit was introduced in the past up until saas-17.1, to prevent locking of subscription sales orders. https://github.com/odoo/odoo/pull/159863 However, the forward porting commits after saas-17.2 are missing this diff. https://github.com/odoo/odoo/pull/159993/files Few months after the commits were merged, someone mentioned about this diff being missing, but no actions were taken afterwards. This commit applies the missing diff. --- In another [bugfix](https://github.com/odoo/enterprise/pull/91339), which is dependent on this , we decided to not lock SOs from FSM tasks, taking similar approaches as how Subscription Orders process it, utilizing the `_should_be_locked()` function. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221617 Forward-Port-Of: odoo/odoo#221281
Payment receipt PDFs now show the actual foreign-currency payment amount instead of the company-currency amount. This prevents confusing or misleading receipt totals when invoices are paid and reconciled in another currency.
Original PR description
**Steps to reproduce**: 1. Install the `accounting` module. 2. Activate a foreign currency form `Accounting -> Configuration -> Currencies` and fetch its exchange rate. <img width="599" height="267"…
**Steps to reproduce**: 1. Install the `accounting` module. 2. Activate a foreign currency form `Accounting -> Configuration -> Currencies` and fetch its exchange rate. <img width="599" height="267" alt="image" src="https://github.com/user-attachments/assets/34e7c719-20f7-4cd0-a1d6-0e94764461ba" /> 3. Create an invoice using the company’s default currency (e.g., USD). 4. Register a payment using the foreign currency (e.g., VES). 5. Reconcile the payment with the invoice. 6. Print the payment receipt PDF. **Observations**: In the printed PDF, under the `Amount In Currency` column, the amount is incorrectly displayed. For example, suppose `1 USD` = `100 VES`. - An invoice of `100 USD` is created. - A payment of `10,000 Bs` is registered (equivalent to 100 USD). - When the payment receipt is printed, the output appears as: ``` | Invoice Number | Reference | Amount In Currency | Amount | |--------------------|-------------------|--------------------|-------------| | INV/2025/00001 | | | 100.00 USD | | PBNK1/2025/00001 | INV/2025/00001 | -100.00 Bs | -100.00 USD | ``` Here, the `Amount In Currency` for the payment line shows **100 Bs** instead of the correct **10,000 Bs**. **Issue**: The payment receipt uses the `_get_reconciled_invoices_partials()` method to fetch details about reconciled invoices. However, the report incorrectly uses the `amount` field (in company currency) for the `Amount In Currency` column, leading to this mismatch. **Solution**: The report now uses `(debit/credit)_amount_currency` instead of `amount` to correctly reflect the foreign currency values in the `Amount In Currency` column. opw-4898706 Forward-Port-Of: odoo/odoo#221964 Forward-Port-Of: odoo/odoo#219439
Website visitors no longer lose selected event filters when moving to another results page or running a search. This keeps event browsing consistent and prevents users from having to reapply filters repeatedly.
Original PR description
**Issue**:
In the event page on the website, filters are lost when changing pages.
**Steps to reproduce**:
- Ensure enough events exist with multiple type for a category and sufficient quantity (e.g., 24 per type)
- Go to the website app > events:
- Filter events by a type
- Click "Next page" or perform a search
- The filter is lost
**Cause**:
Commit [7b188cf](https://github.com/odoo/odoo/commit/7b188cfedcdd14d2eef12da54084e46f81221350) introduced slug-based filtering. However, the implementation was not fully complete: the slug_tags were not retained in the `url_args` of the pager. As a result, when changing pages, the generated URLs lacked the necessary slug information, causing filters to be lost and search results to reset unexpectedly.
**Solution**:
Hardcode the slug_tags directly into the URL. This way, the slug_tags are preserved without modifying the XML files.
opw-4887189Duplicated pivot tables in spreadsheets now keep the same global filter restrictions as the original pivot. This prevents copied reports from showing unfiltered or inconsistent data, reducing manual correction and reporting errors.
Original PR description
Steps to reproduce: - insert a pivot in a spreadsheet - create a global filter matching one of the pivot fields - use the global filter to restrict the values - duplicate the pivot => the filter is not applied on the duplicated pivot Task:4966634 opw-4950469 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#220996 Forward-Port-Of: odoo/odoo#220588
The invoicing dashboard now uses customer credit notes, rather than vendor credit notes, in key sales reports such as top countries, categories, products, and salespeople. It also excludes draft and cancelled entries when users open top invoices, improving the accuracy of dashboard figures and follow-up lists.
Original PR description
Problem:- In Invoicing Dashboard, in some parts we get wrong values because of wrongly set domain making dashboard consider Vendor Credit Note instead of Customer Credit Note. Before this commit:- - In Invoicing Dashboard, reports Top Countries, Top Categories, Top Products, and Top Salespeople considers Customer Invoice and Vendor Credit Note. - When clicked on Top Invoices, moves in draft and cancel state are also displayed. After this commit:- - In Invoicing Dashboard, reports Top Countries, Top Categories, Top Products, and Top Salespeople considers Customer Invoice and Customer Credit Note only. - When clicked on Top Invoices, moves in draft and cancel state are not displayed. task-4851920 Forward-Port-Of: odoo/odoo#221873 Forward-Port-Of: odoo/odoo#213723
This fixes a display issue in the point-of-sale self-ordering flow where the keypad dropdown was not appearing. Restoring this control helps staff or users access the expected ordering options again.
Original PR description
The forwardport https://github.com/odoo/odoo/commit/621bc2ed48ce4e2486f1604fdfe4d85cc4dc179b introduced a `t-if=!isEditMode` that was making the latest `t-else` statement never reached, thus making `NumpadDropdown` never displayed. Therefore, we simply remove the t-if statement and adjust the xpath inherit to place the `QrOrderButton` just before the `NumpadDropdown` button 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#221642
Creating a sales order item from a project task now automatically fills the related company and product taxes. This prevents missing tax information in multi-company setups and helps keep billable project work correctly priced and invoiced.
Original PR description
## Short functional explanation of the error When clicking on "create and edit" on a Sales Order Item field in a task, the company field is left blank. As a result, the taxes linked to the product…
## Short functional explanation of the error When clicking on "create and edit" on a Sales Order Item field in a task, the company field is left blank. As a result, the taxes linked to the product don't appear. ## Reproduction Steps 1. Install the modules sales, timesheet and project. 2. Make sure that you have at least 2 different companies in the settings. 2. Click on the project app and create a new project. Check the Billable and Timesheets boxes. 3. Create a task and click on it. Set a customer: the field "Sales Order Item" should appear. 4. Click on the "Sales Order Item" field. Type random letters and click on "create and edit". 5. Select a product that has at least one tax. ### Expected behavior The company field should be filled as soon as we click on the create and edit button, and the taxes field should be filled with the taxes of the product as soon as we select said product. ### Unexpected behavior The company and taxes field remain empty. ## Origin of the issue Some fields were set at "default_." __ opw-4904861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221342
Products received from purchase orders with a 100% discount are now valued at zero instead of using their default cost. This prevents overstated inventory values and keeps accounting accurate for fully discounted supplier receipts.
Original PR description
**Current behavior:** Receiving some real-time valuated, non-standard cost product from an order with 100% discount will value the product at its `standard_price`. **Expected behavior:** Valuated at 0. **Steps to reproduce:** 1 Create an average cost, real-time valuated product with non-zero `standard_price` 2. Create a purchase order for some of the avco product, confirm and receive 3. Create and post the bill -> check valuation from inventory **Cause of the issue:** Currently from 6ba1106ae we will ignore a 100% discount in calculating `_get_gross_unit_price()`. **Fix:** Return 0 in this method if we are in a 100% discount case. opw-4862883 Forward-Port-Of: odoo/odoo#220998 Forward-Port-Of: odoo/odoo#217726
This change ensures a base system test related to hidden view fields is included when running standalone localization checks. It helps catch localization-related issues earlier in nightly testing before changes are merged.
Original PR description
This test is not run during the l10n standalone tests leading to error in nightly that are not detected before the merge. 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#219376
Opening a payment link for an unpaid invoice could fail because the payment amount was handled incorrectly. This fix ensures the amount is converted properly, allowing customers to access payment links without an error.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Go to Accounting/Invoicing;
2. open an unpaid invoice;
3. generate payment link;
4. open payment link.
Issue
-----
Traceback on a `ValueError`.
Cause
-----
Commit 5697493e00915 added a `amount and float('amount')`, trying to convert a string into a float.
Solution
--------
Convert the variable into a float instead.
opw-4996783
Forward-Port-Of: odoo/odoo#221914This fixes an inventory issue where changing a product's on-hand quantity to zero did not save correctly after refreshing the page. Businesses can now accurately clear stock quantities for products, improving inventory reliability and avoiding misleading availability figures.
Original PR description
<b>Steps to reproduce:</b> 1) Install stocks 2) Create a product variant with storable true 3) Change the on-hand quantity to some positive value and save 4) Now update the on-hand quantity to 0 and…
<b>Steps to reproduce:</b> 1) Install stocks 2) Create a product variant with storable true 3) Change the on-hand quantity to some positive value and save 4) Now update the on-hand quantity to 0 and refresh the page <b>Issue:-</b> The on-hand quantity doesn't update to 0. <b>Cause:-</b> When the user manually changes the on-hand quantity, an inverse method `_inverse_qty_available` is triggered to create a new stock.quant, but because of this condition, no new quant is created. https://github.com/odoo/odoo/blob/b2e845c46a0b152899ee630770abc15751493069/addons/stock/models/product.py#L236-L238 As a result, the qty_available value will remain same because it will be updated based on the stock.quant's record from the below line. https://github.com/odoo/odoo/blob/b2e845c46a0b152899ee630770abc15751493069/addons/stock/models/product.py#L185 https://github.com/odoo/odoo/blob/b2e845c46a0b152899ee630770abc15751493069/addons/stock/models/product.py#L217 <b>Solution:-</b> We can resolve this issue by modifying the condition in the inverse method to create a new stock.quant if the on-hand qty is 0 or more. Also skip creating a SM with 0 quantity when applying inventory from `_inverse_qty` opw-4761491 Forward-Port-Of: odoo/odoo#208739
Changing the journal on a payment no longer overwrites the selected partner with the journal company's partner. This prevents unwanted data changes and lets users manually choose the correct partner when preparing payments.
Original PR description
Reproducing steps: - Create a payment and select a journal. - Partner is set to the journal's company partner. - Try to change the journal manually. Before this PR: - Partner is reset to the journal's company partner. - Cannot assign a different journal for the journal's company partner. After this PR: - Removed unwanted compute dependency. - Partner is no longer reset and can be changed manually. opw-4769153 Forward-Port-Of: odoo/odoo#221867
This update fixes an internal testing issue so Point of Sale automated tests can run correctly without an internet connection. It helps maintain product quality and reduces the risk of testing failures blocking future updates.
Original PR description
Ensure hoot tests are correctly running offline. rb-error: 226900 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221857
The HTML editor color picker now shows background color opacity changes immediately while the slider is moved. This gives users accurate visual feedback when styling content, reducing confusion and trial-and-error.
Original PR description
### Steps to reproduce: - Type a command (e.g., /table) to insert a table. - Select some cells and apply a background color using the toolbar. - Click the Background Color button again in the toolbar. - Go to the Custom tab in the color picker. - Adjust the opacity using the slider. ### Description of the issue/feature this PR addresses: - Adjusting the opacity slider had no effect on the background color preview. ### Desired behavior after PR is merged: - The preview updates dynamically as the opacity slider is moved. task-4942309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219008
This fix prevents an error when a user starts a product return from a helpdesk ticket and clears the selected delivery. Instead of showing a traceback, the return flow now safely handles the missing delivery, improving reliability for support and inventory users.
Original PR description
step to reproduce : create a sales order with a service and a consumable product deliver the consumable product enable the 'returns' feature on your helpdesk team create a helpdesk ticket in this team select the customer and the SOL you created click on return empty the delivery field => traceback source of the issue : Setting the delivery_id field to false triggers a compute, in which an ensure one is later call on the delivery_id. Since the delivery is empty, it triggers an error. Solution : When the compute is triggered, we can prevent the rest of the code execution when the picking is set to False. task - 4935957 Forward-Port-Of: odoo/odoo#221160
Employees can now access the relevant subtasks in private projects when they should have permission. The update also strengthens the related test coverage so this access rule is checked more reliably in future releases.
Original PR description
same as https://github.com/odoo/odoo/commit/0d75ce1d3912bbd94c5ce3bc199b40134dfab69f but different field `has_template_ancestor`. the test was fragile and didn't cover the case correctly, it was improved in this commit. opw-4980443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the DHL Express shipment data sent by Odoo so commodity code information uses the field name expected by DHL. It helps avoid shipment creation issues caused by a mismatch with DHL's API documentation.
Original PR description
Changed the field name in commodityCodes from `code` to `value` to match with DHL API documentation. Check ticket log notes for details of DHL documentation. opw-4892324 Forward-Port-Of: odoo/enterprise#91645
The website rental shop now keeps original list prices hidden for zero-priced products that are unavailable for sale. This prevents customers and search engines from seeing prices that should only be visible while editing the website.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Create a pricelist setting product prices to zero;
2. configure website to make zero-priced products unavailable for sale;
3. go to /shop as a public user;
4. open the product page of a zero-priced product;
5. open the browser console;
6. use `document.querySelector('.css_non_editable_mode_hidden .oe_currency_value')`
Issue
-----
The query returns an element with the product's original list price.
Cause
-----
In `website_sale`, this element is part of a `t-if` that only gets rendered when `editable` is `True`. A `website_sale_renting` override changes the conditional to `not combination_info.get('is_rental')`.
Solution
--------
Instead of replacing the `t-if` attribute in the override, add `and not combination_info.get('is_rental')` to it, ensuring it remains hidden outside of editable mode.
opw-4865141
Forward-Port-Of: odoo/enterprise#91728
Forward-Port-Of: odoo/enterprise#91112This update makes an automated accounting test more reliable by adding extra waiting steps before key button clicks. It helps reduce intermittent test failures during statement creation, improving confidence in release checks without changing user-facing accounting behavior.
Original PR description
Steps --------- 1. Install account 2. Run the following test-tags `.test_accountant_tour` Problem --------- Sometimes, the tour fails in the statement creation step because the "New" button is not correctly pressed. The error does not always occur. Solution --------- Adding some intermediary steps so that the page settles before pressing on buttons. build-error-226436
Fixed an issue in Loan Analysis where searching for a loan could trigger an error instead of returning results. The search now uses the correct loan field, making loan reporting smoother and more reliable for users.
Original PR description
Behaviour before this commit: While searching for 'Loan' in the Loan Analysis view, a traceback appears since the filter_domain for the search is on `name` but `name` is not present in account.loan.line, instead it is `loan_name`. Desired behaviour after this commit: The filter_domain for 'Loan' is updated to search for `loan_name` instead of `loan`, and domain for `display_name` is removed. TaskID:4991369 Forward-Port-Of: odoo/enterprise#91637
This update fixes an internal test that could fail when the Accountant app was not installed. It helps keep quality checks stable and reduces false alarms during development and release validation.
Original PR description
**Issue:** "test_partner_account_batch_payments" test may fail when "accountant" module is not installed. **Solution:** Handle the case when "accountant" module is not installed separately as it is done in previous versions. runbot-230480
This fix restores prior behavior for imported asset depreciation after customer reports showed incorrect values in many cases. It prevents Odoo from shifting differences from previous software's depreciation calculations into the next period, while keeping improved remaining and depreciated value calculations.
Original PR description
This reverts commit 79aa48867de14a6d2315ec95b271004084d74b14. A lot of customers reported that the data was wrong in a lot of cases. For instance, when the previous software computed a lower depreciation than Odoo, Odoo was then moving the difference into the next period. The change for the computation of `asset_remaining_value` and `asset_depreciated_value` has been kept. opw-4968367 opw-4977970 opw-4961381 opw-4991216 opw-4965451 Forward-Port-Of: odoo/enterprise#91751 Forward-Port-Of: odoo/enterprise#91723
Rejecting an UrbanPiper order in Point of Sale now completes without triggering an unexpected error. This improves reliability for staff handling online orders and keeps the POS order flow stable after a rejection.
Original PR description
Steps to reproduce: --- - Configure UrbanPiper in any POS configuration. - Open this POS and place a test order. - Attempt to reject the order. Issue: --- - A traceback occurs when rejecting the order. Cause: --- - The `removeOrder` function was being called unnecessarily, even though it is already handled by `deleteOrders`. Fix: --- - Removed the redundant call to `removeOrder`. - Additionally, called `afterOrderValidation` and `setSelectedOrder` to properly reset the state after rejection. task-4965076 Forward-Port-Of: odoo/enterprise#91116
This fix prevents an error from appearing when a user clears the delivery field while processing a product return from a helpdesk ticket. It keeps the return flow stable by waiting until a valid delivery is selected before recalculating related return details.
Original PR description
step to reproduce : create a sales order with a service and a consumable product deliver the consumable product enable the 'returns' feature on your helpdesk team create a helpdesk ticket in this team select the customer and the SOL you created click on return empty the delivery field => traceback source of the issue : Setting the delivery_id field to false triggers a compute, in which an ensure one is later call on the delivery_id. Since the delivery is empty, it triggers an error. Solution : The field 'delivery_id' is required. So we can simply prevent the execution of the compute when the delivery is set to false and wait for the user to put a new value to trigger the compute correctly. task - 4935957 Forward-Port-Of: odoo/enterprise#90496
8 changes
Resolved issues and error corrections
This fix prevents an error from appearing when a helpdesk user clears the delivery field while returning a product. It keeps the return workflow stable and lets users select a valid delivery before the system recalculates return details.
Original PR description
step to reproduce : create a sales order with a service and a consumable product deliver the consumable product enable the 'returns' feature on your helpdesk team create a helpdesk ticket in this team select the customer and the SOL you created click on return empty the delivery field => traceback source of the issue : Setting the delivery_id field to false triggers a compute, in which an ensure one is later call on the delivery_id. Since the delivery is empty, it triggers an error. Solution : The field 'delivery_id' is required. So we can simply prevent the execution of the compute when the delivery is set to false and wait for the user to put a new value to trigger the compute correctly. task - 4935957 Forward-Port-Of: odoo/enterprise#90496
Fixed an issue where the Documents details panel could keep showing a previously selected document after users cleared the selection with the control panel. This keeps the panel in sync with the user's current selection and avoids confusion when managing documents.
Original PR description
The details panel does not update when clearing the selection through the control panel. Steps to Reproduce: ==================== - Open the detailsPanel. - Select a document. - Click on a blank space, which removes the current selection. - Re-select a document. - Click the ‘x’ button on the control panel to clear the selection. - The document selection in the detailsPanel does not get cleared. Technical =========== In DocumentsRightPanel and how DocumentsDetailsPanel is handled, The panel relies on the `state.focusedRecord` to determine which record's details to display. However, when clicking the ‘X’ button in the control panel to clear the selection, the `state.focusedRecord` is not being Updated or cleared, the detail panel still shows the previously focused record. After this PR: Clicking the ‘x’ will properly clear the selection from the detailsPanel. Task-4752944 Forward-Port-Of: odoo/enterprise#91151 Forward-Port-Of: odoo/enterprise#85272
This update keeps automated Knowledge app tests working after an internal change to how embedded videos are displayed. It helps maintain product reliability without changing the user-facing Knowledge experience.
Original PR description
Before this commit: - The EmbeddedVideoComponent used a dedicated subcomponent VideoIframe to render the iframe. - The tour test patched this VideoIframe component to mock iframe behavior during tests. After this commit: - Now, the VideoIframe subcomponent was removed and the iframe rendering was moved directly into the template of EmbeddedVideoComponent. - To adapt, this commit now patches the template of EmbeddedVideoComponent directly in the tour to preserve test behavior. community-https://github.com/odoo/odoo/pull/208366 task-4742547
This change fixes an internal test setup so barcode inventory checks no longer depend on sample demo data being present. It helps keep quality checks reliable and reduces false failures during development, with no direct change for everyday users.
Original PR description
Add group 'stock.group_production_lot' to user to enable lots/SN runbot-error-230495 Forward-Port-Of: odoo/enterprise#91709
Sales achievements made on the final day of a commission period are now included in the correct commission calculation. This prevents end-of-month sales from being missed, improving accuracy for commission reports and payouts.
Original PR description
**Issue** Achievements realised on the last day of the period were not taken into account (neither in the expected one, or the next period). **Steps to reproduce** - Create a commission plan with a monthly target frequency and an achievement on "Amount sold" - Have a Sale order with a `date_order` on the last day of a month - Click on the "Commissions" smart button to open the `sale.commission.report` list view -> achieved amount for the SO's month is missing. - Click on "Details" for the line -> there should be one `sale.commission.achievement.report` record. **Cause** We were comparing a Timestamp coming from the commission line with the start/end date of the period. To perform the comparison, the date was cast to a Timestamp with 0:00:00 as the hour, resulting in all commission lines on the last day of the period to be missed. opw-4857936 opw-4934168 Forward-Port-Of: odoo/enterprise#91707 Forward-Port-Of: odoo/enterprise#90658
Changing the date of a recurring shift in Sale Planning no longer leads to a missing record error. This helps teams safely update recurring schedules without interruptions or failed saves.
Original PR description
Version: 17.0 Steps to reproduce: - Install sale_planning - Create a recurrence shift. - Change the date of second shift which is created by recurrence. - Give the edit value as All shifts. - save record, missing error occured. Issue: When a user changes the date of a shift created by recurrence, the system crash with the message, "Record does not exist or has been deleted." Cause: There was an issue between "Planning" and "Sale Planning". When a user moves a shift, "Planning" removes the old shift from the system except the first one, But 'sale planning' was still trying to work with that removed shift. Fix: Now, after 'Planning' does its work, 'Sale Planning' checks again to see that shifts are still there. It only works with shifts that actually exist. So crash no longer happens. Users can now safely change the date of recurring shifts without errors. task-4859892 Forward-Port-Of: odoo/enterprise#91236 Forward-Port-Of: odoo/enterprise#88234
Customers can now choose supported shipping carriers at checkout when their order includes combo products, as long as the combo items have weights set. This also avoids incorrect missing-weight warnings for non-shippable order lines such as down payments, reducing checkout and sales order friction.
Original PR description
\* = bpost, dhl{,_rest}, easypost, sendcloud, ups, usps{,_rest} Versions -------- - 18.0+ Steps ----- 1. Have a combo product Foo; 2. ensure the combo items have a weight set; 3. enable & publish a…
\* = bpost, dhl{,_rest}, easypost, sendcloud, ups, usps{,_rest}
Versions
--------
- 18.0+
Steps
-----
1. Have a combo product Foo;
2. ensure the combo items have a weight set;
3. enable & publish a shipping connector;
4. add combo product to cart;
5. go to checkout;
6. attempt to select shipping connector as delivery method.
A similar message appears when trying to add a delivery method to a backend order if the order has downpayment lines.
Issue
-----
> The estimated shipping price cannot be computed because the weight is missing for the following product(s): Foo
Cause
-----
The combo product doesn't have a weight, as it's not a discrete item, but a collection of multiple items.
The shipping connectors haven't been updated yet to account for this, and still expect every non-service product to have a weight.
Solution
--------
When looking for lines without weight, filter out products of type `combo` (similar to how `service` products are handled) using a new `_get_invalid_delivery_weight_liens` helper method, added to `sale.order.line`.
Also ignore lines where `product_qty` is zero, e.g. `display_type` lines & down payment lines.
Community PR: https://github.com/odoo/odoo/pull/221696
opw-4940973
Forward-Port-Of: odoo/enterprise#91684
Forward-Port-Of: odoo/enterprise#91243This fix removes duplicated rental planning logic and keeps the intended behavior in one place. It reduces the risk of inconsistent planning results for rental orders and makes future maintenance safer.
Original PR description
Before this commit, since the merge of #91164, `_planning_slot_vals_list` method is duplicated in sale_renting_planning/models/sale_order_line.py file. This commit merges the both methods together to keep the behavior added in the one initially introduced before the fix merged. Forward-Port-Of: odoo/enterprise#91696
29 changes
Resolved issues and error corrections
Fixed an issue where long product purchase descriptions could overlap the table header when a purchase order PDF continued onto multiple pages. This makes printed purchase orders easier to read and avoids confusing or unprofessional document formatting.
Original PR description
**Steps to reproduce**: 1. Install the `purchase` module. 2. Go to a product's `Purchase` tab and add a long purchase description (approx. 40–45 lines). 3. Create a Purchase Order using this product.…
**Steps to reproduce**: 1. Install the `purchase` module. 2. Go to a product's `Purchase` tab and add a long purchase description (approx. 40–45 lines). 3. Create a Purchase Order using this product. 4. Print the PDF of the Purchase Order (via gear icon). **Observation**: The long product description overlaps with the table header when the table spans multiple pages in the generated PDF. **Issue**: wkhtmltopdf does not handle multi-page table headers properly by default. causing header/content overlap when the table breaks across pages. **Solution**: Apply a known wkhtmltopdf workaround by explicitly setting: `<thead style='display: table-row-group;'>` This ensures headers will not repeat same as sale order. ref(https://github.com/odoo/odoo/pull/53909) Before: <img width="1003" height="426" alt="image" src="https://github.com/user-attachments/assets/38b7b4de-ea81-445f-8cd2-ae164fcb7531" /> After: <img width="1000" height="414" alt="image" src="https://github.com/user-attachments/assets/ef09ef94-2a26-468a-b6e7-03d93b4515b8" /> opw-4908457
Portal users can now access marketing cards in the same way public users already could. This fixes an access issue that could prevent recipients, who are often customer or partner portal users, from viewing cards intended for them.
Original PR description
The access right that allows public users to read cards should obviously apply equaly to portal users. Recipients will very often be partners so them not being allowed is very annoying. task-5000332
The HTML editor now clears multiple text styles, such as size, color, and bold, with a single click. This avoids repeated user actions and makes document editing more predictable.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Select a text - Apply font size - Apply color - Apply bold - Clicking on removeFormat button doesn't remove all formats User has to click on removeFormat button twice to remove the format. **Desired behaviour after PR is merged:** Now, all formats are getting removed at once when clicking on removeFormat button. task-4911199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The project stock workflow no longer opens an unavailable map view in the community edition. This prevents users from seeing an error when clicking the 'From WH' button from a project task, while leaving room for the enterprise edition to add the map view where supported.
Original PR description
* STEP TO REPRODUCE: go to task of a project, enable 'From WH' in top bar button. Click on it -> error because no map view * SOLUTION: in community version we should remove map view then in enterprise we can overide to add it 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
Payment receipt PDFs now show the actual payment amount in the foreign currency instead of the company-currency equivalent. This prevents confusion for customers and accounting teams when invoices are paid and reconciled in another currency.
Original PR description
**Steps to reproduce**: 1. Install the `accounting` module. 2. Activate a foreign currency form `Accounting -> Configuration -> Currencies` and fetch its exchange rate. <img width="599" height="267"…
**Steps to reproduce**: 1. Install the `accounting` module. 2. Activate a foreign currency form `Accounting -> Configuration -> Currencies` and fetch its exchange rate. <img width="599" height="267" alt="image" src="https://github.com/user-attachments/assets/34e7c719-20f7-4cd0-a1d6-0e94764461ba" /> 3. Create an invoice using the company’s default currency (e.g., USD). 4. Register a payment using the foreign currency (e.g., VES). 5. Reconcile the payment with the invoice. 6. Print the payment receipt PDF. **Observations**: In the printed PDF, under the `Amount In Currency` column, the amount is incorrectly displayed. For example, suppose `1 USD` = `100 VES`. - An invoice of `100 USD` is created. - A payment of `10,000 Bs` is registered (equivalent to 100 USD). - When the payment receipt is printed, the output appears as: ``` | Invoice Number | Reference | Amount In Currency | Amount | |--------------------|-------------------|--------------------|-------------| | INV/2025/00001 | | | 100.00 USD | | PBNK1/2025/00001 | INV/2025/00001 | -100.00 Bs | -100.00 USD | ``` Here, the `Amount In Currency` for the payment line shows **100 Bs** instead of the correct **10,000 Bs**. **Issue**: The payment receipt uses the `_get_reconciled_invoices_partials()` method to fetch details about reconciled invoices. However, the report incorrectly uses the `amount` field (in company currency) for the `Amount In Currency` column, leading to this mismatch. **Solution**: The report now uses `(debit/credit)_amount_currency` instead of `amount` to correctly reflect the foreign currency values in the `Amount In Currency` column. opw-4898706 Forward-Port-Of: odoo/odoo#219439
The Stripe documentation link in Point of Sale payment provider settings has been corrected. This helps users quickly access the right setup instructions and avoids confusion during payment configuration.
Original PR description
Before this commit: ---------------- - The Stripe documentation link in the POS payment provider configuration was broken, leading to a poor user experience. After this commit: ------------------------------- - The Stripe documentation link has been corrected to ensure proper access to setup instructions. Task - 4797691
Email template lists in the email composer now show only templates available to the current user or templates not assigned to anyone. This prevents users from seeing templates intended for other users, keeping the send-email workflow cleaner and more accurate.
Original PR description
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo user. 4. Create a quotation and click the 'Send by Email' button. 5. In the wizard, click the three dots between the attachment and AI logo in the footer. 6. Observe the templates list. **Issue:** - The template created for the admin user appears for the demo user as well. **Cause:** https://github.com/odoo/odoo/blob/07626050bd0104fecd8799b56d30245d00da3f27/addons/mail/static/src/core/web/mail_composer_template_selector.js#L31-L44 - The domain used to fetch templates was incorrectly filtering for templates assigned to any user (instead of filtering for templates assigned to the current user or not assigned at all). **Solution:** - Corrected the domain to include only templates assigned to the current user and not assigned to anyone. opw-4901492
The messaging menu now shows only the relevant empty-state message during quick search. Users searching for a conversation that does not exist will see “No thread found” without also seeing the general “No conversation yet” message, reducing confusion.
Original PR description
**Steps to reproduce:** - Open the messaging menu with 20+ threads (quick search btn shows on 20+ threads) - Dismiss (or install) the 'Install Odoo' notification - Dismiss (or allow) the 'Turn on notifications' notification - Use quick search to look for a thread that doesn't exist => Both 'No thread found.' and 'No conversation yet...' messages are displayed This happens due to an incorrectly handled condition. This PR ensures only the relevant message is shown: - 'No thread found.' is displayed when the search yields no results. - 'No conversation yet...' is shown only when the user has no threads at all. <img width="565" height="279" alt="image" src="https://github.com/user-attachments/assets/689bc007-dfb4-4041-8543-18bc4ad2e19d" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users from creating new work entries in the list view for French payroll. The system now handles missing start or end dates safely, making manual entry creation more reliable.
Original PR description
Currently, a traceback occurs when a user attempts to create a work entry in the list view. **To reproduce this issue:** 1) Install the `l10n_fr_hr_work_entry_holidays` module. 2) Switch to the `French` company and open the payroll. 3) Open the work entries in list view and try to create a new record. **Error:** ``` AttributeError: 'int' object has no attribute 'seconds' ``` **Cause:** By default, when creating a work entry through the list view, no `start` or `end` date is provided. This leads to the traceback originating from the following line when computing the duration. https://github.com/odoo/odoo/blob/84b15dc1f866e27d5c8a5fe3e457c2f982bcb133/addons/l10n_fr_hr_work_entry_holidays/models/hr_work_entry.py#L28-L32 **Solution:** Adding an extra check of the `start` and `end` date would resolve this issue. opw-4943104 Forward-Port-Of: odoo/odoo#220127
Purchase orders now use the supplier’s configured currency even when they are created automatically, such as from an approval request. This prevents orders from defaulting to the company currency and helps keep supplier pricing and purchasing records accurate.
Original PR description
Steps to reproduce: - Go to Invoicing > Configuration > Accounting > Currencies: - Enable the Euro currency - Set company currency to USD - Go to any partner form (e.g. Azure Interior): - In Sales &…
Steps to reproduce:
- Go to Invoicing > Configuration > Accounting > Currencies:
- Enable the Euro currency
- Set company currency to USD
- Go to any partner form (e.g. Azure Interior):
- In Sales & Purchase tab: - Set Supplier Currency to Euro
- Create a purchase order from the UI:
- Select Azure Interior → Currency is correctly updated to Euro (via onchange)
- Install the Approvals module
- Create a storable product "P1":
- Under Purchase tab: - Vendor: Azure Interior - Price unit: 5 EUR
- Create an approval request:
- Request Owner: Marc Demo
- Product: P1
- Approver: Mitchel Admin
- Submit and approve the request
- Click on "Create Purchase Order"
Issue:
The purchase order is created with the correct partner and product. But the currency is incorrectly set to the company currency (USD), instead of the supplier's currency (Euro).
Cause:
The currency was updated via an `@onchange`, which is only triggered in the UI.
When creating a PO programmatically (e.g. via approvals or in a test), the onchange is not executed and the currency falls back to the company default.
Solution:
Replace the `@onchange` logic for `currency_id` with a stored compute field.
This ensures that the correct currency is always computed, regardless of how the purchase order is created.
opw-4938390Fixes an error that could occur when users tried to add tags to a contact in the Contacts app. This keeps contact editing smooth and prevents users from being blocked by an unexpected crash.
Original PR description
**Steps to reproduce:** 1. Install the "Contacts" app. 2. Go to Contacts > Open any contact. 3. Click on the "Tags" (Partner Category) field to add a tag. **Issue:** A traceback is raised: `TypeError: can only concatenate list (not "_ProtectedDomain") to list` **Cause:** - Due to recent changes in https://github.com/odoo/odoo/commit/cd5f29b8b50ef4228be8f58a02bb328548208f77, default domains like `TRUE_DOMAIN` are now defined using a `_ProtectedDomain` class (a tuple subclass) instead of regular lists, to make them immutable. - This breaks code that tries to modify or concatenate domains assuming they are lists. - In this case, `res.partner.category._search_display_name` returned a `_ProtectedDomain` which was passed to `_search()`, leading to the error when Odoo tried to prepend additional filters. Solution: - Before using the domain in _search(), convert it to a regular list using list(domain). opw-4991994
This fix updates Canadian fiscal position mappings so products using Nova Scotia's new 14% HST are handled correctly outside Nova Scotia as well. It helps ensure the correct taxes are applied during transactions and avoids incorrect tax mapping in Canadian localizations.
Original PR description
In odoo/odoo#219117 we added the new 14% tax required for Nova Scotia's tax mandate changes, while the fiscal position was properly update for NS, the rest of the FP were ommited so as of now if any product has a HST 14% tax on it it won't be properly mapped to the correct tax. This was noticed in the saas-18.3 forward port this PR will fix the CSV in older versions and update the migration script for all FP in all versions. task-4937159 Forward-Port-Of: odoo/odoo#220280
This fixes an internal automated test for Time Off that was failing because it relied on a fragile screen element lookup. The test was rewritten to check the same behavior more reliably, helping keep future updates moving without false failures.
Original PR description
The #217517 PR is causing a test failure on runbot.
The problem was due to use of ```$('.o_stat_info:contains("Time Off")')``` to get the element in tour.
To avoid unnecessary use of tour, the test is re-written.
runbot-230486
Forward-Port-Of: odoo/odoo#221706Point of Sale loyalty rewards now correctly add the free product when the eligible item has multiple variants. This helps ensure customers receive promised rewards consistently at checkout and reduces manual corrections for cashiers.
Original PR description
Before this commit, when using a free product reward on multi products that have several variants, adding the desired product to the order would not always trigger the automatic addition of the free product as expected. opw-4841759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the HTML editor where starting to create a link and then clicking away could leave the link popover stuck open or cause it to reappear. This makes editing text smoother and prevents unfinished empty links from lingering after users cancel the action.
Original PR description
reproduction 18.0 and 18.1: 1. Go to the To-do app and type some text. 2. Select the typed text and click the Link button in the toolbar. 3. A link editing popover appears, without adding an href,…
reproduction 18.0 and 18.1: 1. Go to the To-do app and type some text. 2. Select the typed text and click the Link button in the toolbar. 3. A link editing popover appears, without adding an href, click anywhere outside the popover. 4. The popover does not close when clicking outside. And pressing Escape and clicking again in the editor, the popover reopens **Before this commit:** When creating a link from the toolbar, the link element is not padded with `feff` . This results in the selection remaining inside the link when clicking away and keeps the popover open. Pressing Escape only closes the popover but does not clean up the created link element. **After this commit:** We pad the newly created link element with `feff` when it is eligible for visual link isolation but not already padded. This ensures the padding is limited to newly created links. Additionally, when pressing Escape, we now clean up empty link elements after closing the popover. task-4948641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers no longer receive automatic emails asking them to pay an invoice when a saved payment method is already being processed through the payment registration flow. This avoids confusing customer communication and better reflects the actual payment status.
Original PR description
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the…
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed. **Steps to Reproduce:** 1. Enable "Automatic Invoicing" from Sales settings. 2. Enable and publish any payment provider (e.g., Demo) in test mode. 3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner. 4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm. 5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment. **Fix:** This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4850293) opw-4850293 Forward-Port-Of: odoo/odoo#221587
Fixes a website editor issue where pages could crash when reopening content that had a carousel inside a table of contents block with its navigation hidden. This makes editing those pages reliable again and prevents disruption for website managers.
Original PR description
Problem: When `s_carousel` is placed inside an `s_table_of_content` and the navbar of the TOC is hidden (visibility set to "Hide" on desktop), saving and reopening the editor results in a traceback.…
Problem: When `s_carousel` is placed inside an `s_table_of_content` and the navbar of the TOC is hidden (visibility set to "Hide" on desktop), saving and reopening the editor results in a traceback. Cause: The traceback occurs due to the following sequence: In `WysiwygAdapterComponent.startEdition`, calling `await super.startEdition()` will invoke `createInvisibleElement()` if the navbar is hidden. This, in turn, activates the scroll spy by calling `_activateScrollSpy()` while starting the TOC snippet. That triggers `widgets_start_request`, which starts the `s_carousel` snippet. However, at this point the `wysiwyg` instance has not yet been attached to the `wrapwrap` element. That happens later, at: https://github.com/odoo/odoo/blob/f12050f75ae9ae1125c0c01ec504a24bd401b1ea/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L318 and only after the `await super.startEdition()` call at: https://github.com/odoo/odoo/blob/f12050f75ae9ae1125c0c01ec504a24bd401b1ea/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L232 This delay causes a race condition when starting widgets like `s_carousel` that rely on the presence of the `wysiwyg` instance. Solution: Attach the `wysiwyg` instance to the DOM before `await super.startEdition()` in `WysiwygAdapterComponent.startEdition`. Steps to reproduce: - Add a Table of Content block - Insert a Carousel inside the content - Set the TOC navbar visibility to "Hide" on desktop - Save the page - Reopen the editor - A traceback occurs opw-4971409 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221200
Fixed an issue where calendar events created from a contact could lose the intended link because an empty internal value was saved instead of the default contact. This helps ensure meetings remain correctly associated with the relevant contact when users create them from the calendar flow.
Original PR description
To reproduce:
=============
- Pick any contact
- Click on meeting
- Select the time for the meeting with that contact
- Click on more options
- Add a meeting and save
- Click on meeting & contact
Problem:
========
- When creating calendar events, res_id=0 is passed in vals_list
- Events are created with res_id=0 instead of using default value
Solution:
=========
- Add separate handling for res_id in vals_list processing
- Apply defaults.get('res_id') when vals.get('res_id') is falsy
opw-4892445
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216042Payroll now correctly avoids carrying over sick leave or other time off when it overlaps with a public holiday. This prevents employees from receiving an incorrect deferred leave adjustment on a later payslip.
Original PR description
The aim of this commit is to prevent a sick day or any other type of time off taken on a public holiday to be deferred. To reproduce: - Create a public Holiday for previous month - Regenerate the work entries for that month - Compute a batch of payslip for last month, validate and mark it as paid --> The public holiday should be on the payslip - OPTIONAL: run the cron `Payroll: Generate pdfs` to make create the payslip in document and make it available to the concerned employee. - With the concerned employee, put a time off on the whole week of the last month. It should overlap with the public holiday. - Validate the time off and defer it for next payslip - Compute a batch of payslip for following month, validate and mark it as paid Before this commit: The overlapping sick day gets deferred completely ignoring the fact it was a public holiday. After this commit: The overlapping sick day doesn't get deferred. opw-4903546 Forward-Port-Of: odoo/enterprise#89264
This fixes a timing issue that could affect invoice naming when processing Spanish Amazon sales. It helps ensure invoice references are handled correctly and reduces the risk of incorrect or prematurely locked invoice names.
Original PR description
Accessing `invoice_line_ids` was flushing and protecting `move_name` too early. runbot-162079
The journal report now keeps draft invoice lines grouped in a stable order when several draft invoices share the same date. This prevents errors when users click "Load More" while including draft entries, improving reliability for finance reporting.
Original PR description
**Issue description:** When fetching AMLs for the journal report with _query_aml(), it sorts the AMLs based on (am.date, am.name), which are not unique in case we have multiple (draft) moves with the same date. The lines will end up mixed and ordered with respect to the account, which causes errors with the "Load More" functionality, as it assumes that the lines are ordered based on their move. For posted entries, it's not an issue as the am.name is unique. **Steps to reproduce:** -Create 3 or more invoices (with 3+ AMLs each) in draft and on the same invoicing date. -Open journal report settings and set the Load More Limit to 5. -Open the journal report and set the date to this day and check the "Include Draft Entries" option. -Press "Load More", you will get an error. opw-4929907 Forward-Port-Of: odoo/enterprise#90360
WhatsApp message previews now keep underscores in links instead of treating them as italic formatting. This prevents copied URLs from being altered, helping customers and users access the correct pages from WhatsApp messages.
Original PR description
To reproduce this error: 1- Send a message that has _ in whatsapp message e.g. http://example.com/my/orders/3?access_token=ab 2- Preview the message and copy the url into browser 3- As you see _ in the url is turning into italic symbol opw-4889978
This update addresses several user-facing issues across Odoo Enterprise, including payroll offer handling, subscription discounts, accounting exports, bank synchronization, data merging, and localized financial reporting. It improves accuracy, prevents duplicate actions, and helps businesses comply with reporting requirements in Türkiye and Germany.
This fixes an issue where hidden page data could still expose a product’s original list price when a zero-priced item was unavailable for sale. The change keeps those prices hidden for public visitors and search engines while preserving the intended editing behavior for website managers.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Create a pricelist setting product prices to zero;
2. configure website to make zero-priced products unavailable for sale;
3. go to /shop as a public user;
4. open the product page of a zero-priced product;
5. open the browser console;
6. use `document.querySelector('.css_non_editable_mode_hidden .oe_currency_value')`
Issue
-----
The query returns an element with the product's original list price.
Cause
-----
In `website_sale`, this element is part of a `t-if` that only gets rendered when `editable` is `True`. A `website_sale_renting` override changes the conditional to `not combination_info.get('is_rental')`.
Solution
--------
Instead of replacing the `t-if` attribute in the override, add `and not combination_info.get('is_rental')` to it, ensuring it remains hidden outside of editable mode.
opw-4865141
Forward-Port-Of: odoo/enterprise#91112This fix restores the previous behavior for imported assets so Odoo no longer shifts depreciation differences from prior software into the next period. It helps keep asset reports and depreciation schedules accurate for customers migrating accounting data, while preserving improved remaining and depreciated value calculations.
Original PR description
This reverts commit 79aa48867de14a6d2315ec95b271004084d74b14. A lot of customers reported that the data was wrong in a lot of cases. For instance, when the previous software computed a lower depreciation than Odoo, Odoo was then moving the difference into the next period. The change for the computation of `asset_remaining_value` and `asset_depreciated_value` has been kept. opw-4968367 opw-4977970 opw-4961381 opw-4991216 opw-4965451 Forward-Port-Of: odoo/enterprise#91751 Forward-Port-Of: odoo/enterprise#91723
Urban Piper menu synchronization now sends a DoorDash-compatible selection limit for multi-checkbox product options. This prevents checkbox-style options from appearing as single-choice radio buttons, helping restaurants present menus accurately on DoorDash.
Original PR description
Steps: - Configure urban piper in pos.config - Select products that has attribute and its type is multi-checkbox - Sync menu. Issue: - For Doordash multi-checkbox appears as radio instead of checkbox. Cause: - max_selectable is -1 which is not supported by Doordash. Fix: - Send static value as 30 instead of -1. task- 4971545
Customers no longer receive automatic emails asking them to pay when a payment has already been started through the payment registration process. This prevents confusing payment reminders and improves the customer experience for invoices paid with saved payment details.
Original PR description
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the…
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed. **Steps to Reproduce:** 1. Enable "Automatic Invoicing" from Sales settings. 2. Enable and publish any payment provider (e.g., Demo) in test mode. 3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner. 4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm. 5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment. **Fix:** This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard. opw-4850293 Forward-Port-Of: odoo/enterprise#91570
Searching for loans in the Loan Analysis view now uses the correct loan field, preventing an error message from appearing. This helps users find loan records reliably without interruptions.
Original PR description
Behaviour before this commit: While searching for 'Loan' in the Loan Analysis view, a traceback appears since the filter_domain for the search is on `name` but `name` is not present in account.loan.line, instead it is `loan_name`. Desired behaviour after this commit: The filter_domain for 'Loan' is updated to search for `loan_name` instead of `loan`, and domain for `display_name` is removed. TaskID:4991369
This fix prevents Romanian SAF-T exports from being blocked when optional product group information is missing or when VAT checks incorrectly flag partners. Businesses can complete required tax reporting more smoothly with fewer false validation errors.
Original PR description
- Added fallback for missing to prevent crash during export. - Replaced incorrect usage of with to align with actual partner VAT validation logic and avoid false errors. These changes ensure smoother SAF-T export by handling optional fields and validation more robustly.