Daily updates from Odoo
Wednesday, December 10, 2025
64 changes · 19.0
New functionality added to Odoo
This update implements new rules for Mexican export invoices (COMEX) where services are involved. Specifically, when the ‘Servicios’ unit code (99) or ‘E48’ is used, certain fields like value and currency must be set to zero. New tests have been added to ensure compliance with SAT guidelines.
Original PR description
According to the official SAT guidelines and the c_ClaveUnidadAduana catalog, if UnidadAduana unit code is "99" (which corresponds to "Servicios") or ClaveUnidad has the value "E48", the following rules apply: - ValorUnitarioAduana must be 0. - ValorDolares must be 0. - FraccionArancelaria should not exist. Add test for COMEX invoices with service target: 19.0 task-5257001
This update introduces a new setting to allow businesses to exclude product references from PEPPOL invoices. This change enhances PEPPOL invoice compliance and flexibility, addressing potential data requirements for specific trading partners. The update includes necessary code changes, tests, and XML adjustments to implement this functionality.
Original PR description
Introduced a new boolean field to control the inclusion of product references in PEPPOL invoices. Added corresponding logic, tests, and XML changes to support this feature. Task-5401660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces support for Hong Kong's eMPF (electronic Money-Purchase Funds) system, enabling companies to generate CSV reports compliant with eMPF regulations. This allows for simplified reporting of employee contributions, facilitating compliance with Hong Kong labor law and avoiding manual file/API integrations.
Original PR description
Implement support for eMPF in Odoo, with the ability to export csv files compliants with the eMPF.
This update adds demo tax data and sample invoices for the Arabic localization (l10n_ar) in Odoo. This allows internal teams and reviewers to quickly test and verify that the legal tax reporting requirements are correctly implemented without needing to set up complex tax configurations. It streamlines the testing process for this important feature.
Original PR description
**Purpose of the PR** This PR introduces demo data to facilitate testing of the legal requirement implemented in v16 and forward-ported to all supported versions. **What it does** - Provides demo taxes (e.g., national, other categories). - Adds demo invoices combining different taxes. **Why** The demo data allows users and reviewers to quickly verify that the correct legal legend is displayed without having to manually configure taxes and create invoices. References: Adhoc task 53768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr CLA PR: https://github.com/odoo/odoo/pull/226715 Forward-Port-Of: odoo/odoo#237932 Forward-Port-Of: odoo/odoo#226938
Enhancements to existing features
This update enables users to send multiple attachments when sending invoices through the Peppol network. The attachments are now embedded within the invoice XML file using a standard ‘AdditionalDocumentReference’ tag, streamlining the process for international transactions. This improves compatibility and efficiency for Peppol-related invoicing.
Original PR description
[IMP] account: multiple embed files peppol This commit allows user to send multiple attachments through peppol. The attachments will be embedded into the xml under the `AdditionalDocumentReference` tags task-5103539 Forward-Port-Of: odoo/odoo#238936 Forward-Port-Of: odoo/odoo#234339
This update enhances Odoo's tax calculations to better handle situations where taxes are based on volume, such as sales of goods by weight or quantity. This change, requested during Odoo Exp 2025, ensures more accurate tax calculations for businesses with volume-based pricing. It impacts the account_tax_python module.
Original PR description
The use case to cover is when you have a volume based tax. Requested during Odoo Exp 2025. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238140 Forward-Port-Of: odoo/odoo#232146
This update adds a new 'Update Document' button within sign templates, allowing users to easily reuse common layouts across multiple sign templates. This streamlines the process of creating sign documents by duplicating a template and swapping in a different PDF, saving time and ensuring consistency.
Original PR description
Adds the 'Update Document' button in the template edition for allowing changing the current document to another pdf by duplicating the current template and replacing the document in the new template. This is a super useful feature for re-using common layouts of sign items between different sign templates. task-5254140
This update enhances the website generator's efficiency by proactively verifying URLs before initiating the scraping process. By checking URL validity and authorization on the IAP server, we prevent unnecessary requests and potential errors, leading to faster website generation. This improves the overall user experience and reduces load on our systems.
Original PR description
This PR adds the client side verification of an url for the request we make to generate a website using the website scraper. **The goal is to filter all the unwanted requests (invalid urls, banned urls) before launching the scraper process.** The check is done on the IAP server, and retrieved on the DB. The reason is that we don't want to send a request directly from the db [as this was already discussed](https://github.com/odoo/enterprise/pull/92724). Since the IAP server is also the one that will eventually do the scraping request, it also makes more sense that it is the one to check (to avoid the case where odooDB has access to an URL and IAP server does not). Previous PR was in master, but since we only change js component, we can modify 19.0 directly. Link : [Master PR](https://github.com/odoo/enterprise/pull/99433)
Resolved issues and error corrections
This update fixes an issue where invoice totals didn't update correctly when changing the product or unit price. The fix ensures that the totals recalculate accurately after these changes, resolving a problem that prevented dynamic updates. This improves the accuracy of invoice calculations.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice with an invoice line - Save the invoice - Change the unit price => The totals should change - Change the product => The unit price and…
**Steps to reproduce:** - Install Accounting - Create an invoice with an invoice line - Save the invoice - Change the unit price => The totals should change - Change the product => The unit price and the totals should change - Change the unit price again **Issue:** After this point, the totals don't change anymore, even if the unit price is changed several times. Only saving the form will adapt the totals correctly. **Cause:** When changing the unit price the first time, a "price_unit "key is added in the onchange values. When changing the product, a "product_id" key is added after the price key. Changing the product triggers an onchange of the price with the price of the new product. However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after. This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals". **Solution:** If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first. opw-5012125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239110 Forward-Port-Of: odoo/odoo#232684
This update corrects a display issue on the Odoo portal where users were seeing outdated document counts. Now, the portal only shows users documents that are currently in their signing sequence, improving the user experience and ensuring accurate document tracking. This prevents confusion and streamlines the signing process.
Original PR description
Version: - 18.0 Steps to reproduce: - Install sign - Upload document. - Add multiple signers - Set a sequential signing order Issue: - When documents require sequential signing, portal users see a banner saying there’s a new document to sign, even if it’s not yet their turn. Solution: - Update the counter to show only the documents that the user can currently sign. Impact: - Portal users now only see documents when it’s their turn to sign. Task-5226240 Forward-Port-Of: odoo/enterprise#98671
This update prevents a confusing traceback error when using Studio to create a menu item for the account.code.mapping model. The fix replaces a technical error with a user-friendly message, ensuring a smoother experience for users creating and accessing this feature.
Original PR description
**Steps to reproduce:** * Install **Accounting** and ensure Studio is available. * Using **Studio**, create a new menu item pointing to the model *account.code.mapping*. * Save the menu and click it to open the corresponding view. **Observed behavior:** * Opening the Studio-created menu triggers a full traceback. **Cause:** * The model *account.code.mapping* overrides `_search()` and raises `NotImplementedError` when no `account_ids` can be extracted from the domain, which is the case when opening the view without filters. * The missing `_search` logic for empty domains was never implemented, and the resulting exception propagates to the UI as a traceback. **Fix:** * Replace the `NotImplementedError` with a user-friendly `UserError` explaining that the view cannot be opened without specifying relevant filters, preventing the traceback and improving clarity. opw-5183909 Forward-Port-Of: odoo/odoo#239076 Forward-Port-Of: odoo/odoo#236665
This update fixes a previous error that prevented shipping rate calculations when a customer partner lacked address information (country, state, and city). The change ensures that the system handles missing location data gracefully, preventing errors and allowing shipping rates to be accurately calculated for all customers.
Original PR description
Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city). **Steps to Reproduce:** 1. Install and…
Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city). **Steps to Reproduce:** 1. Install and configure the **Envia Shipping** module. 2. Create a partner without an address (only name + phone). 3. Create quotation for that partner with a deliverable product (e.g; Conference Chair). 4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**". **Error:** `TypeError - quote_from_bytes() expected bytes` **Cause:** At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised. **Fix:** This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2] [1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593 [2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624 sentry-7063870478 Forward-Port-Of: odoo/enterprise#100734
This update ensures that older IoT boxes running Odoo 19.1 or later will always be upgraded to Odoo 19.0. This prevents issues caused by a change in Python version requirements, safeguarding the IoT boxes from potential malfunctions.
Original PR description
The IoT boxes using image 25.07 or less are running Python 3.11. In Odoo 19.1 the minimum Python version will change to 3.12. In order to prevent IoT boxes from being bricked after checking out, we add a check to make sure that 19.0 will be checked out if the database is using a version of 19.1 or higher. task-5380815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where the system was incorrectly removing outdated sub-channels. The change adds a crucial check to ensure the cleanup process only affects actual sub-channels, preventing unintended consequences and maintaining data integrity. This ensures our email system operates more reliably.
Original PR description
In [1], the `_gc_unpin_outdated_sub_channels` method was updated to avoid unpinning sub-channels multiple times. However, a condition is missing on `parent_channel_id` to restrict this gc to actual sub- channels. [1]: https://github.com/odoo/odoo/pull/238493 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#239248
This update resolves an issue where freezing a spreadsheet containing empty data rows incorrectly reported the data as text. The fix ensures that empty strings are handled correctly when freezing, preventing false positive results in data analysis. This improves the reliability of spreadsheet reports.
Original PR description
Steps to reproduce: - insert a list - expand the list beyond the number of records in order to have ODOO.LIST with no result - add =ISTEXT( <a reference to an empty ODOO.LIST> ) -> the result is TRUE - Freeze and share the spreadsheet => the result of ISTEXT is FALSE in the frozen version task-5360561 opw-5359100 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#239107 Forward-Port-Of: odoo/odoo#237511
This update resolves an issue in the Hong Kong payroll system where the default account for net salary payments was incorrectly configured. The change replaces the problematic account with a new 'Salaries & Wages Payable' account, ensuring accurate payslip generation and payment processing. This improves payroll accuracy and avoids potential payment problems.
Original PR description
Fixes the default account for NET salary rules in the Hong Kong payroll, which is using the wrong account type and causes issues when trying to pay payslips. It is replaced by a new Salaries & Wages Payable account, and we also set it for the structures other than 'Monthly Pay' task-5042786 Forward-Port-Of: odoo/enterprise#100835
This update corrects a bug in the loyalty program's reward system. Previously, rewards weren't triggered when using 'not ilike' product domains. This change ensures that rewards are correctly applied based on product exclusions, improving the accuracy of loyalty program targeting.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a loyalty program; 2. Create a reward; 3. Add a Product domain to the reward containing the `not ilike` operator; 4. Load the POS; 5. Try to trigger…
Versions
--------
- 18.0+
Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied
Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.
Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.
Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])`
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.
For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)
Solution
--------
1. Perform the initial search with `ilike` for both operators
opw-5182818
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235656This update adds a new account for 'Salaries & Wages Payable' within the Odoo Hong Kong localization. This change is necessary to correctly account for payroll liabilities under Hong Kong's NET rules and resolves an existing issue with default data configuration. It ensures accurate financial reporting related to employee compensation.
Original PR description
Adds a new Salaries & Wages Payable account of type current liabilities in order to use it in payroll for the NET rules and solve a misconfiguration in the default data. task-5042786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237884
This update corrects a display issue where product specifications with single values were appearing twice when shown in an accordion format on the website. The fix ensures that specifications are shown only once, improving the clarity and accuracy of product information for customers. This change enhances the user experience and prevents confusion.
Original PR description
Currently, when the product specification is shown in an accordion, single-value attributes are displayed twice, causing duplicate information to appear. **Steps to replicate:** * Install…
Currently, when the product specification is shown in an accordion, single-value attributes are displayed twice, causing duplicate information to appear. **Steps to replicate:** * Install `website_sale` with demo data. * Open Products, pick any product, and add an attribute with a single value. * Edit that product’s website page and set Specification → In accordion. **Observed Behavior:** * Specifications for single valued attributes are shown twice. **Root cause:** * This happens because [1] always shows single attribute values, regardless of the specification display style. **Solution:** * Hide the extra table when accordion is active. **Before:** <img width="1851" height="928" alt="image" src="https://github.com/user-attachments/assets/dbaccc28-dbbb-41df-9a04-b0330479e480" /> **After:** <img width="1858" height="927" alt="image" src="https://github.com/user-attachments/assets/09317662-3d40-4128-a6d3-9f9c0af618c4" /> [1]: https://github.com/odoo/odoo/blob/ac6960dc553088894e688bcc0f4a49245aa02d6c/addons/website_sale/views/templates.xml#L2175-L2195 opw-5382484
This update addresses a requirement from the Belgian Peppol Authority. The system now provides a warning to users attempting to register with the 9925 (BE VAT) method, as this is no longer the standard approach. This ensures users are guided toward the correct 0208 (BCE/KBO) registration for optimal compliance.
Original PR description
The Belgian Peppol Authority wants us to register belgian users with 0208 (BCE/KBO) and not 9925 (BE VAT). It should still be possible to register with 9925 for some edge case, but let's make it clear to our users that this is not the regular path. task-none (feedback from support + TSB) Forward-Port-Of: odoo/odoo#239208 Forward-Port-Of: odoo/odoo#238737
This update fixes an issue where repair order moves weren't properly linked in the inventory reporting system. The change was necessary due to a previous update that removed a key field. The fix ensures that repair order moves are accurately reflected in move history reports, improving data accuracy.
Original PR description
### Steps to reproduce: - Create and confirm a repair order for a storable product - Go to Inventory > Reporting > Moves History #### > The related move line appears without reference ### Issue: The…
### Steps to reproduce: - Create and confirm a repair order for a storable product - Go to Inventory > Reporting > Moves History #### > The related move line appears without reference ### Issue: The issue has been introduced with facf4eba6cd0504aae949c23454c6ffa9eaa9c3f which purpose is was to remove the `name` field of the `stock.move` model. However, prior to saas-18.4, the reference of the move relied on its name: https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 To not lose this reference an override of the `_compute_reference` compute method was introduced for repair orders. But it is currently ineffective since `moves_with_reference` is a set of records and not a set of ides which makes it the method call its super method on every records including the repair orders. opw-5385004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239215
This update addresses a change in Facebook's data reporting, specifically the deprecation of the audience trend metric. We've temporarily adjusted the calculation to rely on total page follows, ensuring continued accurate reporting while a more comprehensive solution is developed. This change ensures the continued tracking of page follower trends.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend,…
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend, because we needed a fix rapidly, and we wasn't sure about unfollow. And indeed, `page_daily_follows` only count for positive value, unlike the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent of `page_fan_removes`... Example of data for a month: ``` page_follows 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 page_follows 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ``` So we now use `page_follows`, so the total value at a given time, and we look for the newest and oldest value (note that if we could do the same for `page_post_engagements`, then we could just make 2 APIs calls for the year stat). Task-5353390 Forward-Port-Of: odoo/enterprise#101625 Forward-Port-Of: odoo/enterprise#100275
This update fixes a flaw in a stock test that caused inconsistent results due to timing differences. The test now freezes time to ensure consistent execution, guaranteeing the test accurately reflects the intended functionality. This improves the reliability of our stock management testing.
Original PR description
In a previous fix in #174442, we ensured that the order of moves when freeing reservation would remain deterministic, even if move dates were the same. In the test however, we didn't make sure that both moves were created at the exact same time, meaning that in some case, a millisecond could pass between the two moves creation, making the later assert checking if both dates are the same wrong, and making the test irrelevant. Now freeze the time at an irrelevant date just to make sure the test always does what it was intended to do. runbot-233470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239229
This update resolves an issue where duplicate contacts were incorrectly flagged as linked to employees, preventing their deletion. The change ensures that contacts are properly linked to employee records, allowing for accurate contact management and deletion functionality. This was caused by a previous update and has been corrected to use the `employee_ids` field for validation.
Original PR description
Steps to reproduce: 1. Take or create a contact linked to an employee. 2. Duplicate that contact. (The duplication won't be linked to any employee) 3. Try to delete the duplicated contact. This behavior was introduced in the commit 834ec2d. Replace the computed boolean `employee` field with direct `employee_ids` check to ensure we're validating against actual linked employee records. opw-5209516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update caused an error when using the AI feature within certain reports (like forecast reports). This fix prevents the error by ensuring the AI functionality doesn't attempt to access a field that isn't available in the 'ir.actions.client' action type. This ensures the AI feature is consistently reliable.
Original PR description
Asking the AI while the user is in the ``ir.actions.client`` action (e.g., forecast report) triggers a traceback. Steps to reproduce the error: - Install ``Inventory`` module - Open any product > Click the forecast report smart button - Click the AI icon from the systray - Ask anything in AI Traceback: ```py AttributeError: 'ir.actions.client' object has no attribute 'search_view_id' ``` https://github.com/odoo/enterprise/blob/ba78913e01f215b44389a5bf0bca0e6886deab1e/ai/models/ai_agent.py#L770-L778 Here, only ``ir.actions.act_window`` actions have the ``search_view_id`` field, while ``ir.actions.client`` does not. So when the ``current_action`` is an ``ir.actions.client``, accessing ``search_view_id`` results in the above error. sentry-6942041136
This update fixes an issue where procurement quantities were incorrectly calculated when the dropshipping module was enabled. The change ensures accurate quantity calculations for sales orders, preventing over-procurement of stock when dropshipping is utilized. This improves order fulfillment accuracy.
Original PR description
Issue ----- Procurement quantities are computed wrong (for non-dropshipped sales) when the dropship module is installed. Steps to reproduce ----- - Enable dropshipping & multi step route - Set…
Issue
-----
Procurement quantities are computed wrong (for non-dropshipped sales) when the dropship module is installed.
Steps to reproduce
-----
- Enable dropshipping & multi step route
- Set delivery rule as MTSO
- Create a product
- Stock of 5
- Add a vendor
- Create a SO
- Sell 6 of the product
- Confirm SO
- Open linked PO and confirm it
- Go back to the SO and change quantity of the product to 8
- Open the second linked PO
> Quantity is 7 instead of 2
Cause
-----
Writing the new quantity triggers `action_launch_stock_rule`
https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/sale_stock/models/sale_order_line.py#L255
in which we call `_get_qty_procurement` to get the 'already handled' quantity
https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/sale_stock/models/sale_order_line.py#L384
The problem is that this function is overriden in `stock_dropshipping`
https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/stock_dropshipping/models/sale.py#L42-L52
Because the condition is true, we use the purchase line's `po_line.product_qty` instead of calling `super()`. Since `po_line.product_qty == 1`, we simply return 1.
With this, we end up creating a procurement of 8 - 1 = 7 units as if we were doing a dropship, instead of the expected 2 units.
-----
Ticket:
opw-5121035A test within the hr_payroll_account module failed when run without the standard demo data. This was due to a missing default account configuration. The update adds a default account to the test environment and corrects the accounting balance, ensuring the test now passes reliably.
Original PR description
Steps to reproduce: Install hr_payroll_account on a fresh db without demo data. Run the test test_payment_hr_payslip. The test fails. Cause: With demo data, the us payroll was installed and with it, the payroll accounts were configured. Without demo data, default account is missing. Fix: Add a default account in the test and fix the amount balance with a new debit rule to balance the credit one. Task: 5386528 Runbot Error: 161615 Forward-Port-Of: odoo/enterprise#101299
This update resolves a technical issue causing errors in the generation of WPS payroll reports for Saudi Arabia. The fix corrects an incorrect use of a function within the payroll module, ensuring reports are now created without errors. This improves the reliability of payroll reporting.
Original PR description
this commit addresses traceback errors occured due to incorrect usage of `_` function. task-5310946 Forward-Port-Of: odoo/enterprise#99789
This update fixes a technical issue where sub-channels were incorrectly being unpinned, leading to unnecessary notifications. The change also prevents unpinning sub-channels if members still have unread messages, ensuring the pin feature functions as intended for accessing important threads. This improves the reliability of notifications and the overall user experience.
Original PR description
Before this commit, outdated sub-channels were unpinned each time the vacuum ran. It occurs because a condition on sub-channel being pinned is missing. In practice, it's not a big deal funtionnaly but leads to useless notifications being sent. While at it, this PR prevents unpins when there are still unread messages in the sub-channel: the pin feature is used to see unread messages on otherwise hidden threads. Forward-Port-Of: odoo/odoo#239242 Forward-Port-Of: odoo/odoo#238493
This update resolves a visual bug where the shape selector would cause unwanted scrolling on the browser window when viewing limited shape categories. The fix adjusts the scrolling behavior to prevent viewport disruption, ensuring a cleaner user experience when the window is small.
Original PR description
**Description of the problem** If the browser window has a limited height, clicking on a shape category in the shape selector scrolls both the shape selector pager (wanted) and the full viewport (not…
**Description of the problem** If the browser window has a limited height, clicking on a shape category in the shape selector scrolls both the shape selector pager (wanted) and the full viewport (not wanted), leading to white bands appearing at the bottom of the viewport. **How to reproduce** 1. Drop `s_picture` snippet 2. Open the background shape selector 3. Reduce the window height until only ~4 rows of shapes are visible 4. Click on "Linear" or "Creative" category 5. BUG: the viewport scrolled **Why the problem happens** When a shape category in the shape selector is clicked, the function `scrollIntoView` is used to bring the first shape of that category into view. By default, `scrollIntoView` scrolls all ancestor scroll-containers (and possibly the viewport) until the desired element is visible. This means that in specific situations the viewport could scroll too. **Fix** The function `scrollIntoView` should support the option `container: "nearest"`, which would force only the first scroll-container to scroll, avoiding scrolling the viewport. However, at the moment this option is not widely supported across browsers [1]. Thus `scrollIntoView` has been removed and its behaviour has been replicated by changing the `scrollTop` property of the `ShapeSelector` scroll-container. [1]: https://caniuse.com/mdn-api_element_scrollintoview_options_parameter_container_option task-5262945 Forward-Port-Of: odoo/odoo#237767
This update resolves a problem in the pos_settle_due tests that were failing due to a hardcoded year. The fix ensures the tests work correctly regardless of the current year, improving the reliability of the testing process. This prevents potential disruptions to the POS settlement functionality.
Original PR description
When running the pos_settle_due tests with faketime, the tour pos_settle_account_due was failing cause of a hardcoded year which would not work on another year. This is now fixed. runbot-error: 234052 Forward-Port-Of: odoo/enterprise#101217
This update ensures that when new partner records are imported into Odoo, they are automatically designated as 'companies.' This correction improves data accuracy and streamlines processes related to account management and EDI billing. It addresses a previous issue where imported partners weren't correctly categorized.
Original PR description
Ensure imported partner records are marked as companies when creating new partners. Task-5353923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239116 Forward-Port-Of: odoo/odoo#238793
This update fixes a bug where updating the quantity of a component in a manufacturing order could incorrectly mark a stock move as 'picked,' preventing further reservations. The change ensures that a move remains reserved until the component's consumption is fully utilized, improving the accuracy of production planning. This resolves a potential issue with inventory management.
Original PR description
Steps to reproduce the issue:
- Create a storable product “P1” with the following BoM:
- Component: - 1 unit of C1
- Update the quantity on hand of C1 to 10 units
- Create a manufacturing order to produce one unit of P1
- Confirm the order → The quantity of C1 is reserved, and the produced quantity of P1 is 0 (expected behavior)
- Update the component's quantity to consume (C1) to 2
- The consumed quantity is set to 0 and the move marked as picked
- Try to reserve the quantities again
Problem:
Since the move is picked, the
new quantity cannot be reserved.
Solution:
Prevent the move from being marked as picked when the consumed quantity is zero.
opw-5152592
Forward-Port-Of: odoo/odoo#236759
Forward-Port-Of: odoo/odoo#231875This update fixes an issue where the LWF report incorrectly included data from previous runs when a department was selected. The fix clears existing report data before generating a new report, ensuring accurate reporting for employees across departments. This improves the reliability of payroll reporting.
Original PR description
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. -…
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. - Download report , all employee will come in report. - Now select any department and download report again. - All employee(It is fetching previous data) + employee from selected department will come in report. Cause: - In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly reset previous lines as a result previous data remains in lines. - When the department is changed, the wizard id remain same, so previously lines added to wizard are coming with new lines. - Using `Command.link()` for new lines is invalid because it requires an existing database record ID, but wizard lines are creating inside a compute method so their IDs are only saved after the flush. Fix: - Since this is a stable version, clear the previously existing lines using 'Command.clear()' before creating new ones. Task - 5366498 Forward-Port-Of: odoo/enterprise#101190
This update resolves an issue where the Czech VAT control statement incorrectly calculated amounts for invoices in foreign currencies (specifically EUR). The fix ensures accurate reporting by using the absolute value of the signed total when dealing with foreign currency transactions, aligning with Czech tax regulations.
Original PR description
With l10n_cz_reports: - Create a currency exchange between CZK and EUR where the EUR is valued at least at twice the amount of CZK. - Create an invoice in EUR, with a line with price_unit 5000 and a tax. - In the CZ Tax Report, in the VAT control statement, the converted amount is found in section B.3, which contains received taxable supplies and provided payments up to CZK 10,000. However, the converted amount of the invoice in CZK is higher than 10,000. In `_report_custom_engine_control_statement`, the amount used to check whether the move should be included in this section uses `amount_total`, which in the case of foreign currency gives the wrong result. If the move is in a foreign currency the total is not in CZK so we have to use the absolute value of the signed total. opw-5080339 Forward-Port-Of: odoo/enterprise#100456
This update resolves a potential issue where upgrading to a newer Odoo version (19.1) could cause compatibility problems with older IoT box hardware. The change prevents automatic checkout of versions above 19.0, ensuring stability and preventing the need for a database re-flash. It also confirms compatibility between the 19.0 IoT Box and the 19.1 database.
Original PR description
To avoid reflashing after a db update to 19.1, which would lead to python version incompatibility (3.12 min but iot box v25_07 and under have 3.10), we now prevent checkout above v19.0. We also ensure that 19.0 IoT Box is compatible with 19.1 db. Task: 5380815
This update enhances the website builder by adding URL autocomplete suggestions when replacing images. Previously, users couldn't easily enter URLs for image replacements, leading to a less efficient workflow. Now, users will receive helpful suggestions as they type, streamlining the image replacement process.
Original PR description
This commit extends the default BuilderUrlPicker by WebsiteUrlPicker for ReplaceMediaOption to enable URL suggestions/autocomplete. Steps to reproduce: - Drop a snippet with an image - Click on the image - Click on the chain icon next to "Replace" button - Type in "Your URL" field - No url suggestion or autocomplete task-5090136
This update fixes a problem where blog posts weren't consistently appearing as published during performance tests due to timing variations. By freezing time during specific test calls, the tests now produce reliable and repeatable results, ensuring accurate performance measurements. This improves the stability and accuracy of our blog performance monitoring.
Original PR description
Some blog post are published with a post_date matching the time the test is run meaning that they are not considered published. We have multiple possibilities when _get_url_hot_query is called: - all call to /blog are executed before the publication date: 9 - some call to /blog are executed after the publication date: 11 - only the last call is executed after the publication date: ~40-50 Using freezetime after the publication date ensures a consistent result This can be easily reproduced by freezing the time on the first calls in _get_url_hot_query and not on the last one. Runbot error [55754](https://runbot.odoo.com/odoo/error/55754) Forward-Port-Of: odoo/odoo#239236
This update fixes an issue where the debit note button was missing on credit notes and refunds. The button was recently moved to the invoice header, but this change only applied to invoices and bills. This fix ensures the button is visible for all invoice types, including credit notes and refunds, which is crucial for operations in regions like Latin America.
Original PR description
The button for debit note is not visible on credit notes and refunds. Since f29c106b57dd6e8ca19ccc2d2479542f202d1c77 the button for debit note has been moved from action menu to the header of the invoice form, but the commit makes it only visible for invoices and bills, while it was also visible for credit notes and refunds before. The button needs to be also visible for CN/refunds as it is necessary for many countries, like latam countries opw-5385273 Forward-Port-Of: odoo/odoo#239019
This update resolves an issue where data records related to deleted models remained in the system, potentially causing errors. The fix ensures that these records are properly removed when a model is no longer needed, improving data integrity and stability. This prevents potential problems and ensures a cleaner system.
Original PR description
When a model is unlinked, the `ir.model.data` related to that model wasn't cleaned up. This leaves dangling records that can generate issues. sentry-6938852090 Forward-Port-Of: odoo/odoo#236615
This update resolves an issue where the demo stock data installation incorrectly used US currency, causing problems when users have databases with different currencies (like EUR). The fix ensures the demo data installation works correctly regardless of the company's currency setting, improving data consistency.
Original PR description
Currently in the `_merge_move_itemgetter` the system call `self.company_id.currency_id.decimal_places`. However the demo data of stock create a database with US currency and some `stock.move` in it. If we have an existing database with EUR for example. The upper call will return a `currency_id.decimal_places` since we have multiple currency. The best solution, would be to split `_action_confirm` to do a loop by company. But it would need a small refactoring and we will do a minimal diff to fix this issue. Using the smallest currency among all the company is not always correct but it's a super edge case and we should probably remove this code since it went to far. Close #230965, #234078 Forward-Port-Of: odoo/odoo#239273
This update fixes a bug that prevented users from deleting subthreads in group chats without encountering an error. The change ensures the system correctly handles the deletion process by clearing the recordlist, preventing errors related to missing data. This improves the stability and reliability of the chat functionality.
Original PR description
Before this commit, in some cases deleting the subthread would result in an error. The `correspondent` field on the thread model would be set to undefined. The deletion would react due to owl and request the `correspondent` value which fails since undefined at that time. Steps to reproduce: - install mail and im_livechat modules - create a group chat (3 users minimum) - create a subthread - delete the subthread This commit aims to clear the recordlist instead of forcing undefined (if possible) therefore making calls to get the value while deleting still possible. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue where calendar event popovers were misaligned, particularly with longer events. The fix enhances the popover's positioning flexibility, allowing for more accurate display. Additionally, the team reverted a previous change and removed an unnecessary code component for improved stability.
Original PR description
Fixes an issue where the calendar event popover was positioned incorrectly for long events displayed in the day scale. The fix introduces a new positioning parameter that allows the popover logic to test a wider range of possibilities, including center positioning, which resolves the identified bug case. Additionally, this commit: - Restores the default calendar popover position back to 'right', as the previous change (https://github.com/odoo/odoo/pull/236503) did not properly address the root issue. - Removes an unnecessary useEffect hook from the Many2ManyAttendeeExpandable component. task-5401647
This update fixes an issue where search suggestions in Odoo (Command Palette, Many2X fields, Settings) displayed escaped HTML entities. The change refines the search logic to now show unescaped HTML entities, improving the user experience and allowing for proper rendering of special characters in search results. This ensures search suggestions accurately reflect the underlying data.
Original PR description
**Before this commit:** Search suggestions **(Command Palette, Many2X fields, Settings)** displayed escaped HTML entities because both the user input and the source data were being escaped before regex matching. For eg: **(e.g. & -> &)**. **After this commit:** Search suggestions now displays unescaped HTML entities. This is achieved by refining the regex to avoid matching characters inside **&...;** sequences. The regex is tailored around the characters escaped by `htmlEscape` in **OWL: ["&", "<", ">", "'", "\"", ""]`**. task-5124883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the automated testing of Odoo's email functionality. Initially, a frequent check was implemented to ensure accurate test results, but this caused significant CPU load. This change reduces the check frequency and focuses it only on specific elements, improving overall test execution times without negatively impacting system performance.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/238747
PR above improves execution time of the `@mail` suite by checking selector every 100ms tick, as sometimes the mutation observer fails to see changes and the contains pass after the 3 seconds timeout, thus wasting time. The affected selectors are the ones targeting the `:value` or with param `{ value }`.
However 100ms tick adds significant CPU load, which is a problem as runbot execution time is quite heavily reliant on CPU load. So while this makes `@mail` test suite faster in ideal condition, this worsen execution time in some cases [1].
This commit minimizes the problem by increasing the tick from 100ms to 500ms, and also limit the tick behavior to selectors targeting `:value` or `{ value }`. That way the majority of the time it relies on mutation observer so doesn't worsen CPU load, and only with value that this uses tick system.
[1]: https://runbot.odoo.com/runbot/build/95207707This update allows regular users to find contacts during VoIP call creation by enabling the search for contact extensions. Previously, this feature was limited to users with elevated permissions due to access restrictions on user extension data. This change improves the usability of the VoIP module for all users.
Original PR description
When a call is created, VoIP tries to associate it with a contact based, among other things, one the contact's extension. However, the extension is stored on the res.users.settings record of other users, which regular users don't have access to. This commit updates get_contact_info to perform the search for the extension in sudo mode, so that regular users also get meaningful results. [Task-5395010](https://www.odoo.com/odoo/project/5778/tasks/5395010)
This update clarifies the ‘Refresh e-Invoices status’ button to only update status information, separating it from the automated process of fetching e-invoice documents. Previously, this button triggered a combined update of status and document synchronization, causing potential delays. Now, document retrieval continues to be handled by scheduled background tasks.
Original PR description
The “Refresh e-Invoices status” button previously also triggered the crons that fetch eArchive and eInvoice sales documents, mixing status updates with document synchronization. This change scopes the button to status updates only. Fetching eArchive/eInvoice sales documents remains handled by their scheduled crons. task-5344128
This update streamlines the process of obtaining Nilvera PDFs for invoices created within Odoo. Previously, a complex system was in place that wasn't functioning correctly. Now, a dedicated cron job automatically fetches the PDF and attaches it to the invoice, ensuring accurate Einvoice documentation.
Original PR description
Commit 2e1b0f16d8732e9450caf9ac313312e7ad42a2b2 extended _l10n_tr_nilvera_get_documents with a flow for invoices created in Odoo (fetch Nilvera PDF + set provider reference). This mixed two distinct…
Commit 2e1b0f16d8732e9450caf9ac313312e7ad42a2b2 extended _l10n_tr_nilvera_get_documents with a flow for invoices created in Odoo (fetch Nilvera PDF + set provider reference). This mixed two distinct flows. Rationale: - The reference from Nilvera is not needed. We also have this data since we are the senders. - _l10n_tr_nilvera_get_documents should only import documents (moves) originating from the provider. - The added logic was never executed because the method skips moves that already exist in Odoo. Changes: - Revert the parts of _l10n_tr_nilvera_get_documents related to Odoo-created invoices. - Add a dedicated cron to fetch Nilvera-generated PDFs for invoices created and sent from Odoo. To do this in stable without adding a new field, the cron targets moves where message_main_attachment_id points to the PDF created by Odoo. Once the PDF from Nilvera is fetched, it is set as the main attachment instead. - Add a button to the list and the form view for invoices to fetch the Nilvera PDF. - Add that PDF in the email attachments. task-5265045
This update fixes an issue where the barcode scanning feature for stock batches wasn't functioning correctly when multiple pickings were involved. The change ensures that moves from different pickings within a batch are handled accurately, preventing errors and improving the reliability of batch tracking. This ensures correct inventory management.
Original PR description
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of…
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of both pickings - Go back to the barcode main screen - Open the batch again > Both pickings have their demand = partially delivered quantity Cause ----- When leaving the page, we trigger https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68 in which we end up merging the moves together https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51 This has been added by 9753c24 (ade0bef in 17.0) The problem is that `_merge_moves` merges all of the moves into the first of `merge_into` https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088 This, however, doesn't make much sense for batches because the moves can be from different pickings. ----- Ticket: opw-5163740 Forward-Port-Of: odoo/enterprise#101630 Forward-Port-Of: odoo/enterprise#100940
This update resolves an issue where requests to the IoT box for customer display functionality were failing due to incorrect data formatting. The PR corrects the data format, ensuring seamless communication between Odoo and the IoT device. This prevents display-related errors and improves the functionality of the customer display feature.
Original PR description
Currently the requests sent to the iot box to use customer display cause and error because of the bad format of the data in the request. This PR formats the data correctly to be sent to the iot box The compatibility for webrtc for the iot boxes in 19.1 isn't necessary as webrtc was removed in 19.1 task-5408081
This update fixes a potential issue where users could inadvertently modify parser rules after the parser was initially set up. This change ensures data integrity and stability by preventing these edits, safeguarding against unexpected behavior within Odoo.
Original PR description
The parser rules cannot be modified once the parser has been instantiated. task-5091744 Forward-Port-Of: odoo/odoo#239046
This update fixes an issue where selection placeholders weren't working correctly within Odoo's HTML editor's table cells. Now, users can reliably select and manipulate content within table cells, including non-editable elements, improving the overall editing experience. This ensures consistent functionality when working with tables in the HTML editor.
Original PR description
### Steps to reproduce: - Create a table inside the Todo. - Insert a banner into any table cell. - Place the cursor inside the banner and press Backspace. - Banner cannot be deleted and no selection placeholders are inserted. ### Description of the issue/feature this PR addresses: - Selection placeholders were not inserted inside table cells. when they contained contenteditable=false nodes. ### Desired behavior after PR is merged: - Table cells are allowed as valid selection placeholder containers. - When a non-editable element exists inside a table cell, placeholders are inserted before and after it. task-5357197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where pickup moves related to rental orders were not correctly linked in the inventory reporting. The change restores the mechanism for associating rental orders with pickup moves, ensuring accurate tracking of rental transactions. This prevents data discrepancies in reporting.
Original PR description
### Steps to reproduce: - Create a rentable, storable product - Create and confirm a rental order for 1 unit of this product - Click on pickup - Inventory > Reporting > Moves History #### > Your…
### Steps to reproduce: - Create a rentable, storable product - Create and confirm a rental order for 1 unit of this product - Click on pickup - Inventory > Reporting > Moves History #### > Your pickup move appears without any reference ### Cause of the issue: The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was: https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257 ### Fix: Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference. opw-5385004 Forward-Port-Of: odoo/enterprise#101670
This update resolves an issue preventing users from exporting their bills. Previously, bills weren't being generated, which blocked the export process. This change ensures that bills are now correctly created and available for export, improving the user's ability to access and manage their financial records.
Original PR description
After this PR: https://github.com/odoo/odoo/pull/235934, clients can't export bills because they were never sent. Allow clients to export bills. Related feedback on task-4946367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238660
This update resolves a crash that occurred when deleting subthreads within group chats. The fix ensures stable thread deletion by correcting a data management issue, preventing unexpected errors and improving chat functionality. This improves the reliability of group chat operations.
Original PR description
Before this commit, deleting a thread in a group chat could lead to the following crash: ``` Cannot read properties of undefined (reading '_proxy') ``` Steps to reproduce: - install mail and…
Before this commit, deleting a thread in a group chat could lead to the following crash: ``` Cannot read properties of undefined (reading '_proxy') ``` Steps to reproduce: - install mail and im_livechat modules - create a group chat (3 users minimum) - create a subthread - delete the subthread This happens because when deleting the thread of group, there are the following side-effects: - it deletes relation `parent_channel_id` - deletion of `parent_channel_id` side-effects to delete subthread again (because deletion in relation may come from parent) - deletion of subthread triggers deletion of members - deletion of member deletes subthread.correspondent since this is being used. While the subthread is being deleted, it's not technically deleted yet, as fields.onDelete() may still need to refer to this record. This is intentional design [1]. However there was a typo in code: code of deletion of record in relation this is being used assumes that the record using it is a proxyInternal, therefore the `proxyInternal[one] = undefined` was expected to work properly. However the deleting records were stored as raw record, and this mistakenly and actually assigned `undefined` instead of clearing the internal record list. Because of this problem, any `Proxy.get()` on this relational field would trigger the crash above. We could fix the PR with `_proxy` on deleting record, but to keep code as fast as possible, this commit instead retrieve the raw record in usingRecord instead, and apply the deletion on internal record list on the raw record. This works with reactivity because even when operations are done on raw record, the function `.delete()` and `clear()` on record list have dedicated implementation to properly make writes on `_proxy` thus notifying reactive change as expected. [1]: https://github.com/odoo/odoo/pull/224912
This update resolves an issue where duplicate bills were inadvertently creating additional assignation rules within the ESG carbon emissions tracking app. The fix ensures that new rules aren't automatically generated when a bill is copied, maintaining data integrity and simplifying the ESG workflow. This prevents potential errors and inconsistencies in emissions calculations.
Original PR description
[FIX] esg: prevent rule creation on copy Steps: 1. Go to the ESG app and create a new Emissions Factor (or duplicate one for sake of ease) 2. Open the Assignation tab and create a rule for Any Account - Any Partner - Mileage 3. Create a Bill and add the Mileage product If you check here, no other assignation rule is created 4. Duplicate the bill 5. Navigate back to the Emissions Factor on the ESG app. A new assignation rule has appeared. Notice that the steps use a product Mileage as example, you can use another one You can also test the steps with different rule configuration, you only need at least one "Any" opw-5350250 https://github.com/odoo/enterprise/commit/bab99c460a93cb4eef959d8dcd2f12e4ebaa07af
This update resolves an issue where updating the available quantity of a tracked product (lot/serial) would sometimes trigger an error related to missing package records. The fix isolates a specific code change to prevent unintended side effects and ensures package records are correctly created and updated.
Original PR description
Steps to reproduce: - Enable lots & packages - Create a tracked product (either lot/serial) - Try to update its available quantity, it will open the quant view - Create a new line, add a new lot/serial number and save its form Issue: A traceback occurs, saying a package record doesn't exist In the `Many2XStockPackageAutocomplete`, we add some custom `onRecordSave` to handle creating package records without name, and still use the name given from the python-side. However, this was done by hijacking `FormViewDialog`, and injected it directly on the class itself, propagating that behavior to unrelated places. Now limits it to a specificly created Dialog class to avoid overspill. opw-5326068 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when downgrading from the latest Odoo version (19.1) to 19.0 while using chat hub data. The fix ensures compatibility between the different data formats used in each version, preventing the system from failing when attempting to load chat windows. This improves stability and reliability for users performing version updates.
Original PR description
Before this commit, when downgrading from 19.1 to 19.0 with chat hub data from 19.1, i.e. chat windows or bubbles that are open, loading web client would crash with following error: ``` KeyError:…
Before this commit, when downgrading from 19.1 to 19.0 with chat hub data from 19.1, i.e. chat windows or bubbles that are open, loading web client would crash with following error: ``` KeyError: 'thread_model' ``` This happens because of mismatch of format of chat hub data in 19.0 and 19.1: - 19.0 identifies channels with model "discuss.channel" and id - 19.1 identifies channels with just id When downgrading from 19.1 to 19.0, it attempts to getOrFetch a thread to server by providing channel id but without passing a model. The getOrFetch of 19.0 looks at thread level, so it cannot guess providing just id means a channel, therefore it crashes due to missing model to provide. This commit fixes the issue by dropping the chathub local storage data if the format of chathub data in local storage is invalid, i.e. the identifying data of opened / closed should necessarily have id and model. If no model is provided like with downgrade from 19.1 to 19.0, then it drops local storage and assumes no chat window or bubbles is open. Task-5223650
This update resolves an issue where the Point of Sale system for Mexican companies was incorrectly flagging the 'Invoice to Public' setting as an error when a customer lacked a country or zip code. The fix adds the necessary field to the ORM, allowing users to correctly set invoices to public without triggering the error. This ensures proper invoice generation for Mexican businesses using the POS.
Original PR description
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice…
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#101275
Forward-Port-Of: odoo/enterprise#99871This update resolves an issue where the bank statement import wizard wouldn't correctly identify the 'Cumulative Balance' field, preventing it from being offered for setup. The fix ensures the wizard accurately matches the balance, allowing users to properly import and manage their bank statements. This improves the accuracy of financial data import.
Original PR description
When importing a bank statements xlsx in a bank journal, the wizard would not match the "Cumulative Balance", not even proposing it for manual setup. Steps to reproduce: - Go to the accounting…
When importing a bank statements xlsx in a bank journal, the wizard would not match the "Cumulative Balance", not even proposing it for manual setup. Steps to reproduce: - Go to the accounting dashboard - On a bank journal tile, in the right corner menu "New > Import File" - Upload a file (there is one attached to the ticket) - Cumulative Balance is not matched This commit adds module.init() that is skipped in the "onWillStart" override (it's present in the parent onWillStart). This has for consequence that the "bank_stmt_import" key is now present in the context when get_fields_tree() from Base_ImportImport is called, allowing the addition of missing field. See https://github.com/odoo/enterprise/blob/19.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L18 This commit also adds a check to only add debit & credit in the added field list if they are not actual field on the bst line model (see: https://github.com/odoo/enterprise/commit/af863c5a53d0ab50fe67cb9ea910391d4a1979dd) This commit also checks that those fields are only added when the model is account bank statement line (only useful in this case). opw-5222326
This update resolves a problem where invoices generated in Arabic were sometimes printed incorrectly, with missing logos or repeated headers. The fix reduces the number of invoices processed at once, allowing the printing software to render them properly. This ensures consistent and accurate invoice printing for all customers.
Original PR description
Repro steps: 1. Create a customer whose language is Arabic 2. Create 16 or more invoices for that customer 3. Send these invoices together all at once Issue: PDFs generated for the invoices are strange, some have missing logo in the header, while others have the header repeated multiple times on the page. Root cause: wkhtmltopdf does not have enough time to render all these PDFs at once, so it fails to render them properly leading to these half-rendered PDFs. Solution: This commit solves this issue by reducing the number of invoices that the cron processes at once from 20 to only 10 (the default of the function _cron_account_move_send). This would ensure that wkhtmltopdf has enough time to process and render a batch of invoices at once. opw-4997495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236810
This update resolves a technical issue where validation errors in the Point of Sale (POS) system weren't being properly communicated. The fix ensures that errors detected during validation are correctly passed along, preventing the system from incorrectly proceeding with payment processing. This improves the reliability of the POS system and ensures accurate financial reporting.
Original PR description
This PR is related to https://github.com/odoo/enterprise/pull/101365. In the above PR, a l10n test fails because an error is not correctly propagated by the method overriding `finalizeValidation`. In fact, the method `OrderPaymentValidation.shouldHideValidationBehindFeedbackScreen` requires the return value of `finalizeValidation` to determine whether an error occurred or not. https://github.com/odoo/odoo/blob/9e04aadb83d482d05fc2fa66fa3c3bebb6ac1528/addons/point_of_sale/static/src/app/utils/order_payment_validation.js#L96-L99 In the methods overriding `finalizeValidation`, if the return value is not propagated, the potential error is lost and the `shouldHideValidationBehindFeedbackScreen` will attempt to move onto the next screen anyway. (related to) opw-5171035
This update improves the way the AI assistant provides information by automatically adding clickable links to the sources used for each response. Previously, the AI didn't clearly indicate where its information came from. Now, users can easily access the original documents referenced within the AI's answers, enhancing trust and transparency. This also ensures the AI respects user access permissions for these sources.
Original PR description
## Summary: This PR introduces `_get_llm_response_with_sources` to correctly parse the LLM's output format, which includes inline `[SOURCE]` for any claim it mentions, containing attachment IDs of the sources used. The method is responsible for: - Processing the raw LLM message and adding clickable sources numbers for the sources used for the answer. - Fetching the associated `ir.attachment` records based on the IDs and linking their sources' urls to the response. task-id-5153916
This update resolves an issue where AvaTax processes would fail if orders lacked at least one line item. This prevented tax calculations and related workflows. The fix ensures that AvaTax only attempts to retrieve tax information for orders with valid line items, improving data accuracy and preventing disruptions.
Original PR description
Calling Avatax without lines results in an error and blocks flows: ``` Odoo could not fetch the taxes related to MXXX - SOXXX/XXX. Please check the status of `Sales Order XXX` in the AvaTax portal.…
Calling Avatax without lines results in an error and blocks flows: ``` Odoo could not fetch the taxes related to MXXX - SOXXX/XXX. Please check the status of `Sales Order XXX` in the AvaTax portal. Transactions must have at least one line. ``` There are various cases this can happen: 1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1], 2/ if you put the `end_date` of a subscription before the `next_invoice_date`, then none of the lines are considered invoiceable [2] and you get the error when viewing the subscription in the portal This commit filters out orders without lines. It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually. [1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159 [2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475 opw-5214609 opw-5247727 opw-5311132 opw-5385960 Forward-Port-Of: odoo/enterprise#101643