Wednesday, August 6, 2025
26 changes · saas-18.4
New functionality added to Odoo
This update adds standard Profit and Loss and Balance Sheet reports for the Vietnamese localization. Businesses operating in Vietnam can now access localized financial statements more easily, supporting reporting and compliance needs.
Original PR description
Add the P&L and the BS for the vietnamese localization task-2492680 Forward-Port-Of: odoo/enterprise#91672 Forward-Port-Of: odoo/enterprise#90594
Enhancements to existing features
Restaurant staff are now alerted when the first dine-in self-order is placed from a table. The POS plays a sound and shows a persistent notification with a Load button, helping staff notice and open the order quickly.
Original PR description
Before this commit: =================== - When a customer placed a self-order for Dine In, the config was not notified. After this commit: ================== - A new sound `order-receive-tone` plays when a Dine In self-order is placed. - A sticky notification appears in the pos when the first order is received from a table. - This notification stays on the screen until it is manually closed by clicking the `Load` button. - Clicking `Load` button opens the order in the `register view`. Task: 4874405
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
The Vietnamese localization now includes additional default accounts to better separate short-term and long-term balances. This supports newer financial reports that require that distinction, helping companies produce more accurate localized reporting with less manual setup.
Original PR description
With the addition of financial reports where the distinction between short and long term is done, we add new default accounts to cover these needs. task-2492680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221741 Forward-Port-Of: odoo/odoo#219807
Belgian certified point-of-sale setups now automatically select the fiscal device when exactly one is available. This reduces manual configuration and helps businesses start using certified POS more quickly with fewer setup errors.
Original PR description
If one wants to use a certified pos without FDM and there is only one available, the pos automatically selects this one.
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
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
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
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
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 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
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
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
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
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
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