Wednesday, July 23, 2025
17 changes · saas-18.1
Resolved issues and error corrections
This fixes VietQR generation for Vietnam localization when a company has a state such as Hanoi or Hai Phong but no city entered. Businesses can now create compliant QR payment codes without unnecessary address validation errors.
Original PR description
* Problem: Using Vietnam localisation, leave city empty and just input state_id as Hà Nội or Hải Phòng, try to use vietqr code -> Raise error missing city * Solution: Just like https://github.com/odoo/odoo/pull/218984 we should check for state too although according to VietQR document, merchant city is not required see (https://vietqr.net/portal-service/download/documents/QR_Format_T&C_v1.0_VN_092021.pdf and search for term 'Merchant City') 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#219566
The Today filter now correctly shows only records from the current day in both Timesheets and the attendance report. This prevents users from seeing unrelated entries when reviewing daily work or attendance data.
Original PR description
In this bug, the today filter in timesheet is not written correctly. To reproduce the bug: 1- Create a db with timehseet installed 2- In timesheet app, and add records with different dates 3- Add Today filter 4- The filtered records are not only from today 5- The bug is also reproducible in attendance report In the fix, the filters which are used both in timesheet and report, are fixed. opw-4936780 Forward-Port-Of: odoo/odoo#219692
A redundant step was removed from an automated restaurant point-of-sale test. This helps keep quality checks reliable and reduces false failures in the release process.
Original PR description
Following this commit: ==== - Extra step was removed. runbot Error: 114352 Forward-Port-Of: odoo/odoo#198457
This fix stops website editor history records from being written directly, avoiding failures when content is copied or duplicated. It helps keep editor history consistent and reduces the chance of errors during normal editing workflows.
Original PR description
This commit prevent direct write to history, also, removes it from copy_data as it would fail anyway when trying to write the history Forward-Port-Of: odoo/odoo#217951 Forward-Port-Of: odoo/odoo#217167
This fixes a wording mismatch in website sales email content by using lowercase “order” where the email template expects it. The change helps keep automated tests aligned with customer-facing email text and prevents avoidable build failures.
Original PR description
in the email body it is 'order' not 'Order' , check the error in the runbot build error log build_error-223173 Forward-Port-Of: odoo/odoo#219388
Fixes an issue where certain website or report templates could accidentally omit an item when a conditional section appeared next to a comment. This helps ensure rendered pages and documents show the expected content consistently.
Original PR description
Forward-Port-Of: odoo/odoo#212159
Opening or reading Sign requests that are not in the shared state no longer triggers an error. The share link is now left empty when it does not apply, improving reliability for users and integrations accessing Sign request records.
Original PR description
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests…
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests that are in the 'shared' state. However this compute method fails for requests not in the 'shared' state leading to a traceback error. This commit fixes it by setting the default as False for the sign.request records that do not have state='shared' so the traceback error is handled. This can be reproduced in v17 and above by: 1. Open any sign.request record that isn't in the shared state 2. Enable Developer Mode 3. Using the debug icon, click on view record data The traceback will be visible here which mentions that the compute method failed to assign It can also be re-produced by using an xml-rpc / json-rpc ORM call to search_read the sign.request records that does not have state = 'shared' ### Before https://github.com/user-attachments/assets/24c07f2a-2398-44b4-8969-30abb576876a ### After https://github.com/user-attachments/assets/e92b1212-5405-4b98-ba41-c81b2ac547d7 [opw-4864159](https://www.odoo.com/odoo/project/49/tasks/4864159) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90576
The UrbanPiper point-of-sale integration now uses the actual finalized order status instead of an unused internal flag. This helps ensure order tickets show the correct state and reduces the risk of incorrect handling in the POS screen.
Original PR description
In this commit: ==== - Use `finalized` instead of `uiState.locked` to determine order state on TicketScreen. - Remove the unused `locked` property from `uiState` in posOrder. Task-4745869 Related: odoo/odoo#207406 Forward-Port-Of: odoo/enterprise#86684
This fixes an installation failure in Project Documents when a standard Documents tag, such as Draft, was previously deleted. Businesses can now install the feature reliably even if their Documents setup was customized.
Original PR description
**Steps to reproduce** On a fresh database: - Install Documents - Delete the "Draft" tag - Try to install `documents_project` Installation fails: `ValueError: External ID not found in the system: documents.documents_tag_draft` **Cause** Documents tags can be deleted, innstallation of `documents_project` will fail if `ir_actions_server_data.xml` references a deleted tag https://github.com/odoo/enterprise/blob/99d7d43abf17877f6cf2e0ad88bb64fdd85b4579/documents_project/data/ir_actions_server_data.xml#L14 **Solution** Partially backport the part of the fix related to `documents_project` in https://github.com/odoo/enterprise/commit/0be3fb2661b14690f090776a2da4eb767e489ef2 , the part related to `documents_account` is only necessary for 18.2 and later after https://github.com/odoo/enterprise/commit/30968e831a92d4317025a2c312a273a0bd51f9a2. opw-4554976 Forward-Port-Of: odoo/enterprise#79252
When creating a credit note from a Peruvian vendor bill, users now see the appropriate purchase journals instead of sales journals. This prevents selection errors and helps accounting teams process vendor refunds correctly.
Original PR description
**Issue** When creating a credit note for a vendor bill, the journal selection dropdown incorrectly shows only sales-type journals instead of purchase-type journals. **Steps to Reproduce** 1. Install the modules: Accounting, l10n_pe, and l10n_pe_edi. 2. Navigate to Accounting > Vendors > Vendor Bills. 3. Open a posted vendor bill and click Credit Note. 4. Open the journal dropdown. 5. Notice that only sales journals are shown. **Root Cause** The journal field's domain was hardcoded to type = 'sale' in the inherited view. This forces the dropdown to show only sales journals, even when reversing a vendor bill. **Fix** Removed the hardcoded domain from the XML view. This allows Odoo to apply its standard logic for journal filtering, which correctly selects purchase journals when reversing vendor bills. Opw-4913997 Forward-Port-Of: odoo/enterprise#90445
An obsolete empty file in the Documents app was removed after it had been unintentionally left behind during earlier cleanup work. This has no expected effect on users, but helps keep the codebase cleaner and avoids confusion for future maintenance.
Original PR description
During sharepocalypse, the file was emptied but not deleted, it's not used anymore. Introduced in https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e (18.0). Already removed in https://github.com/odoo/enterprise/commit/bb196623f348795536368287eb1a6e1ac5f5bc44 (saas-18.3). Forward-Port-Of: odoo/enterprise#89518
This update keeps several Odoo apps working reliably with newer Python, Debian, Babel, and PDF library versions. It mainly adjusts automated checks so upgrades do not create false failures or block future maintenance.
Original PR description
Forward-Port-Of: odoo/enterprise#90362 Forward-Port-Of: odoo/enterprise#90352
When a company chooses to receive Peppol documents only in a Documents folder, Odoo will no longer automatically select a purchase journal as well. This keeps the Peppol setup aligned with the user's chosen destination and avoids unintended accounting configuration.
Original PR description
In the Peppol settings, you can choose to receive your documents in an accounting journal, a documents folder, or both. However, when we only select a folder, the compute method of the journal field will still choose a purchase journal by default. We don't want that. This fix makes sure that we only compute the journal when no folder has been set. no-task Forward-Port-Of: odoo/enterprise#90083
The Knowledge editor now restores extra space at the bottom of long documents while editing. This makes it easier for users to scroll the final lines into a comfortable viewing position, improving readability and the writing experience.
Original PR description
With version 18.1, we migrated from legacy HTML editor to the new one. As part of this upgrade, we revised the templates and reworked the wysiwyg helper. During the migration, several CSS classes were altered or removed. One issue that emerged is that the CSS rules intended to add bottom padding to the editor area are still present in the stylesheet but no longer apply to any element. These rules were especially helpful when working with long-form content, as they allowed users to scroll further and bring the end of the text closer to the center of the screen - improving readability and enhancing the editing experience. To fix this, we'll update the relevant CSS selector to ensure the padding is correctly applied to the editable area. See: odoo/enterprise#67083 Task-4636494
This fixes the wording shown for subscription products that are physical goods invoiced on delivered quantities. The corrected description helps users choose the right invoicing setup and avoids confusion during product configuration.
Original PR description
To reproduce: ============== 1- go to subscription 2- go to product 3- select product type : goods and invoicing_policy : Delivered Quantity Problem: ========= wrong description. Solution: ========== update description. opw-4929735 Forward-Port-Of: odoo/enterprise#90143
Fixed an issue where opening the On Hand stock view from a product linked to an approval could trigger an error. Users can now review product availability from approvals without interruption.
Original PR description
<b>Steps to reproduce:</b> 1. Install the `approval`,`stock` module. 2. settings Inventory> Warehouse > check storage Loaction 3. Go to approval > Manager> All Approvals 4. Select an Approval > add…
<b>Steps to reproduce:</b> 1. Install the `approval`,`stock` module. 2. settings Inventory> Warehouse > check storage Loaction 3. Go to approval > Manager> All Approvals 4. Select an Approval > add storable product with on hand quantity > 0. 5. Go through the product > stat button On Hand <b>Issue:</b> - A traceback for unknown name field occurs when opening the On hand (stock.quant list view) <b>Cause:</b> - The context `search_view_ref` is passed from the `approval_product_line_view_tree` via the `product_id` field, which interferes with the Quant list view rendering. As a result, the On Hand button fails to display the expected stock information. <b>Solution:</b> - Removed `search_view_ref` from the `product_id` field context in the approval product line tree view. This prevents the context from unintentionally affecting unrelated views i.e. stock.quant list, ensuring On Hand smart button works as expected. <b>opw-4916178</b> Forward-Port-Of: odoo/enterprise#89973
This fix prevents an error from appearing when viewing technical data for Point of Sale product variants using the pricer feature. It ensures the display price field always has a safe default value, improving reliability without changing normal user workflows.
Original PR description
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click…
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click on the Bug icon (top-right corner). 7. Click on Data. **Issue:** A traceback is raised with the error: `Compute method failed to assign product.product(191,).pricer_display_price` The method `_compute_pricer_display_price` was removed in this commit https://github.com/odoo/enterprise/commit/87b1672ac7c1d27cd9eab05138b78f6a9439fea7 , and was reintroduced in a later commit https://github.com/odoo/enterprise/commit/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798 to avoid the AttributeError. **Cause:** The computed field `pricer_display_price` is a type Char and and is non-stored was not being assigned a value inside the compute method. So ORM requires that records to be assigned a value in a compute method. **Solution:** To fix this, assign a default value to `pricer_display_price` inside the compute method to prevent the error. opw-4887318 Forward-Port-Of: odoo/enterprise#88517