Monday, January 19, 2026
50 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue preventing users from editing event organizers (like 'My Company') within the website editor. The problem stemmed from an incorrectly formatted domain string being passed to the system, causing an error. This fix ensures the website editor functions correctly when editing event details.
Original PR description
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed. **Steps to reproduce:** 1. Install `website_event`…
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.
**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.
**Error:**
`ValueError: Domain() invalid item in domain: ')'`
**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]:
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|',
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```
This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example:
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd',
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r',
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'",
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n',
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```
Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.
**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.
[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109
sentry-6916986959
Forward-Port-Of: odoo/odoo#238825This update removes a restriction that prevented users from inserting records into lists grouped by many2many fields. The previous limitation was unnecessary and blocked functionality without a clear reason. This change ensures users can now seamlessly insert records from these grouped lists.
Original PR description
When we introduced the record-specific insertion from a list, we added a limitation on lists grouped by many2many fields but this limitation makes no sense, it only blocks the users without any clear reason. Task: 5267035 Forward-Port-Of: odoo/enterprise#103869 Forward-Port-Of: odoo/enterprise#103161
This update adjusts the size of 'looking for help' timers in live chat conversations on the discuss sidebar. The change makes the overall appearance of discussion items more balanced and visually appealing. This improves the user experience by creating a cleaner and more organized chat interface.
Original PR description
Timers on "looking for help" live chat conversations on discuss sidebar were slightly too big. This commit reduces the size to make the overal text content of a discuss item more balanced. Before / After <img width="296" height="100" alt="Screenshot 2026-01-16 at 16 58 50" src="https://github.com/user-attachments/assets/32d8e304-c00f-4d2f-bcb9-3b58be7f01c4" /> <img width="298" height="99" alt="Screenshot 2026-01-16 at 16 58 57" src="https://github.com/user-attachments/assets/2cc6fff7-8613-4b56-b44c-22ad72738286" />
A technical error occurred when only the l10n_be_hr_payroll module was installed. This update corrected a configuration issue by moving a field to the appropriate module, preventing a build error. This ensures the Belgian payroll functionality operates correctly.
Original PR description
A traceback about bike_id occurs when only installing l10n_be_hr_payroll. The field bike_id is in the fleet bridge of the belgian payroll. The field is already present in the _get_whitelist_fields_from_template method in that module. Removing the field from the l10n_be_hr_payroll method solves the issue. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/234856 task-5504273
This update enhances how users manage their consent for online account synchronization. Previously, there was a technical issue that prevented consent management, now a message is displayed to allow users to control their data sharing preferences. This change improves data privacy and aligns with evolving regulations.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#104519 Forward-Port-Of: odoo/enterprise#102428
This update fixes an issue where receiving products with negative quantities (e.g., due to returns) caused incorrect average cost calculations, resulting in negative inventory values. The change ensures that the standard cost is updated to the last receipt cost when a product's quantity is negative, preventing inaccurate valuation and improving inventory accuracy.
Original PR description
## Issue When doing a receipt with a different Unit Cost than the current one in negative quantity, the average cost would become aberrant. ## Steps to Reproduce - Create product P, Average Costing method, cost at 0 - Create & Validate a delivery for 10 unit of P - Create & Confirm a Purchase Order for 5 Units of 0 at *10 / Unit - Receive the 5 Units ==>> The product standard cost becomes $-10 ! This is because the system sees -5 Units on hand for a total of $50, and do the average. In Odoo 18, the Delivery would have been reevaluated to the receipt value, so the total value after the receipt would have been $0 for -5 Units. ## Solution When the product quantity is negative, we use the cost from the last receipt as the new average cost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243813
This update resolves an issue where the 'Other Input' section of the Payroll app displayed trailing zeros for negative salary attachment counts. The fix adjusts a widget to properly handle negative values, ensuring accurate reporting of negative amounts. This improves the clarity and reliability of payroll data.
Original PR description
Steps to Reproduce: - install Payroll app - create an employee and create a salary attachment. - check the negative value for salary attachment - generate a payslip Issue: - In "Other Input" section, salary attachment count displays value with trailing decimal zeros for negative amounts. Reason: - The field is using the widget float_without_trailing_zeros which should remove the extra decimal zeros but it doesn't work when the value is negative. Solution: - Fix the regular expression in the float_without_trailing_zeros widget to handle negative values and properly remove trailing decimal zeros. task-5477466 Forward-Port-Of: odoo/odoo#243074
This update addresses several minor issues within the l10n_hr_edi module, primarily focused on improving the reliability and user experience of invoice processing. Specifically, it enhances error handling related to fiscalization status checks, improves multi-company API support, and clarifies settings for Company BUs, ensuring smoother invoice generation and approval workflows.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
A technical issue within the VoIP functionality's test process was causing a tour to fail when using demo data. This commit corrects the tour by ensuring it selects the correct contact associated with the call, resolving the problem and improving the reliability of the test.
Original PR description
`call_activity_chatter_link` tour fails when test contains demo data. When contains demo data, the test select a wrong contact in Contact tab. In this commit, we change to select the first call in Recent tab to ensure this is the contact of the call we just made.
This update resolves a problem where scanning barcodes on picking orders with kit product variants would cause an error. The fix ensures that packaging information for these variants is correctly captured during barcode scanning, improving the accuracy of inventory tracking.
Original PR description
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration.…
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration. 2. Create a product, that as a least 2 variants. 3. Add a packaging to one of the variants. 4. Create a BoM for created product (kit type). 5. Create a picking order for the variant with packaging. 6. Print the picking operation to scan the code through barcode. 7. Go to barcode and try to scan it, this will trigger the traceback. ### Cause of the issue: Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data: https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91 _get_stock_barcode_data will obtain the packaging methode for the products. https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16 since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information. ### Fix: We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids: https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441 our fix will allow for packaging in the variant to be considered when there is more than only one variant. opw-4852875 Forward-Port-Of: odoo/enterprise#103860 Forward-Port-Of: odoo/enterprise#87867
This update fixes an issue where Odoo incorrectly exported negative discounts in Peppol BIS 3 invoices. The change ensures that negative discounts are now correctly classified as surcharges, aligning with PEPPOL standards and preventing calculation errors. This ensures accurate invoice generation and compliance with international trade regulations.
Original PR description
In Peppol BIS 3 (UBL 2.1), negative discounts are logically treated as Surcharges (Charges) rather than Allowances. Previously, Odoo exported negative discounts as an Allowance with a negative amount and a numeric reason code (95). This violated: BR-CL-20 / PEPPOL-EN16931-CL003: Coded charge reasons must belong to the UNCL 7161 (alphabetic) list when ChargeIndicator is 'true'. PEPPOL-EN16931-R120: The line net amount calculation failed due to the negative sign in the calculation. Solution: Dynamically toggles ChargeIndicator based on the discount sign. Swaps AllowanceChargeReasonCode to 'ADK' (Surcharge) for negative discounts. task-5432024 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#241070
This update corrects a missing piece of information required for Chilean SII (Service de Impuestos Internos) compliance within the Odoo Enterprise system. Specifically, the regional office for the Alto Hospicio area has been added, ensuring accurate reporting for businesses operating in that region. This ensures compliance with local tax regulations.
Original PR description
Oficina Regional Alto Hospicio Comuna Alto Hospicio Región Taracapá Forward-Port-Of: odoo/enterprise#102712
This update fixes an issue where the POS product information popup only displayed the first tax applied to a product. Now, the popup correctly shows all taxes associated with the product, separated by commas, providing customers with accurate tax details. This improves the user experience and ensures accurate pricing information.
Original PR description
Before this commit: --- - The POS product info popup displayed only the first tax from `tax_details`, which meant multiple applied taxes were not visible. - The logic fetched a single tax name instead of all tax applied to the product. After this commit: --- - The POS store sends a full list of tax names instead of a single name. - The popup template displays all tax names, comma-separated. task-5406826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239813
This update resolves a problem where customers couldn't change product selections in the Point of Sale configurator when specific attribute exclusions were set. The issue was previously fixed but reintroduced. The fix removes the code that was incorrectly disabling options, allowing customers to freely select product combinations.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241259
This update resolves a technical issue causing duplicate entries in the Accounts Coverage Report. The fix ensures accurate reporting by ignoring identical report lines with the same name and code, improving data reliability. This change primarily impacts the reporting functionality within the Enterprise module.
Original PR description
Reproduce the bug: -Install Ireland(ie) reports -Enable debug mode -Go to Reporting>Balance Sheet>Accounts Coverage Report -The generated sheet should have false positive duplicates error Fix: Ignore the report lines that has the same name and the same code task: 5373732 Forward-Port-Of: odoo/enterprise#101311
This update corrects a bug where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. Previously, the system didn't check if the project was linked to an optional product. Now, the quotation is confirmed without project creation when ordering zero units, ensuring accurate invoicing and order management.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118 Forward-Port-Of: odoo/odoo#240608
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503 Forward-Port-Of: odoo/enterprise#103218
This update ensures that newly created General(MISC) entries in the accounting system automatically have ‘no follow-up’ enabled. This simplifies the tracking process for these common transactions and reduces the risk of unnecessary notifications. It's a minor, technical adjustment to improve efficiency.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244309
This update fixes an issue where cash order creation in Point of Sale was missing essential information like session ID, company ID, and user ID. This change ensures that cash orders are accurately recorded in the accounting system, improving financial reporting and data integrity. The fix was verified through internal testing and aligns with standard Odoo practices.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244287
This update fixes an issue where sorting of picking records was not functioning correctly due to a technical detail in how Odoo compares related data. The change ensures that picking records are sorted accurately, improving the reliability of inventory management processes. This resolves a potential inconsistency in how the system identifies and orders related records.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512 Forward-Port-Of: odoo/enterprise#104561
This update fixes a minor issue where the employee onboarding tour sometimes finished prematurely, leaving the form in an incomplete state. This prevented users from fully completing the tour and resulted in a confusing error message. The fix ensures the tour waits for form autosave, guaranteeing a clean and successful completion.
Original PR description
This commit fixes an indeterministic error in the hr_salary_calculator_tour where, sometimes, the last tour's steps finish too quickly and doesn't wait for the form's autosave (triggered by the employee autocomplete selection) to complete, leading to a "Tour finished with a dirty form view being open" error. This is kind of a follow-up of https://github.com/odoo/enterprise/commit/5497e947cdfa242c090a3d77d900375bfb067b0f runbot-237794
This update corrects a bug where invoices could be incorrectly linked to DIAN documents due to connection issues. When a DIAN rejection error occurs, the system now verifies key invoice details (customer, date) match the DIAN document before linking, ensuring accurate tracking and compliance.
Original PR description
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian…
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian localization with valid DIAN credentials - Create an invoice for a Colombian customer - Confirm the invoice - Send the invoice to DIAN - Cancel and delete the invoice - Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice - Confirm the invoice - Send the invoice to DIAN **Issue:** A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN: "Regla: 90, Rechazo: Documento procesado anteriormente." It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected. In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue. However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document. It results of having an invoice that is linked to an incorrect document in DIAN. The customer, date and other info, completely different. **Solution:** When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo. opw-5095212 Forward-Port-Of: odoo/enterprise#99936
This update ensures that live chat and member lists automatically open by default, providing a better user experience. Previously, opening one panel would disable the other. Now, the system intelligently manages panel visibility to always display the most relevant information, prioritizing the live chat panel by default.
Original PR description
Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa. This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel. This commit fixes the issue as follow: - auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible - closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations Task-5496830 [1]: https://github.com/odoo/odoo/pull/238472
This update resolves a technical issue related to how live chat and WhatsApp information is combined when creating support tickets. Specifically, the system now correctly merges member and live chat details, ensuring a more seamless and accurate ticketing process. This enhancement improves the overall efficiency of our helpdesk operations.
This update fixes an issue where products created through the website automatically appeared as published, even without a category assigned. The fix removes a setting that forced publication and a related configuration, ensuring products remain unpublished until a category is selected, aligning with the user's expected experience. This improves the consistency and usability of the website's product creation process.
Original PR description
**Description:** Products created from the website frontend were automatically published even without a category assigned, contradicting the "Unpublished" placeholder expectation. The issue had three root causes: 1. JavaScript (new_content.js) forced default_is_published: true 2. XML action context contained website_published: True 3. Both caused products to be published regardless of category **Fixed by:** - Removed default_is_published from JS product creation handler - Removed website_published from action context. **After this PR:** Now products remain unpublished until a category is assigned, matching the intended UX indicated by the placeholder text. opw-5408903 SEE ALSO: Enterprise PR:https://github.com/odoo/enterprise/pull/103778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244067 Forward-Port-Of: odoo/odoo#242779
This update ensures the website's product barcode lookup feature accurately reflects a recent change in Odoo. Specifically, the test now correctly handles scenarios where products created through the website aren't automatically published if a category isn't selected, aligning with a community update.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#104491 Forward-Port-Of: odoo/enterprise#103778
This update fixes an issue where loyalty points weren't accurately adjusted when a customer reduced the quantity of a free, loyalty-rewarded product. Previously, decreasing the order quantity didn't correctly update the points spent. The fix ensures that loyalty point calculations are recomputed when rewards are modified, maintaining accurate tracking of customer loyalty benefits.
Original PR description
When decreasing the quantity of a product that was awarded for free using loyalty points, the points spent were not updated accordingly. Steps to reproduce: ------------------- * Create a loyalty program that grant 1 free product A for 1 point * Create a loyalty card with 3 points for partner A * Open PoS and make an order for partner A * Just claim the 3 free products A using loyalty points * Decrease the quantity of product A from 3 to 2 > Observation: The points spent were not updated accordingly. It should be 3 - 2 = 1. Why the fix: ------------ We need to recompute the loyalty programs when the quantity of a reward is changed. This was not done if the changes happened in `_updateRewardLines`. We now track if changes happened in this method and we call `orderUpdateLoyaltyPrograms` if needed. opw-5177593 Forward-Port-Of: odoo/odoo#242816
This update resolves a sporadic issue where the quotation signing tour occasionally failed to complete correctly. The fix adds a deliberate pause within the tour to ensure all interactions have finished loading, resulting in a more reliable and consistent user experience for creating quotes.
Original PR description
This commit fixes the flaky quotation signing tour in sale_management by adding an explicit step to wait for interactions to fully load before proceeding with the next steps. runbot error-224021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242848 Forward-Port-Of: odoo/odoo#242746
This update resolves an issue where the HTML editor would crash when attempting to remove formatting (specifically color) from a cell after text had been deleted. The fix ensures that the color is correctly removed without triggering an error, improving the stability and usability of the editor. This was a minor bug impacting the functionality of a core feature.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243976 Forward-Port-Of: odoo/odoo#241829
This update fixes an issue where the Netherlands localization incorrectly created duplicate fiscal positions. The change removes the redundant position and properly configures the NL Domestic fiscal position, ensuring accurate reporting for Dutch businesses. This ensures compliance with Dutch tax regulations.
Original PR description
Installing the Netherlands localisation creates two Domestic fiscal positions, both incorrectly configured. This commit removes the empty duplicate fiscal position and properly defines the NL Domestic fiscal position by setting the Country Group, leaving Country empty, and disabling VAT requirement. task-5489829 Forward-Port-Of: odoo/odoo#244183
This update corrects an issue where Odoo incorrectly displayed a 'Resume' prompt after successfully importing large CSV files in batches. The fix ensures the 'Resume' prompt only appears when a batch is truly incomplete, improving the user experience and preventing unnecessary prompts. This resolves a minor annoyance for users importing sizable datasets.
Original PR description
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce:…
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce: 1. Create a CSV file with enough records to trigger at least 2 batches 2. Go to any list view and select "Import records". 3. Upload the file and click "Import". 4. Wait for the import to complete. 5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears. The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes. * In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated. * If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch. * `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value. This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`). opw-5343837 Forward-Port-Of: odoo/odoo#241490
This update fixes an issue where reports were displaying unit prices with incorrect decimal precision. The change removes a technical setting that was overriding the configured Decimal Accuracy, ensuring reports now accurately reflect the product's price to the specified number of digits. This improves reporting accuracy for financial data.
Original PR description
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue:…
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue: The decimal precision of the unit price is not respected in the report. Cause: The unit price field in the report uses the `monetary` widget, which ignores the Decimal Accuracy configuration and enforces currency precision instead. Solution: Remove the `monetary` widget from the unit price field in the report so that Decimal Accuracy is applied correctly. Before: <img width="570" height="97" alt="image" src="https://github.com/user-attachments/assets/dda22b25-0ade-40ae-b585-c6251ba89c89" /> After : <img width="584" height="87" alt="image" src="https://github.com/user-attachments/assets/b51d3040-e7b5-41d6-bdd9-7ec799b8005d" /> opw-5418665 Revert [PR #224219](https://github.com/odoo/odoo/pull/224219/files#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bR201) to the original implementation so that the configured Decimal Accuracy is correctly applied in reports as other apps i.e. Purchase or Account Forward-Port-Of: odoo/odoo#241255
This update resolves a test failure that occurred when the current date was in 2027. The issue stemmed from subscription end dates being set to December 31, 2026, causing a system error. This fix ensures the subscription logic functions correctly regardless of the year.
Original PR description
Before this commit, the test was failing if today date was in 2027. it occured because the end_date of the subscription was on the 31 of December 2026. As a result, when running in 2027, the _create_recurring_invoice method would close the order. runbot-id-237658 Forward-Port-Of: odoo/enterprise#104604
This update enhances the security of our connections to external services by allowing us to securely verify server identities using certificate stores. Previously, our system struggled to utilize certificate verification effectively due to limitations in the underlying software. This change adds support for managing CA certificates, strengthening security and reliability.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#244386 Forward-Port-Of: odoo/odoo#238717
This update fixes inaccuracies in the Spanish balance reports, specifically for 'pymes' and 'completo' business types. The changes ensure that financial data is correctly calculated and balanced, addressing previous errors related to section sums and specific account entries. This improves the reliability of financial reporting for Spanish-speaking customers.
Original PR description
Waking up a test that check the balancedness of balance sheet, we check again the Spanish ones: pymes: - subsections were not taken into account into the sum of the section - 296/596 are specific to pymes, but it goes into the overall section - 473 was included. It is not included in documentations because it needs to be emptied at closing, but we want balanced all the time. - 5585 was missing completo: - 200/280/290: research should be expenses at closing, but in the meantime we add it to the other accounts assoc: - 178/189: to deudas a largo plazo can caracteristicas especiales Translation for deudas a largo plazo was changed. Forward-Port-Of: odoo/enterprise#97875
This update ensures that documents are correctly moved to the appropriate folder and receive the correct tags when linked to a journal entry (like a vendor bill). Previously, the system didn't update document locations, but this fix resolves that issue, streamlining document management within Odoo.
Original PR description
Steps to reproduce: 1. Open the Documents app and select an uploaded file. 2. Click the action "Create Vendor Bill" (or any journal entry action). 3. The Invoice is created and the document is…
Steps to reproduce: 1. Open the Documents app and select an uploaded file. 2. Click the action "Create Vendor Bill" (or any journal entry action). 3. The Invoice is created and the document is attached to it. **Current Behavior:** The document remains in its original folder (e.g., Finance) and does not receive the tags defined on the journal settings. **Expected Behavior:** The Document should be moved to the specific folder linked to the Journal (e.g., "Vendor Bills") and receive the configured tags. **Cause:** The `write` method attempts to identify documents to sync by calling `_get_document_attachments_to_sync`, which inspects the current record (`self`). However, when an invoice is being linked to a document for the first time, the attachment ID exists only in `vals` and has not yet been applied to `self` via `super().write()`. Consequently, the code assumes there are no documents to sync and skips the folder/tag update. This issue was introduced in 2333367. **Fix:** Detect the specific case where `attachments_to_sync` is empty (no current link) but `vals` contains a `message_main_attachment_id`. In this scenario, force the synchronization flag to `True` so the document is updated after the changes are saved. Note: The loop logic was also refactored to flatten the structure and accommodate the new check more cleanly. Task-5452880
This update resolves a test failure within the im_livechat module. The issue stemmed from a mismatch between the demo data's time zone setting and the test's expectations. By explicitly setting the time zone for the OdooBot partner record, the test now passes correctly.
Original PR description
This PR fixes a failing assertion in `test_channel_get_livechat_visitor_info`. The test fails since [*] because the demo data sets the OdooBot time zone to 'Europe/Brussels', while the test was asserting it to be False. This PR explicitly sets the time zone of the OdooBot partner record and updates assertions accordingly. [*] https://github.com/odoo/odoo/pull/210094 runbot-237778 --- 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 live chat agents weren't receiving the latest conversation updates. The change ensures the live chat system correctly connects to the channel bus, guaranteeing agents see real-time updates within the live chat interface. This improves the agent experience and the quality of customer interactions.
Original PR description
The `test_form_view_embed_thread` ensures that the live chat list view redirects to the discuss app and that the bus subscription for the selected channel is properly made. This ensure that a live chat agent looking at a channel will receive the latest updates for the conversation. To ensure the bus subscription is made, the bus service is patched in order to detect calls to add or remove methods. However, we only wait for `whenReady` which is not enough to guarantee the bus is already exposed via `odoo.__WOWL_DEBUG__`. This PR ensure we wait for the list view to be displayed, which ensures the webclient is mounted and the debug info is already set. runbot-234928 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 resolves a bug in the Point of Sale system that prevented users from creating orders with custom prefixes. The change ensures order names are correctly generated, avoiding errors related to data type conversions. This ensures consistent order naming functionality across Odoo 19.1.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with…
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575 Forward-Port-Of: odoo/odoo#239515
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method code were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving data accuracy. This change impacts the generation of invoice reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460A test used to fail intermittently due to a race condition caused by a lingering success notification. This commit resolves the issue by automatically closing the notification message after an inventory adjustment, ensuring accurate test results. This improves the reliability of the inventory packaging test.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104614 Forward-Port-Of: odoo/enterprise#104481
This update resolves an issue where demo data installation caused incorrect packaging behavior during a specific test. The fix ensures that new packages are created with unique names, preventing the system from incorrectly adding items to the demo data package instead of the intended new package. This improves the reliability of the demo data.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802) Forward-Port-Of: odoo/enterprise#104623
This update removes a recent change that was causing performance issues and instability within the spreadsheet dashboard feature. The previous attempt to use ETags for efficiency wasn't delivering the expected benefits and was creating more problems than it solved. This reversion ensures the dashboard continues to function reliably.
Original PR description
This reverts commit 3b014027cb785a2c567ec94fd14ae24f39f92783. We already had many issues (and probably a lot more to come) with etag computation in spreadsheets, the ratio cost/benefit is not worth it. This reverts the etag computation in spreadsheet dashboards. Task: 5504270 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 change removes a recent update that was causing issues with spreadsheet performance. The effort to implement etag computation in spreadsheets didn't outweigh the problems encountered, so we've reverted the changes to restore previous functionality. This ensures spreadsheets continue to operate efficiently.
Original PR description
This reverts commit 60fc64d0fd2458f60b5d922fe12c0d09dc2bcde0, 67ba628326b4eb0336095b912f40d0f320a848aa and 8f3e242e197b2f269827499b0d89b2e9080f5d09. We already had many issues (and probably a lot more to come) with etag computation in spreadsheets, the ratio cost/benefit is not worth it. This reverts the etag computation for spreadsheets. Task: 5504270
This update resolves an issue where users couldn't immediately configure their website after installing the website module. The fix ensures the website setup configurator is correctly triggered during installation, streamlining the user experience and preventing delays in website setup. This change addresses a previous installation failure.
Original PR description
Since [1], installing the website module fails to launch the configurator, preventing users from setting up their website immediately. This issue occurs because `website_generator` is set to auto-install. During the installation sequence, `website_generator_wait` overrides `website_configurator_todo`, causing the latter to be bypassed. This commit provides a temporary fix to ensure the configurator is correctly triggered [1]: https://github.com/odoo/enterprise/commit/c0f26ac040b1d8ff81a2f53306e81da1778d70c2
This update resolves a recurring issue in the Odoo message copy test that occasionally failed. The fix modernizes the test to more reliably capture the copy functionality by focusing on the composer's state rather than relying on potentially unreliable keyboard shortcuts. This ensures the test consistently passes, improving overall system stability.
Original PR description
Before this commit, the "Copy Message Link" test was sometimes failing. It happens for two reasons: - It presses "ctrl+v" with the intent of copying the message link in the composer but doesn't check if the composer is focused (it should not be as the test clicks away to copy the link). - It then presses "enter" with the intent of posting the message, without checking if the composer is filled or even ready to send. This test replaces the "press" steps: - "ctrl+v" is replaced by `insertText`: we already check that the copy works and "press" is less reliable. - We click on the send button when enabled. runbot-237538 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 technical issue that prevented test cases from running correctly. The `pickup_time` and `return_time` fields were initially defined in one module, but later moved to another. This change required updating related code to ensure proper functionality and test case setup.
Original PR description
During the development of odoo/enterprise#102625, the fields `pickup_time` and `return_time` were first defined in `sale_renting`, as they were prior to the PR, but during development it was decided to move the fields into `website_sale_renting`, where they are actually used. Unfortunately, some remaining code in `sale_renting` was not updated accordingly, which caused the setup of test cases to fail when `website_sale_renting` was not installed along with `sale_renting`. runbot-237987
This update resolves a technical issue that caused translation tests to fail due to delays in loading sidebar content. By preloading translated elements, the system now ensures the sidebar is fully ready before tests begin, improving test reliability and speed. This enhances the overall translation process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#242490
This update fixes an issue where EU Standard invoices (Peppol Bis 3.0) were incorrectly displaying the customer's reference instead of the company registration number for key identifiers. The change now utilizes the company registry information, ensuring compliance with Belgian e-invoice regulations. This ensures accurate data transmission for VAT reporting and other business processes.
Original PR description
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs:…
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs: An independent invoice example: https://developer.vertexinc.com/einvoicing/docs/belgium-example-documents https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1564-L1566 https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1585 Steps To Reproduce: - Have accounting, account_edi_ubl_cii and contacts installed. - Create a Belgian company and set the VAT, Company ID and Reference (under Sales & Purchase tab). - Create a contact and set his eInvoice format in Accounting tab to EU Standard (Peppol Bis 3.0) and make sure to give him a country. - Go to accounting -> Customers -> Invoices and create an invoice for the contact you created. - Send the invoice to the contact and download the XML from the chatter and inspect it. - PartyIdentification/ID shows the partner's ref field value (e.g., "(odoobe)") instead of the company registration number. - PartyLegalEntity/CompanyID uses the VAT number instead of the company registration number (ondernemingsnummer). Ticket [link](https://www.odoo.com/odoo/project.task/5418190) opw-5418190 Forward-Port-Of: odoo/odoo#244143 Forward-Port-Of: odoo/odoo#243143
This update resolves an issue where the forecasted inventory view incorrectly linked manufacturing reservations (mrp.production) to stock picking records. The fix ensures that the correct manufacturing reservation document is displayed, improving accuracy and usability for users managing production planning.
Original PR description
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect…
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect navigation to a `stock.picking` record. Fix this by comparing both model and id when checking if the reservation differs from the outgoing document, and by opening the reservation using its actual model. This ensures the correct document is shown and avoids duplicate or invalid links in the "Used by" column. **Steps to reproduce:** - Create a v19 db with sale,mrp,sale_stock with `--demo-true`. - Go to products -> search for 'FURN_0269' product and open form view. - open forecasted smart button for forecasted reeport. - check the used by column for mrp reservation - i.e,: `WH/MO/00001 - WH/MO/00001` appears twice. - clicking on first, opens correct record of `mrp.production` where the units is reserved. - clicking on the second, navigate to false record of `stock.picking` by taking the id of `mrp.produciton` as the reserve is having `_name: "mrp.production"` **Screenshots from UI:** - Product page: <img width="1253" height="572" alt="stock_1" src="https://github.com/user-attachments/assets/13cd7f0a-34b0-48ea-a8d5-5337cbf9f5a5" /> - Forecasted report for that product: <img width="1908" height="994" alt="stock_2" src="https://github.com/user-attachments/assets/ce0af8a3-9f37-469c-8119-36b6e7be9c4a" /> - Clicking on First `WH/MO/00001` button: <img width="1265" height="568" alt="stock_3" src="https://github.com/user-attachments/assets/a8cb8a08-5c24-45f7-ad2e-5e3987f9ee70" /> - Clicking on second `WH/MO/00001` button, navigating to incorrect `stock.picking` by taking id of `mrp.production` even though there is no picking avaiable: <img width="1264" height="519" alt="stock_4" src="https://github.com/user-attachments/assets/3a2d1613-ccbb-4994-898c-c885690c507e" /> **Final view Before and After the Fix:** - For final view, In order to check the reservation done by `stock.picking`, I have created a `sale.order` having delivery for the same product to showcase both of them are working. - **Before Fix:** <img width="1907" height="994" alt="stock_5" src="https://github.com/user-attachments/assets/4441910e-348b-4270-ab1b-db903b334c97" /> - **After Fix:** <img width="1905" height="940" alt="stock_66" src="https://github.com/user-attachments/assets/ba288e6b-b2c9-47ed-b752-233ff876fb55" /> opw-[5481220](https://www.odoo.com/odoo/70/tasks/5481220?debug=1) upg-[3804157](https://upgrade.odoo.com/odoo/upgrade.request/3804157?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244222