Daily updates from Odoo
Navigate
Branch
Friday, April 17, 2026
189 changes
24 changes
Enhancements to existing features
This update simplifies the Balance Sheet in both the generic and US versions of Odoo, making it clearer to distinguish between 'Earnings' and 'Equity'. The changes enhance the chart of accounts to better track the allocation of earnings, providing a more organized view of financial reporting.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259485 Forward-Port-Of: odoo/odoo#256674
This update enhances the accuracy of product imports by making the matching process case-insensitive and using a similarity ratio. Previously, exact matches were required, leading to missed products. Now, a 90% similarity threshold is used to find more relevant matches, improving data import reliability.
Original PR description
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match…
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`. - Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with `Wireless bluetooth speaker battery`), leading to unrelated matches. After this commit: - Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`. - Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names. Technical: - Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive. - Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match. - Added system parameter for configurable product name similarity threshold. task-5951469 Forward-Port-Of: odoo/odoo#258709 Forward-Port-Of: odoo/odoo#252147
Resolved issues and error corrections
This update adjusts how Odoo assigns leads to sales team members. Previously, team members with specific preferences received too many low-probability leads. Now, leads are prioritized by probability, ensuring the most suitable team members receive the highest-quality opportunities, leading to better sales efficiency.
Original PR description
Since we've added the preferred domain field, the leads are firstly assigned to members matching the preffered domain. The issue with this behavor is that a memeber with prefered domain can get a lot of leads with low probability because they match his preferred domain. So we process the leads in the order of probabilities and if it match a preferred domain, it'll be assigned to the member, and if not we choose one without the matching preferred domain. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous oversight that allowed team members to modify user information (like email and phone). It ensures that user data is managed through the correct channels, improving data accuracy and security. This change aligns with best practices for user management within Odoo.
Original PR description
Team member is not the place to edit user information like email and phone. Oversight of odoo/odoo#240202.
This update ensures that table assignments are consistently synchronized across all devices within a POS session. Previously, a waiter selecting an empty table wouldn't update its status on other devices. This fix corrects this issue, improving the accuracy of table availability information for all users.
Original PR description
When a waiter selects a table without adding any items and returns to the floor screen, the table appears as occupied (green) on their device but not on other devices in the same POS session. Steps to reproduce: ------------------- * Open POS session on device A * Open same POS session on device B * On device A: click a table, don't add items, go back to floor * On device B: observe the table does not appear as occupied > Observation: Empty table assignments were not being synced to the server, so other devices couldn't detect the table occupancy. Why the fix: ------------ Also treat orders with a table_id as pending so they sync immediately when a table is opened. The backend already supports this: pos.order can be created with just table_id, and pos_restaurant._get_open_order looks orders up by table_id for table-based sync. opw-5236119 Forward-Port-Of: odoo/odoo#241321
This update fixes a visual issue where clickable scorecards in the spreadsheet dashboard were displaying a default arrow cursor instead of a pointer. Now, scorecards that act as buttons correctly show a pointer cursor on hover, improving the user experience and ensuring consistent interaction.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - The scorecard case was missed when replacing hasOdooMenu with hasOdooLink. - Clickable scorecards were showing the default arrow cursor instead of a pointer on hover. Desired behavior after PR is merged: - Scorecards now correctly use hasOdooLink to determine if they are clickable. - The pointer cursor is displayed on hover when the scorecard acts as a button in dashboard view. Task: [6116584](https://www.odoo.com/odoo/2328/tasks/6116584) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258896
This update clarifies ledger reports by displaying the company name alongside each journal when selecting journals within a journal group. Additionally, the system now includes archived journals in ledger calculations, ensuring more complete financial reporting across multiple companies. This enhancement improves data accuracy and provides a more comprehensive view of financial activity.
Original PR description
In multi-company, when choosing the included journals of a journal group, display the name of the journal's company before the journal name. Also, add the 'active_test=False' context for the journal in the ledgers in order that ledgers also take into account the archived journals. task-6111366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restores the vendor bill auto-complete feature that was temporarily disabled. Previously, users experienced issues with the system's ability to suggest relevant vendors when creating vendor bills. This change ensures a smoother and more efficient process for managing purchase invoices.
Original PR description
This reverts commit https://github.com/odoo-dev/odoo/commit/efb240e04c73593a4a711ddc1bf3bf542925e7d4. Enteprise PR: https://github.com/odoo/enterprise/pull/113827 Upgrade PR: https://github.com/odoo/upgrade/pull/9948 task-6119762
This update removes unnecessary emoji triggering from the suggestion service, streamlining how emojis are offered in emails. The change ensures the emoji plugin, which handles emoji suggestions in HTML, functions correctly, resolving a previous redundancy. This improves the user experience for adding emojis to emails.
Original PR description
Currently the emoji suggestions are triggered by the ":" delimiter, but this is already handled by the emoji plugin since https://github.com/odoo/odoo/pull/243077 This commit removes the redundant ":" delimiter from the suggestion service, and only keeps it for the composer when HTML is not enabled (since the emoji plugin only works in HTML mode). task-6127107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a limitation where users couldn't edit images (resize, crop, etc.) when replacing them on product pages. The change ensures that editing options are only displayed for images that are *not* recently uploaded, streamlining the user experience and preventing unexpected behavior. This improves the visual consistency of product listings.
Original PR description
## Context On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it. ## Issue When uploading a new picture, users can only…
## Context On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it. ## Issue When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size. ## Steps to reproduce 1. Install the *eCommerce* (`website_sale`) app. 2. Create a product and set a picture for it. 3. Go to that product's page in the Website app and open the website editor. 4. Click on the picture and replace it. 5. **The options to transform the picture are not displayed.** ## Cause The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`: https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16 ## Solution We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image: https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173 We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo. On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are: - Description - Tooltip - Transform (*"Transform the picture"*) - Size ## Tests The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it. https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16 ## Options displayed | | Before this commit | After this commit | Previous versions | |---|---|---|---| | **Before replacing the image** | Media, Re-order | Media, Re-order | Media, Re-order | **After replacing the image** | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality opw-5251864 Forward-Port-Of: odoo/odoo#247706 Forward-Port-Of: odoo/odoo#241071
This update fixes an issue where Arabic text on invoices was displayed with incorrectly positioned parentheses in the generated PDF. The change ensures that Arabic characters and their associated parentheses are rendered correctly, regardless of the invoice's language setting. This improves the clarity and accuracy of invoices for users viewing them in Arabic.
Original PR description
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in…
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF. **Steps to reproduce:** 1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر ) 2. Create an invoice with that product 3. Print the invoice PDF in English 4. Observe the brackets are misplaced in the description column **Current behavior:** Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text. **Expected behavior:** Parentheses correctly wrap the enclosed Arabic text. **Cause of the issue:** Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them. **Fix:** Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets. opw-5884712 Forward-Port-Of: odoo/odoo#259039 Forward-Port-Of: odoo/odoo#251190
This update fixes an issue where the average cost calculation in the 'Inventory at Date' report was inaccurate for products using the AVCO cost method. The fix ensures that the average cost is correctly calculated based on actual transactions, preventing discrepancies in inventory valuation. This improves the reliability of stock reporting.
Original PR description
When we open the Stock report at date, we filter out moves anterior to that date and, if the cost method is AVCO, Odoo recompute the `avg_cost` up to that point of time with `_run_average_batch`. However, when iterating over the moves, `move._get_value(at_date)` might return a value calculated from the current standard_price if the move is not associated with any accounting entry or PO/SO. Steps to reproduce the issue: 1. Create a new product with AVCO cost method 2. On the product form, set the cost to 5$ 3. Manually adjust the inventory to 5 units 4. Create a PO and receive 5 products at a unit cost of 10$ > Total value: 75$ > Total quantity: 10 units > avg_cost: 7.5$ 5. Navigate to Stock report and run "Inventory at Date" at current time 6. avg_cost is 8.75$ instead of 7.5$ Ticket: opw-5951072 Forward-Port-Of: odoo/odoo#253659
This update fixes an issue where refund orders paid with eWallet top-ups weren't correctly identified as refunds, leading to incorrect invoice generation. The fix ensures that refund flows, including those using eWallet, are accurately processed, producing the correct accounting documents and tax calculations. This improves the reliability of our point-of-sale accounting.
Original PR description
[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs Refund orders paid through eWallet top-up can have a net total of 0, which made refund detection based only on negative…
[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs Refund orders paid through eWallet top-up can have a net total of 0, which made refund detection based only on negative totals inconsistent. As a result, some refund flows were treated as normal invoices and refund tax/invoice signs were incorrect. Steps to reproduce: ------------------- * Configure an eWallet program in POS. * Create and pay a POS order for one product, then invoice it. * Refund that order and choose eWallet as refund payment method (refund + top-up). * Validate and inspect the generated accounting document. > Observation: The refund flow may not be consistently treated as a refund when the order’s net amount is 0, causing incorrect invoice move type/sign handling and wrong tax booking behavior. Why the fix: ------------ Refund detection now also relies on `refunded_order_id` in key paths: * `_compute_prices`: apply refund factor when order is linked to a refunded order (or already negative), so totals/taxes keep refund semantics. * `_prepare_invoice_vals`: create `out_refund` when the order is linked to a refunded order (or has negative total), ensuring a credit note is produced. * `_prepare_base_line_for_taxes_computation`: consider refund context with `is_refund` or negative total for tax base sign consistency. This keeps existing negative-total refund behavior while correctly handling refund+eWallet cases where the arithmetic total can be 0. opw-5426818 Forward-Port-Of: odoo/odoo#259217 Forward-Port-Of: odoo/odoo#247948
This update fixes an issue where the unit cost of products was incorrectly calculated when considering stock held in internal locations like subcontracting warehouses. The change ensures accurate valuation by properly accounting for all relevant stock locations, leading to more reliable inventory reporting. This resolves discrepancies in reported values.
Original PR description
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can…
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273 2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65 ### Steps to reproduce: - In the settings enable Multi-Steps Routes - Create a storable with an avco perpetual valuation with a cost of 5$ - Click the `On hand` smart button > Update Quantity - Put 1 unit in WH/Stock and 2 units in Subcontracting - Go to Inventory > Reporting > Stock #### > The unit cost of your product is 15$ instead of 5$ - Click on locations on the line and remove the `internal` filter #### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$ ### Cause of the issue: The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines: https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363 ### Additional issue: The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it. opw-5959720 opw-5883980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257103
This update resolves an issue where the chat composer on mobile devices would become unresponsive when the mobile menu was open. The fix prevents the mobile menu from stealing focus from the composer, ensuring users can consistently access and use the chat feature. This improves the mobile user experience.
Original PR description
**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.…
**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open. https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef Steps to reproduce: 1. Open the website in a mobile view. 2. Tap the navbar toggler to open the mobile menu. 3. Without closing the menu, open the chat window. 4. Tap on the message composer text area. → The composer is not accessible. This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard. This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus. Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259486 Forward-Port-Of: odoo/odoo#250294
This update fixes an issue where offline POS orders were incorrectly having their payment dates automatically updated to the current date. Previously, when these orders were imported into the POS system, the payment date would be overwritten. This change ensures that the original, saved payment date for offline orders is preserved, improving order accuracy and preventing potential discrepancies in reporting.
Original PR description
Before this commit, saved orders that were captured offline, would have their payment_date overridden to the current date when they were loaded in the POS. opw-6117966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259114
This update fixes an issue where MyInvois was incorrectly reducing invoice amounts due to pre-payments on individual POS e-invoices. The change ensures the Total Amount Payable accurately reflects the e-document's total amount, aligning with MyInvois requirements and preventing discrepancies.
Original PR description
For individual POS e-invoices, the PrePayment Amount was mapped to the payment linked to the invoice. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document, regardless of prior payments. This commit forces the PaidAmount to 0 for individual POS e-invoices, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-6057187 Forward-Port-Of: odoo/odoo#259339 Forward-Port-Of: odoo/odoo#258824
This update resolves issues with the Windows IoT configuration by aligning it with the Raspberry Pi version. Specifically, it increases the maximum file size allowed for actions and enables both HTTP and HTTPS, ensuring the LNA feature works correctly within Virtual IoT environments. This prevents errors and improves functionality for IoT deployments.
Original PR description
Built installer for testing: https://drive.google.com/file/d/1wF7MCiQox3nAsW9CXg75wsV_Y5fF-5Rw/view?usp=sharing This commit makes the following changes that bring the Windows IoT nginx config in line with the Raspberry Pi version: - The `client_max_body_size` is set to 10MB. This prevents a 413 error from being received when sending large actions to the IoT (e.g. printing a large receipt). - It now listens on regular HTTP as well as HTTPS. This fixes LNA not working with Virtual IoT. opw-6106765, opw-6108700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259635
This update resolves a technical problem where the website's cookie bar incorrectly persisted a value, leading to potential performance issues and errors. The fix prevents the cookie bar from setting a default value when it's closed without user interaction, ensuring a smoother website experience.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 Forward-Port-Of: odoo/odoo#258938
A technical issue causing negative values in the Luxembourg tax report has been resolved. The formula for a specific tax line (226) was incorrectly calculated, leading to inaccurate reporting. This update corrects the formula to ensure accurate tax reporting for Luxembourg companies.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/odoo#259388
This update resolves an issue where the 'Select Store' feature in Click and Collect would fail if a pickup location's address (city or street) was missing. The fix ensures the system handles empty address fields correctly, preventing errors and improving the user experience when setting up pickup locations. This improves reliability for our customers.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137 Forward-Port-Of: odoo/odoo#259397 Forward-Port-Of: odoo/odoo#259164
This update fixes an issue where users couldn't sort sale orders by delivery date. A recent change renamed a field, making the standard sorting function unavailable. This change adds the 'promised delivery' date back to the list view, restoring the ability to sort sale orders effectively.
Original PR description
Version: --- 19.1+ Issue: --- it's not possible to sort sale order list using `delivery date` anymore. After 30b895e3bd93ab3f0c0a86c3fcfd0fc0c3b6fb89, a `delivery_field` field is introduced, and `commitment_date`'s string is renamed to `promised delivery`. The new `delivery_date` is a compute field, hence it isn't sortable. The propostion here is to add `commitment_date` to the list view, in case users want to sort the list using `Promised delivery date`. opw-6112037 Forward-Port-Of: odoo/odoo#259641
This update resolves an issue where double-clicking on a message action menu kept displaying the same menu. Now, double-clicking on a message action will open the browser's standard context menu, providing users with more flexibility and control over actions.
Original PR description
Before this commit, when message actions are displayed from right-click, triggering a right-click on the message again would keep displaying the message actions. Right-click on message to show the…
Before this commit, when message actions are displayed from right-click, triggering a right-click on the message again would keep displaying the message actions. Right-click on message to show the actions is useful in many cases, but sometimes the user wants to trigger the browser context menu. Currently browser context menu is shown on links and when there are some text selection, but there might be some other potential cases where seeing the browser context menu is desirable. In practice users could trigger it through SHIFT + right-click but they are not necessarily aware of it. This commit let double right-click on same message open the browser context menu, so that if users really want to have the browser context menu then doing it twice will show it. Before  After  Forward-Port-Of: odoo/odoo#258699
This update resolves an access error that prevented users from correctly adding TDS entries when working within a branch company setup in India. The fix ensures the system uses the correct company ID for currency calculations, granting the necessary permissions for branch operations. This improves functionality for businesses operating with multiple company branches.
Original PR description
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator**…
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company. * Login from this user . * Create and confirm a vendor bill in the branch company. * Click **TDS Entry** and select any TDS section. **Observed behavior:** * An **AccessError** is raised when selecting the TDS section. **Cause:** * In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`. * For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent. * The user operating in the branch company does not have access to the parent company, triggering an access error. **Fix:** * Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency. * The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights. **Note:** * Regression test is not feasible due to ORM cache behavior: * In tests, `mock` environments share a transaction-level cache. * `compute_sudo=True` fields populate cache with superuser access. * By the time `_compute_amount` runs, values are already cached. * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced. opw-6095312 Forward-Port-Of: odoo/odoo#259091
17 changes
Resolved issues and error corrections
This update corrects an issue where account searches on invoices only worked when searching by name, not by code. Now, account searches on invoices function correctly regardless of whether the user searches by name or code, ensuring accurate results. Additionally, a 'Search more...' option is always visible for Account searches.
Original PR description
Currently, on invoices, the account_id many2one field overrides `name_search` to limit search results based on account types, but that is applied only if the account is searched by name. If the account is searched by code, all the accounts appear in search results which is not intended. This commit fixes that issue. task-6075233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257850
This update fixes an issue where custom snippets created in Website Edit Mode were only available as inner content. Now, snippets can be used both as blocks and inner content, aligning with previous versions. This improves flexibility for users creating website content.
Original PR description
Steps to reproduce: 1. Go to Website > Edit mode. 2. Drag and drop a `Map` from `Inner Content` snippets. 3. Save it as a custom snippet. Current behavior: - The custom snippet is saved only as inner content and does not appear as a block in custom snippets. Expected behavior: - The snippet should be available both as a block and as inner content, consistent with behavior in `saas-18.3`. Issue: - Custom inner content snippets were systematically extracted from `snippet_custom`. As a result, snippets that can serve both purposes were only kept as inner content, preventing their usage as blocks. Solution: - Update the logic to: 1. Keep dual-purpose snippets in `snippet_custom` (block usage). 2. Also add them to `snippet_custom_content` (inner content usage). 3. Remove only inner-only snippets from the block category to avoid display issues. task-6064917 Forward-Port-Of: odoo/odoo#259452 Forward-Port-Of: odoo/odoo#256777
This update fixes a bug that prevented users from using keyboard shortcuts (Tab, Enter, Shift+Tab) to select values within selection fields in list views. Previously, the system prioritized certain key presses, blocking the intended shortcut functionality. Now, users can seamlessly navigate and select values using their keyboard.
Original PR description
Steps: - Open any editable list view (for example sub-list view in sales) - Either it has a selection field or you add it via studio - With two values (for example "true" and "false") - Add a record to your list view - Try to edit the selection field - Popover is opened - You can select any value with a mouse click - You can navigate through values with arrows - You can't select values with `Enter` and `Tab` So list cell in edit mode has a function for all theses hotkeys: - `tab` - `shift+tab` - `enter` - `escape` Because `ListRenderer.onCellKeydown` is called before `hotkeyService.onKeyDown`, if any hotkeys is handled in cell edit mode it will be prevented and the hotkeyService will not propagate it to `select_menu`. That's why arrows are working, because there are not listed in cell edit mode keys. opw-6025476 Forward-Port-Of: odoo/odoo#255029
This update fixes an issue where individual POS e-invoices were incorrectly showing a zero Total Amount Payable. The change ensures that the payable amount accurately reflects the total e-document amount, as required by the MyInvois tax officer and helpdesk. This prevents discrepancies in the data sent to MyInvois.
Original PR description
For individual POS e-invoices, the PrePayment Amount was mapped to the payment linked to the invoice. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document, regardless of prior payments. This commit forces the PaidAmount to 0 for individual POS e-invoices, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-6057187 Forward-Port-Of: odoo/odoo#259339 Forward-Port-Of: odoo/odoo#258824
This update fixes an issue where users couldn't sort sale orders by delivery date. A recent change made the delivery date field un-sortable. This fix adds the 'promised delivery' date back to the list view, allowing users to sort sale orders effectively based on their promised delivery times.
Original PR description
Version: --- 19.1+ Issue: --- it's not possible to sort sale order list using `delivery date` anymore. After 30b895e3bd93ab3f0c0a86c3fcfd0fc0c3b6fb89, a `delivery_field` field is introduced, and `commitment_date`'s string is renamed to `promised delivery`. The new `delivery_date` is a compute field, hence it isn't sortable. The propostion here is to add `commitment_date` to the list view, in case users want to sort the list using `Promised delivery date`. opw-6112037
This update fixes a problem where the Point of Sale system was incorrectly trying to access printer settings. The fix ensures the system correctly identifies and uses available printers, preventing potential errors during sales transactions. This improves the reliability of the POS functionality.
Original PR description
We were looping over non existing `config.printer_ids`. It's either `config.receipt_printer_ids` or `config.preparation_printer_ids`. We now loop over a set containing values of both.
This update simplifies the process of reloading your chart of accounts. Previously, users received a confusing error message, but now a clear warning directs them to the necessary localization settings within the Odoo Apps menu. This change improves user experience and reduces potential frustration.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly. Forward-Port-Of: odoo/odoo#259539 Forward-Port-Of: odoo/odoo#257515
This update resolves issues preventing large actions (like printing receipts) from working correctly on the Windows IoT version of Odoo. Specifically, the Nginx configuration has been adjusted to handle larger file uploads and ensure compatibility with Virtual IoT environments, addressing previous LNA functionality problems.
Original PR description
Built installer for testing: https://drive.google.com/file/d/1wF7MCiQox3nAsW9CXg75wsV_Y5fF-5Rw/view?usp=sharing This commit makes the following changes that bring the Windows IoT nginx config in line with the Raspberry Pi version: - The `client_max_body_size` is set to 10MB. This prevents a 413 error from being received when sending large actions to the IoT (e.g. printing a large receipt). - It now listens on regular HTTP as well as HTTPS. This fixes LNA not working with Virtual IoT. opw-6106765, opw-6108700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259635
This update fixes an issue where the unit cost of products was incorrectly calculated when considering stock held in internal locations like subcontracting warehouses. The change ensures accurate valuation by properly accounting for all relevant inventory locations, leading to more reliable inventory reporting.
Original PR description
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can…
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273 2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65 ### Steps to reproduce: - In the settings enable Multi-Steps Routes - Create a storable with an avco perpetual valuation with a cost of 5$ - Click the `On hand` smart button > Update Quantity - Put 1 unit in WH/Stock and 2 units in Subcontracting - Go to Inventory > Reporting > Stock #### > The unit cost of your product is 15$ instead of 5$ - Click on locations on the line and remove the `internal` filter #### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$ ### Cause of the issue: The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines: https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363 ### Additional issue: The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it. opw-5959720 opw-5883980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257103
This update resolves an issue where the checkout process became unresponsive when using the l10n_br_avatax_sale module with CPF identification. The previous implementation unnecessarily called external tax APIs, leading to errors and a broken confirmation step. This fix removes the problematic API call, ensuring a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259522 Forward-Port-Of: odoo/odoo#256692
This update resolves a technical error that prevented users from selecting a store when the store's address information (city or street) was incomplete. The fix ensures the system correctly handles missing address details, improving the reliability of the Click and Collect feature. This prevents a frustrating user experience and ensures accurate store selection.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137 Forward-Port-Of: odoo/odoo#259397 Forward-Port-Of: odoo/odoo#259164
This update fixes an issue where offline orders were incorrectly having their payment dates automatically updated to the current date when brought into the POS. This ensures that the recorded payment date for saved orders remains accurate, improving the reliability of sales reporting and order management. This change was made to maintain data integrity.
Original PR description
Before this commit, saved orders that were captured offline, would have their payment_date overridden to the current date when they were loaded in the POS. opw-6117966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259114
This update resolves a technical problem where the website's cookie bar incorrectly persisted a value, leading to potential issues with website performance and error messages. The fix prevents the cookie bar from setting a default value when it's closed without user interaction, ensuring a smoother user experience.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 Forward-Port-Of: odoo/odoo#258938
A technical issue in the Luxembourg tax reporting module (l10n_lu) was causing negative values to appear for certain tax lines. This update corrects a formula change, ensuring that credited amounts are displayed accurately as positive values in the tax report. This ensures correct tax reporting for Luxembourg businesses.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/odoo#259388
This update corrects a problem where electronic invoices (FatturaPA) generated with units of measure containing special characters (like m² or m³) failed validation. The fix ensures these units are properly formatted before being included in the XML, guaranteeing compliance with Italian tax regulations and preventing invoice rejection.
Original PR description
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format. ### Steps to reproduce the issue: 1. Download Italian loc + electronic invoicing 2. Activate UoM option in settings 3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3) 4. Invoice this product 5. Create the XML for SdI 6. Check format with Fex > apex is not recognised as a valid character ### Cause of the issue: The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications. ### Reason to introduce the fix: Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules. opw-6075119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259076 Forward-Port-Of: odoo/odoo#257012
This update corrects a bug in the Point of Sale system's tax calculation process. Previously, when a fiscal position lacked tax information, an empty tax list was returned. This change ensures that tax calculations align with the underlying Python logic, improving accuracy and reliability of sales transactions. The fix addresses an internal issue identified in opw-6126210.
Original PR description
When a fiscal position has no tax_ids, the JS implementation was unconditionally returning an empty array. The Python map_tax method only removes all taxes when the taxes themselves carry fiscal_position_ids (the tax-units pattern); otherwise it passes the original taxes through. opw-6126210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259555
This update resolves an issue where mobile self-orders were incorrectly appearing in order lists for different Point of Sale (PoS) configurations within a company. The fix ensures that mobile self-orders are only displayed within their originating PoS configuration, improving order management and preventing confusion. This change enhances the accuracy of order data across our system.
Original PR description
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back,…
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back, open Restaurant, click on Orders tab -> The Bar's self-order shows up in the Restaurant's order list. What's happening ---------------- In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company. But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config). The fix ------- We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method. opw-6068187 Forward-Port-Of: odoo/odoo#258712
2 changes
Resolved issues and error corrections
This update fixes a bug that prevented users from saving appointments when removing the organizer. The issue stemmed from a mismatch in data expectations within the Google Calendar integration. This change ensures smooth appointment creation and prevents errors related to data consistency.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update addresses a broken test within the l10n_pe_edi module, specifically related to unit price rounding for PEPOL compliance. The fix ensures accurate calculations for Peruvian electronic invoicing, maintaining compliance with local tax regulations. This resolves a technical issue that could have impacted invoice accuracy.
Original PR description
https://github.com/odoo/odoo/commit/e79136d04c844f9a0a8c6d0532c65e0cc3a68b8f fixes unit price rounding in peppol. This PR fixes a broken test in l10n_pe_edi opw-6009771
16 changes
Enhancements to existing features
This update replaces the unreliable VIES check with a more robust system using the IAP server. This improves the accuracy of EU VAT ID validation, particularly for French partners, and reduces potential errors during Tax ID changes.
Original PR description
Currently, when changing the Tax ID of a partner that is another EU country, we perform a VIES check to know whether it is valid (i.e. can do intra-com). However, it is often the case that the VIES check fails because of an internal error on their side (timeout, max concurrent update, ...), especially for France. Instead, we will now use the IAP server which stores the validity of a Tax ID for some time. If the IAP server does not have the info (because VIES is down), we will not actively wait. Instead, IAP will perform a push to a webhook on the client database once it has the information. For security purposes, an HMAC is generated and sent to IAP so that only IAP can contact the db with the up-to-date info, and not anyone on the internet that calls this new webhook. There is also a cron for polling for OnPrem instances that cannot be contacted via the webhook. task-5977584 Forward-Port-Of: odoo/odoo#259565 Forward-Port-Of: odoo/odoo#258155
Resolved issues and error corrections
This update fixes an issue where numbers in the domain selector and expression editor were not displayed correctly based on the user's locale settings. Now, numbers are formatted according to the user's local preferences, ensuring a consistent and accurate experience across different regions. This improves usability and data clarity.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. 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#258287
This update fixes an issue where Mercado Pago webhooks with invoice references containing slashes (like INV/2026/00001) were not being correctly processed, resulting in a 404 error. The change allows the webhook to handle these references, ensuring accurate processing of Mercado Pago payments. This improves the reliability of payment processing.
Original PR description
Currently, the mercado_pago_webhook http route only takes into consideration 1 url segment. This means that invoices with references like INV/2026/00001 don't match any defined route and the server returns a 404. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => KO This commit allows references with slashes to be matched by the route by capturing the entire remaining url path including the slashes. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => OK opw-6035161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259378
This update resolves an issue where the Point of Sale app on iOS/Safari would unexpectedly crash due to a lost connection to its local database. The fix prevents crashes when the app goes to the background or when the operating system temporarily closes the database connection. This ensures a more reliable and stable Point of Sale experience for our iOS users.
Original PR description
On iOS/Safari, the WebKit IDB server process can be killed by the OS (e.g. due to memory pressure when the app is backgrounded), resulting in an UnknownError: "Connection to Indexed Database server lost". Additionally, returning from background can leave the connection in an InvalidStateError "closing" state while this.db remains non-null. opw-5121896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256401 Forward-Port-Of: odoo/odoo#253943
This update fixes an issue with invoice rounding related to down payments. The system now correctly uses specific currency fields to ensure the total invoice amount, including taxes, matches the expected value. This improves accuracy when processing invoices with down payments, preventing potential discrepancies.
Original PR description
'total_excluded_currency' is for the base amount. 'base_amount_currency' should be used only when getting the base per tax. When dealing with a down payment, a distortion in the taxes amounts might be introduced to ensure the total of the invoice is exactly the expected one. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent issue prevented activity states from being consistently shared across different tabs within Odoo. This PR corrects a technical typo that was causing this problem, ensuring that activity updates are now properly synchronized across all tabs. This improves the user experience by guaranteeing consistent visibility of activity updates.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 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#258644 Forward-Port-Of: odoo/odoo#255785
This update fixes a test failure in the HTML Editor module caused by relying on a fixed animation frame wait. The change now monitors elapsed time, making the test more reliable across different system speeds. This ensures consistent test results and reduces the risk of false failures.
Original PR description
Waiting for a full animation frame is too dangerous. In the general case, an animation frame happens every 16ms, in which case the power buttons haven't been updated yet since they have a debouncing timeout of 30ms. However, when the runbot is slow, more than 30ms may very well have elapsed between two animation frames. When that is the case, the power buttons are displayed and the test fails. This commit changes the forced awaiting of an animation frame to a waiting pased on the time passed. In the general case, an animation frame will have happened in 20ms, so the test will still catch a regression. When the runbot is slow however, more time might have passed, but not necessarily an animation frame, so the power buttons should still be invisible, making this test more reliable. runbot-242466
This update corrects a rounding issue in the Peppol invoice XML generation, preventing validation errors related to line amount calculations. The fix ensures accurate invoice formatting for Peppol compliance, avoiding potential delays in electronic invoice processing. This improves the reliability of our Peppol integration.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because `priceAmount*InvoicedQuantity != LineExtensionAmount`. **STEP TO REPRODUCE** 1. Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. 2. Generate an XML with peppol, and try validating the invoice. You should have the following error: `[PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount` opw-6009771 Forward-Port-Of: odoo/odoo#255358
This update ensures that dynamic reports attached to invoices in email templates use the correctly configured 'Printed Report Name' instead of a default naming pattern. Previously, invoices used a different email flow that didn't properly apply these names. This fix guarantees consistent and accurate report filenames in email attachments.
Original PR description
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice…
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number). This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself. To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved. The fix will ensure extra dynamic reports follow their configured printed name. Steps to reproduce: 1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. 2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). 3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”. 4. Add the duplicated report under Dynamic Reports. 5. Create a customer invoice and confirm it. 3. Click Send (or Send & Print) to open the email preview. Related Ticket: opw-6058716 Forward-Port-Of: odoo/odoo#259597 Forward-Port-Of: odoo/odoo#259267
This update resolves an issue where invoices weren't automatically marked as paid when using a specific payment setup (default bank account as outstanding account). This prevented invoices from correctly reflecting completed subscription payments. The fix ensures invoices are properly reconciled, streamlining the billing process.
Original PR description
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even…
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even though the payment transaction is 'done'. This type of configuration is usually done when users want to skip the bank reconciliation process, and just create payments without the need to reconcile the payments with transactions. Steps to reproduce: - In Settings, under Sales > Invoicing, disable Automatic Invoice - Activate demo payment method - In the main Bank account add the default account as outstanding account for demo payment method. - Create a sales order with a subscription product - Open Preview - Pay - Go back to the sales order and open the created invoice Issue: The invoice is created and the payment is registered, but the invoice remains 'Not Paid'. Analysis: The invoice and the payment move lines are not automatically reconciled during the post-processing of the transaction, leaving the invoice unbalanced. opw-5869303
This update resolves an access error that prevented users in branch companies from correctly calculating TDS entries on vendor bills. The fix ensures the system uses the correct company ID for currency calculations, addressing a discrepancy between branch and parent company access rights.
Original PR description
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator**…
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company. * Login from this user . * Create and confirm a vendor bill in the branch company. * Click **TDS Entry** and select any TDS section. **Observed behavior:** * An **AccessError** is raised when selecting the TDS section. **Cause:** * In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`. * For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent. * The user operating in the branch company does not have access to the parent company, triggering an access error. **Fix:** * Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency. * The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights. **Note:** * Regression test is not feasible due to ORM cache behavior: * In tests, `mock` environments share a transaction-level cache. * `compute_sudo=True` fields populate cache with superuser access. * By the time `_compute_amount` runs, values are already cached. * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced. opw-6095312 Forward-Port-Of: odoo/odoo#259091
This update resolves an error that prevented users from saving appointments when removing the organizer (user) and setting a Google Meet link. The fix prevents a 'singleton' error that occurred when a method expected a single user record, now it gracefully handles appointments without a designated organizer.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update corrects a technical error in the Danish accounting module (l10n_dk) that prevented accounts without a standard code from being correctly processed. The fix ensures all accounts, regardless of their code, are now handled accurately within the system. This improves data accuracy and functionality for Danish businesses using Odoo.
Original PR description
From https://github.com/odoo/odoo/pull/256541.
```yml
File "/home/.../odoo/addons/l10n_dk/migrations/1.4/end-migrate.py", line 102, in migrate
if len(account.code) < 6:
TypeError: object of type 'bool' has no len()
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258399
Forward-Port-Of: odoo/odoo#258299This update fixes a limitation in Odoo Studio where activity filters (past, today, future) weren't consistently working when the 'use_mail' Chatter feature was enabled. The team added necessary filters to the search view, ensuring users can effectively filter activities based on their timeliness within Studio. This enhances Studio's usability for managing and tracking activities related to records.
Original PR description
Steps to reproduce
==================
- Install studio
- Create a new app
- Create a new model
- Keep the Chatter toggled (use_mail)
- Exit studio
- Create three records, one with an activity in the past, one today and one in the future
- Click on the clock status icon in the top right
- There should be a section with the new model
- Click on 1 Late => every records is displayed
- Same for Today and Future
Cause of the issue
==================
https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77
For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present
Solution
========
We add them to the search view. They are all pretty much implemented the same way in every model.
opw-6069150
Forward-Port-Of: odoo/enterprise#113011This update corrects a discrepancy in how purchase order move lines handle sub-location destinations. Previously, even with a sub-location configured, move lines defaulted to the main warehouse, preventing accurate forecasted quantity updates. This change prioritizes the sub-location, ensuring that quantities are correctly tracked for specific receiving areas.
Original PR description
### **Description of the issue/feature this PR addresses:** **Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However,…
### **Description of the issue/feature this PR addresses:** **Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However, when a user configures a sub-location on the Receipt Operation Type, the picking destination is correct, but the move lines are defaulted to the main warehouse. This mismatch causes the Forecasted Quantity to not increment for the intended sub-location **Solution:** Prioritize the `default_location_dest_id` before falling back to the default stock location opw-6032018 ### **Current behavior before PR:** When confirming a PO, the `location_final_id` on stock moves defaults to the `lot_stock_id`, regardless of the specific destination set on the Operation Type. This causes a mismatch in 1-step receiving flows where a sub-location (e.g., WH/Stock/Test) is intended, since the move lines revert to the root warehouse location (WH/Stock). Thus, the forecasted quantity for the specific sub-location doesn't increment as expected. ### **Desired behavior after PR is merged:** The `_get_final_location_record` method will now evaluate if the Operation Type's `default_location_dest_id` is a child of the warehouse's main stock. If it is, the sub-location is used as the `location_final_id` for the moves and move lines. This ensures that the forecasted quantity reflects the intended destination upon PO confirmation while still maintaining the fallback to the warehouse root for standard multi-step routes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256725 Forward-Port-Of: odoo/odoo#254527
This update fixes an issue where the Italian tax module was incorrectly removing parts of VAT numbers when generating invoices for Spain. The fix ensures that VAT numbers, like A95758389, are accurately exported to the tax agency's XML files, preventing data discrepancies. This ensures compliance with Italian tax regulations.
Original PR description
**Steps to reproduce:** * Install `l10n_it_edi` module. * Create a partner with country **Spain** and VAT `A95758389`. * Create an invoice and send it to the Tax Agency, and download XML. **Observed behavior:** * The exported XML contains `5758389` in <IdCodice> instead of `A95758389` — the first two characters of the VAT are silently dropped. **Cause:** * In `_l10n_it_edi_get_values`, the EU branch that strips the country-code prefix used a bare `else` after the `isdecimal()` check, unconditionally removing the first two characters of any VAT that does not start with two digits. Spanish NIFs like `A95758389` start with `A9` (letter + digit), which is not a country-code prefix but was treated as one, corrupting the value. **Fix:** * Remove country prefix from normalized VAT by `removeprefix(normalized_country)` Instead of removing the first two characters. It will ensure that only the country prefix will be removed. opw-6089198 Forward-Port-Of: odoo/odoo#258626
22 changes
New functionality added to Odoo
This update introduces a new report that calculates the percentage of Saudi employees within a company's workforce. This allows businesses to track their progress towards Saudization goals and comply with local regulations. The report provides valuable insights into workforce composition.
Original PR description
Add a wizard to compute the Saudization percentage, which is the ratio of Saudi employees to the total number of employees. task: 6102086
This update adds a guided tour to help users correctly set up and use Worldline payment terminals when operating kiosks. This ensures seamless payment processing and improves the overall kiosk ordering experience. It addresses a previous issue related to Worldline terminal compatibility.
Original PR description
We add a tour to ensure worldline payment terminals work correctly with kiosk. Forward-Port-Of: odoo/enterprise#113823 Forward-Port-Of: odoo/enterprise#105478
This update introduces a new feature to manage and track employee transportation allowances. Specifically, it supports reimbursement for employees covered under the 200 and 302 joint committees, streamlining payroll processing for these groups. This enhancement improves the accuracy and efficiency of compensation calculations related to transportation costs.
Enhancements to existing features
This update prepares Odoo's maintenance request system for a change in how user assignments are handled. It updates related reports and tests to work with the new Many2many structure for user selection, ensuring continued functionality. This migration improves the system's flexibility and future-proofing.
Original PR description
This commit updates dependent modules to support the field migration from 'user_id' to 'user_ids'. It ensures that reports and tests remain functional with the new Many2many structure. task-5960480
This update enhances the mobile map view by switching to a bottom sheet for displaying pin lists. This eliminates the awkward split-screen effect and provides a much smoother, more intuitive user experience when navigating the map on smaller devices. It's a simple change that significantly improves usability.
Original PR description
Improves the mobile map view design by replacing the split-screen pin list with a bottom sheet overlay. This prevents the map from being abruptly cut in half when the list is toggled, resulting in a much smoother UX. task-6059726
This update streamlines the handling of depreciation models within Odoo, making them more flexible and reliable. Specifically, it removes the requirement for company IDs and resolves conflicts between company and all-company models, ensuring assets are created correctly across all businesses. This improves asset tracking and reporting.
Original PR description
This commit applies several changes to fixed assets and depreciation model: 1. Depreciation model is no longer required to have a company id and the default is set to null. If a depreciation model has an empty company id, it means the depreciation model exists for all companies. 2. If a depreciation model with no company id is used to create an asset, the first general journal for the current company is used to create an asset. 3. In chart template, when loading depreciation models, we first check if it exists as an all-company model. If it exists, then we skip the model creation and update record xmlid to reference all-company model. 4. If company depreciation model conflicts with all-company depreciation model, then journal name is appended to the company depreciation model name. 5. The `car_category` field is removed from the `account.fiscal.category` model. A similar field `is_vehicle_account` already exists in `account.account`. task-6010586
This update simplifies the rental app experience in One-App Free by making key rental options readily accessible and updating demo data to reflect the latest system logic. This ensures accurate testing and a more intuitive user experience for rental configurations.
Original PR description
This pull request introduces key usability improvements for the rental app in One-App Free environments and refreshes the associated demo data across all related modules. Previously, essential rental…
This pull request introduces key usability improvements for the rental app in One-App Free environments and refreshes the associated demo data across all related modules. Previously, essential rental options were hidden from standard menus, requiring technical workarounds to enable basic capabilities. To resolve this, rental menus and settings have been reorganized to expose these core features directly in the base app. Additionally, the pickup and return time fields have been migrated from `website_sale_renting` to the core `sale_renting` module, and the default rental date computation logic has been unified so both backend and frontend flows share the exact same logic. Furthermore, following recent architectural changes in the rental app (#104380), the existing demo data had become outdated and lacked diversity, as most products were limited strictly to daily rentals. This PR comprehensively updates the demo data to align with the new system logic, providing a much wider range of configuration scenarios to ensure robust and accurate testing going forward. task-5865007 This PR also includes https://github.com/odoo/enterprise/pull/109498 (task-6003684) to resolve conflicts and speedup the merge 🚀 See also: - https://github.com/odoo/upgrade/pull/9897
This update simplifies our testing process by replacing outdated tour tests with more efficient HOOT tests. Unnecessary tour tests focused on basic frontend functionality have been removed and replaced with Python tests for order creation flows, reducing test execution time and improving development efficiency. This change focuses on internal improvements to the testing framework.
Original PR description
*: pos_appointment, pos_discount, pos_enterprise_sms_whatsapp, pos_online_payment_self_order_preparation_display, pos_order_tracking_display, pos_planning, pos_restaurant_preparation_display, pos_sale_subscription In this commit: --- - Converted unnecessary tours (that only test basic frontend functionality without backend involvement) to HOOT tests. - Removed tours that are already covered by existing HOOT tests. - Replaced tours that are used only for order creation or preparation ticket flows with Python tests, avoiding the need to run tours. task-6089607 related-https://github.com/odoo/odoo/pull/259340
This update simplifies the configuration of LNA (Local Network Access) for printer models. By consolidating the IoT and ePOS checkboxes, the system now uses a single setting to control LNA, making it easier for clients to manage. Changes ensure consistency between printer settings and IoT Box records.
Original PR description
The printer model has two checkboxes: one for IoT and one for ePOS. LNA is already hard for clients to understand, we then simplify it by removing the IoT one from the printer model, to use the ePOS one for both. If we check `use_lna` for on a printer type "iot", it will check the checkbox on the IoT Box record. Also, if we check/uncheck `use_lna` on the IoT Box record, it will check/uncheck it on the corresponding printer model. Forward-Port-Of: odoo/enterprise#113542 see odoo/upgrade#9921
This update automates the generation of French tax reports by extracting key data and formatting it into a structured XML file. This XML will then be sent to Aspone, streamlining the process of submitting the 'liaisse fiscale' – a crucial French tax return – directly from Odoo. This improves efficiency and reduces manual data entry errors.
Original PR description
This task aims to extract the values of the reports and send them as a structured xml to Aspone task_id-5913160
This update streamlines the process of creating documents from attachments. Users can now automatically create a document in their personal folder with a single click, eliminating the need for a separate selection step. The action button visually indicates if the attachment has already been processed, improving efficiency.
Original PR description
The attachment's "Add to Document" action allows to create a Document from a mail_thread record's attachment. To streamline the user experience, documents are now created in one click: * In the documents bridge folder for the record, if applicable * In My Drive otherwise Clicking the action button again allows to move the document or create a personal copy if the former is not allowed. The action button will also be displayed with a color and a specific icon indicating that the attachment has already been treated. Task-5882406
This update streamlines the payment process, allowing users to pay directly from invoices or payments instead of relying solely on batch payments. This change improves user convenience and encourages more users to connect their bank accounts within Odoo, boosting payment efficiency.
Original PR description
This commit improve the payment initiation flow. The idea is to minimize de steps required to achieve a payment. Before -> everything was done from the batch payment Now -> you can pay directly from a payment or a bill We also put more visibility on the feature, to invite users to connect their bank in Odoo. Linked:https://github.com/odoo/odoo/pull/254896 Linked:https://github.com/odoo/upgrade/pull/9925 task-5977356
This update incorporates changes from a community pull request to enhance the order ticket screen. Specifically, clicking the 'info' button now provides more detailed information, streamlining the process for support staff to manage and resolve customer issues. This improves the efficiency of our support operations.
Original PR description
Adaptations related to the imps made in the community PR. Adapts the click on info button in the ticket screen. task: 6009872 community pr : https://github.com/odoo/odoo/pull/253518
This update simplifies the email marketing process by transforming the 'View Online' option into a user-friendly builder tool within the design section. This change allows users to create more visually appealing email templates directly within Odoo, enhancing the overall marketing experience.
Original PR description
This PR, related to a community PR, improves the UI/UX of the email marketing app. The change in this PR concerns the change of the `View in Browser` (previously described as `View Online`) from a snippet into a builder option under the design tab. Task-5358279
This update optimizes how the AI agent accesses topic information, preventing unnecessary data loading and potential confusion for the LLM. By introducing a 'Load Topic' tool, the agent now only retrieves the specific topics relevant to its current task, leading to faster and more efficient responses. This change improves the overall performance and reliability of the AI agent.
Original PR description
Before this commit, all topics (and their attached tools) are always in the context, even when not needed. With this commit, we add a new tool "AI: Load Topic" that the LLM must use to load the Topic information along with its tools when it needs it. This prevent the context from being loaded with unnecessary information which can confuse the LLM. This commit brings the following changes: - Addition of a new tool "Load Topic" to load the topics upon request. Only the topics that are linked to the agent can be loaded. - The context now contains a list of available topics based on the agent with some basic information (id, title, description) helping the LLM make its decision. - The `tools_context` contains information about the tools that have been enabled for the current session. - The `ai.agent` model now has a direct link to the `ai.tool` model
Resolved issues and error corrections
This update corrects an issue where empty strings were being used in selection fields, leading to potential errors. The team has standardized on using 'False' for clearing selection fields, ensuring data integrity and preventing unexpected behavior. This change primarily impacts payroll and IoT modules.
Original PR description
https://github.com/odoo/odoo/pull/255091 https://github.com/odoo/upgrade/pull/9745
This update corrects a technical issue preventing Odoo from correctly identifying Swedish bank account numbers. The fix adds a necessary code tag to ensure the method is recognized as a model method, resolving a potential error when the bank account widget interacts with the system. This ensures accurate processing of Swedish financial data.
Original PR description
The override of `retrieve_account_type` was missing `@api.model`. (the same as Argentinian and Australian overrides) Since this method is called through RPC from the bank account widget, Odoo expected a model method signature. Without the decorator, the call could fail with a missing `acc_number` argument. Add the missing decorator so Swedish account number detection works properly. opw-6002770 Forward-Port-Of: odoo/enterprise#113841
This update fixes a minor issue with the phone dashboard where the revision ID was incorrectly set. The change ensures the dashboard accurately reflects the latest data by using the correct `START_REVISION` identifier. This prevents potential display inaccuracies in the dashboard.
Original PR description
`revisionId` should be `START_REVISION`. Commit f56e6431ea1e2f66610a833bd3d76107171a6e61 updates phone dashboard but with a wrong revisionId. Task: 0 Forward-Port-Of: odoo/enterprise#113983
This update resolves an issue where appraisers without direct access to the appraisal module couldn't add other appraisers. The fix ensures that appraisers can correctly manage the list of appraisers associated with an appraisal, improving workflow and collaboration. It corrects a logic error related to record comparisons.
Original PR description
When you are an appraiser but don't have access rights on appraisal module. You should be able to add other appraiser to the apprasial. This depends on the field 'is_manager', which is computed and triggered by the modification of appraisers. In the compute of this field we are comparing the m2m employee records and the employee_ids of the current user. This doesn't work in the context of an onchange because we have 'New' records with the origin_id, so we need to use the records ids for comparison which always works. Forward-Port-Of: odoo/enterprise#114042
This update resolves a problem where certain fields within the partner commission report were not being properly filtered, leading to inaccurate sales data. The fix ensures that reports now display the correct commission calculations for sales orders. This improves the reliability of sales reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#113825
Features or functions removed from Odoo
This update removes an unnecessary step in sharing helpdesk tickets through the forum. Previously, sharing a ticket triggered a message post, which is no longer required due to a change in the forum's structure. This simplifies the process and improves performance.
Original PR description
Purpose ======= Remove the `message_post` on the forum post when sharing a ticket in forum, because it no longer inherits from `mail.thread`. Task-3586524
Miscellaneous changes
This pull request contains a series of tests across multiple Point of Sale (POS) modules within Odoo Enterprise. The changes primarily focus on static assets (JavaScript and XML files) and associated test files, ensuring the functionality of order processing, preparation displays, and related features. These tests are a standard part of the development process to maintain the quality and stability of the POS system.
Original PR description
test
14 changes
Resolved issues and error corrections
This update resolves a bug that prevented bill matching from working correctly when a vendor bill line lacked a product definition. The fix ensures that quantity calculations are handled appropriately, avoiding errors and improving the reliability of the bill matching process. This change ensures accurate record keeping and prevents disruptions to the purchasing workflow.
Original PR description
Steps to reproduce: - Import or create a vendor bill with a line that has a unit of measure but no product. - Open the bill and go for the bill matching. Issue: Bill lines without a product have product_uom_id set to False. During bill matching, _compute_product_uom_qty calls _compute_quantity without checking this value, which raises a UserError due to missing or invalid UoM configuration. Solution: Add a check to ensure _compute_quantity is only called when product_uom_id is set. Otherwise, fall back to the original line quantity to avoid conversion errors. opw - 6109513
This update optimizes the workcenter planning process by streamlining how it identifies available time slots. By using a more efficient method to detect conflicting intervals, the system now finds available slots significantly faster, especially for short scheduling durations. This reduces processing time and improves overall planning efficiency.
Original PR description
### Description of the issue/feature this PR addresses: The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method…
### Description of the issue/feature this PR addresses: The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot. This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small. ### Current behavior before PR: The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found. This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times. ### Desired behavior after PR is merged: The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval. This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios. ### Benchmarks Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board. | Work Order Duration | Before | After | | --- |---|---| | 1sec | ~2.5min | <1sec | | 1min | ~2sec | <1sec | ### References opw-5437256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where ISO20022 payments using JPY were failing due to a hardcoded decimal format. The fix dynamically adjusts the amount format to match JPY's zero-decimal currency, ensuring compatibility with banking systems. This prevents payment failures and improves the reliability of JPY transactions.
Original PR description
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3.…
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it using the ISO20022 method on the JPY journal 4. Create a batch payment containing that payment, with Batch Type Outbound, on the JPY journal, with ISO20022 as payment method 5. Validate the batch — the XML file is generated and attached 6. Download it -> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has no decimals. The file is rejected by banks. The fix: -------- Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d: > Generating the xml file for iso20022 always generates the amount with two decimals which is hard coded and can cause error for currencies without decimals for example JPY. > The fix is to have the currency decimal number dynamically set through the currency decimal places field. opw-6103849
This update fixes an issue with invoice rounding related to down payments in the account_edi_ubl module. The system now correctly uses specific currency values to ensure the total invoice amount matches expected calculations, particularly when dealing with initial payments. This improves invoice accuracy and prevents discrepancies.
Original PR description
'total_excluded_currency' is for the base amount. 'base_amount_currency' should be used only when getting the base per tax. When dealing with a down payment, a distortion in the taxes amounts might be introduced to ensure the total of the invoice is exactly the expected one. opw-6120645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a rounding issue in the generation of Peppol invoices, ensuring accurate calculations for line amounts. Previously, the system rounded unit prices, leading to validation errors. This fix ensures invoices comply with Peppol standards and avoids potential shipping delays or payment issues.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because `priceAmount*InvoicedQuantity != LineExtensionAmount`. **STEP TO REPRODUCE** 1. Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. 2. Generate an XML with peppol, and try validating the invoice. You should have the following error: `[PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount` opw-6009771
This update fixes an issue where the Mercado Pago webhook couldn't process invoices with references containing slashes (like INV/2026/00001). Previously, the system would return an error. This change ensures that all invoice references, including those with slashes, are correctly processed by the webhook, improving integration with Mercado Pago.
Original PR description
Currently, the mercado_pago_webhook http route only takes into consideration 1 url segment. This means that invoices with references like INV/2026/00001 don't match any defined route and the server returns a 404. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => KO This commit allows references with slashes to be matched by the route by capturing the entire remaining url path including the slashes. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => OK opw-6035161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259378
This update fixes a security issue where unauthorized users could access asset information linked to invoices. Now, only users in specific accounting groups (read-only or invoice-related) can view assets, preventing potential data access problems. This ensures data integrity and protects sensitive financial information.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#113523 Forward-Port-Of: odoo/enterprise#112890
This update resolves an issue where invoice creation would fail when the 'aggregate' setting was enabled without a defined 'aggregate period'. The change ensures that a valid 'aggregate period' is always required when 'aggregate' is set, improving invoice processing stability.
Original PR description
Previously, if `is_aggregate_limit` was set to True while `aggregate_period` was left empty, it would raise a traceback during invoice creation. Although `aggregate_period` has a default value, it can still be manually cleared. With this commit, `aggregate_period` is enforced as mandatory whenever `is_aggregate_limit` is enabled, preventing such errors.
This update corrects and streamlines French translations for the Enterprise module, specifically for asset and reporting functionalities. Incorrect or outdated translation overrides have been removed, ensuring consistent and accurate language across French-speaking regions (Belgium and Canada). A minor menu item adjustment was also made for the Netherlands.
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#106998
This update resolves a test failure related to a calculated field in the Belgian payroll module (l10n_be_hr_payroll). The fix removes tracking from a specific field, preventing it from being prematurely computed during test runs. This ensures accurate calculations and reliable test results.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#113015
This update fixes a calculation error in the timesheet grid's monthly view for flexible schedules. Previously, it incorrectly displayed a deficit, even with fully completed workdays. The fix ensures accurate required hour calculations by adjusting the formula to account for standard working days.
Original PR description
When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed. ### **Steps to reproduce:** 1) Install Timesheet Grid. 2) Assign…
When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed. ### **Steps to reproduce:** 1) Install Timesheet Grid. 2) Assign a flexible working schedule (40 hrs/week, 8 hrs/day) to an admin. 3) Enter timesheets with 8 hours per weekday for a full month (except Feb). 4) Open the timesheets grid month view. Note: current formula correctly calculates for feb month **((40/7)** * **28) = 160** ### **Observed behavior:** The weekly view shows correct totals, but the monthly view displays a deficit (176 h with -1:08 h), despite all working days being fully completed. <img width="1920" height="366" alt="image" src="https://github.com/user-attachments/assets/df98c3e0-ee89-455d-86c6-7941ba0cb7a8" /> ### **Expected behavior:** The monthly view should correctly calculate the required hours i.e 176 h <img width="1909" height="357" alt="image" src="https://github.com/user-attachments/assets/c082953a-62ad-4096-8774-76d9ff7b3b25" /> ### **Root Cause:** The method [_count_daily_working_hours](https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L82) calculated `full_time_required_hours` for a period by dividing the weekly required hours by 7 (including weekends) and multiplying by the total calendar days in the period at [1]. This gave incorrect required hours for months that have extra weekend days. [1]- https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L115 ### **Fix:** Update the computation to divide the weekly `full_time_required_hours` by `5` (standard working days) and multiply by the actual number of weekdays in the requested period. **Example calculation for the month March 2026:** | | Formula | Values | Calculation | Result | |--------|--------|--------|--------|--------| | Before Fix | round(full_time_required_hours / 7 * (delta.days + 1), 2) | full_time_required_hours = 40, delta.days + 1 = 31 | round(40 / 7 * 31, 2) | **177.14 h** | | After Fix | round((full_time_required_hours / 5) * working_days_in_period, 2) | full_time_required_hours = 40, working_days_in_period = 22 | round((40 / 5) * 22, 2) | **176.00 h** | **opw-5966769**
This update fixes a display issue in grouped list views where the pager incorrectly showed the `count_limit` instead of the total record count. The change ensures the pager accurately reflects the number of records in a group, improving user experience and data accuracy. This was achieved by leveraging existing calculations within the system.
Original PR description
When a pager is needed in a grouped list view and if the total number of record is greater than the `count_limit` (by default equal to 10000); opening the group or pressing the "Next" button will display the `count_limit` in the Pager.
This behavior can be optimized since the `web_read_group` call already computed the total count.
This commit allow the grouped list pager to display the total record count if it was already computed.
Steps to reproduce:
in a list view with 10 records, all in the same group for simplicity:
```xml
<list limit="2" count_limit="8">
<field name="foo"/>
</list>
```
- group the view by "foo" => The pager displays: `"1-2 / 10"`
- click on the 'next' button of the pager => The pager displays: `"3-4 / 8"`
8, the `count_limit` is shown instead of 10, the number of records in the group.
task-6053705This update corrects a technical problem where the cookies bar's state was incorrectly saved, leading to performance issues and potential errors with website responses. The fix prevents the cookies bar from persistently setting an invalid value, ensuring a smoother user experience and preventing issues with website delivery.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Backport of: https://github.com/odoo/odoo/pull/258938 Forward-Port-Of: odoo/odoo#259585
This update fixes an issue where bank statement creation didn't consistently use the specified journal type. Now, when a journal type is set during bank statement creation, the system correctly assigns the appropriate journal, ensuring accurate financial record-keeping. This improves the reliability of bank statement processing.
Original PR description
When a account.bank.statement is created via a action where the journal_type is set in the context this value isn't used to compute the right journal for the account.bank.statement.line/account.move --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
This update fixes an error in how stock valuations are calculated when receiving foreign currency purchases with auto-standard products. Previously, incorrect currency exchange entries were created, leading to inaccurate inventory values. This change ensures that stock valuations accurately reflect the cost of goods, regardless of currency.
Original PR description
This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0 Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will…
This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0 Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since https://github.com/odoo-dev/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7, in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. opw-5905197
This update fixes an issue where the Italian tax module was incorrectly removing parts of VAT numbers when generating XML invoices for Spanish partners. The fix ensures that VAT numbers, like 'A95758389', are accurately exported to the tax agency, preventing data discrepancies and potential compliance problems. This improves the reliability of invoice data transmission.
Original PR description
**Steps to reproduce:** * Install `l10n_it_edi` module. * Create a partner with country **Spain** and VAT `A95758389`. * Create an invoice and send it to the Tax Agency, and download XML. **Observed behavior:** * The exported XML contains `5758389` in <IdCodice> instead of `A95758389` — the first two characters of the VAT are silently dropped. **Cause:** * In `_l10n_it_edi_get_values`, the EU branch that strips the country-code prefix used a bare `else` after the `isdecimal()` check, unconditionally removing the first two characters of any VAT that does not start with two digits. Spanish NIFs like `A95758389` start with `A9` (letter + digit), which is not a country-code prefix but was treated as one, corrupting the value. **Fix:** * Remove country prefix from normalized VAT by `removeprefix(normalized_country)` Instead of removing the first two characters. It will ensure that only the country prefix will be removed. opw-6089198
This update resolves a test issue causing inconsistent results in the web_editor's link popover functionality. The fix ensures the selection is correctly set after a click, mirroring a user's actual interaction. This improves the reliability of the test and the overall stability of the web_editor module.
Original PR description
The popover opening is triggered through click, but there is a selectionchange handler on click that checks if the selection is outside of the link and, if it is, closes the popover. In this case, the click method didn't set the selection inside the link properly because of the presence of \ufeff around the link. The test actually passes by mistake when the runbot was fast, but failed when the runbot was slow, as the selectionchange handler had the time to execute and close the popover. This commit forces the selection to be inside the link after calling click, to be closer to what actually happens when a user click on a link, as opposed to a programmatic click. runbot-161423
This update corrects a bug where a refund payment was automatically generated when an uncaptured Stripe payment was voided. This prevented incorrect financial reporting and ensured accurate transaction tracking. The change avoids unnecessary refund processing for payments that haven't been collected.
Original PR description
When an uncaptured Stripe payment is voided, the system will still generate the refund payment entry. Steps to reproduce: - Configure the Stripe payment provider - enable "Capture Manually" - generate webhook - Create a sales order - Generate a payment link and pay with Card - Back to the SO, click 'Void Transaction' Issue: Refund payment entry will be created even if no payment has been collected for the transaction. opw-5866924
This update fixes a minor inefficiency in the process of importing invoices from XML files. Previously, the system unnecessarily re-searched for products, even after a successful search. This change ensures the import process is more efficient and responsive, reducing potential delays.
Original PR description
### Description: Following this commit[^1], parts of the import of invoices from XML files was improved and batched. However, the logic used to filter products that has been searched was flawed: it checked if a product had already been found, rather than if a search had already been attempted. This caused the code to still trigger a search even if it has been executed previously with the same parameters. ### Reference: opw-5462267 [^1]: 2ca1ebac8d4b026e58c4373a346244b086425ff3