Daily updates from Odoo
Tuesday, January 20, 2026
73 changes · saas-19.1
New functionality added to Odoo
This update adds comprehensive tests for the new sections and combo products widgets in Odoo. These tests ensure the correct handling of hidden sections, pricing options, and product movements, enhancing the reliability and functionality of sales order management. The changes improve the overall stability and accuracy of these key features.
Original PR description
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets. HOOT Tests * **Sections widget (account & sale)** * Validate *Hide Composition* and…
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets.
HOOT Tests
* **Sections widget (account & sale)**
* Validate *Hide Composition* and *Hide Prices* actions.
* Ensure duplicating a section also duplicates its invisible `collapse_` fields.
* Confirm drag-and-drop under hidden sections resets `collapse_` values for subsections.
* **Combo products and Optional Sections(sale)**
* Support moving combo lines Up/Down.
* Validate optional product logic.
* Drag-and-drop behavior:
* Moving a product line under an optional section → quantity set to `0`.
* Moving it out of an optional section → quantity set to `1` if previously `0`.
* Moving a subsection under an optional section → resets `collapse_` fields.
Python Tests
* Validate `parent_id` compute logic.
* Test utility methods used in portal and report for Sales Orders with sections.
task-5083152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226613Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted, but now 8-digit numbers (and variations with 'UA' prefixes) are supported. This ensures accurate data entry for Ukrainian businesses and avoids errors related to incorrect length restrictions.
Original PR description
with this commit:- - We are adding support for Ukrainian Tax ID numbers of 8 digits, which was 12 previously. - The following formats are now accepted: - National company numbers: 8 digits (e.g., 12345678) - European company numbers: 8 digits prefixed with 'UA' (e.g., UA12345678) - Individual numbers: 12 or 10 digits (e.g., 123456789012) - This change allows users to enter Ukrainian TINs that were previously incorrectly rejected due to length restrictions. task-5414806 opw-5373469 Forward-Port-Of: odoo/odoo#243258
This update streamlines the accounting process for Ecuadorian businesses within Odoo by consolidating expense accounts and adding a new account for direct employee benefits. It also simplifies reconciliation processes for income-related expense accounts, ensuring accurate financial reporting.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
This update enhances the kiosk payment process by centralizing IoT communication through a new service, `iot_http`. This improves reliability and security by handling various IoT protocols for payment requests, ensuring smoother transactions for customers.
Original PR description
We now use the `iot_http` service to handle all IoT available protocols to send payment requests. Forward-Port-Of: odoo/enterprise#104811
This update enhances the flexibility of Odoo's website builder by introducing a new system for modifying shape groups. Plugins can now directly adjust these groups, allowing for more dynamic and customizable website designs. This change improves the ability to tailor website layouts to specific business needs.
Original PR description
This commit defines `image_shape_groups_providers` and `background_shape_groups_providers` as new plugin resources. These resources return functions that receive the current shape groups, allowing plugins to mutate them directly or return groups to be merged into the final configuration. Forward-Port-Of: odoo/odoo#243121
Resolved issues and error corrections
This update fixes an issue where the product comparison bar was hidden behind other website elements. By increasing the bar's visibility level, users can now consistently access and use the comparison feature regardless of the website's layout. This ensures a smoother shopping experience.
Original PR description
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded).…
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded). This low z-index value caused it to be overlapped by any website snippets using grid mode with more than 3 items, as grid items conventionally have incremental z-index values (1, 2, 3, 4, ...) for JavaScript consistency. The issue was not limited to s_banner_categories but affected all grid-based snippets, making the comparison bar inaccessible when positioned behind snippet content. Solution: Increase the comparison bar's z-index to -modal (1055 in Bootstrap), ensuring it always appears above regular page content including grid snippets, while still remaining below actual modals and dialogs. After this commit: The comparison bar consistently appears on top of all snippet content, ensuring users can always access and interact with product comparisons regardless of the page layout or snippet configuration. opw:5426163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243975
This update fixes an issue where newly created appraisal templates weren't appearing in the campaign selection list. The problem stemmed from a technical detail regarding how the system filtered templates based on company settings. The fix ensures that all templates, including newly created ones, are correctly displayed, streamlining the campaign setup process.
Original PR description
**Version:** - 19.-0 **Steps to reproduce:** - Install the Appraisal module. - Click the Launch Campaign button. - Open the wizard and create a new appraisal template. **Issue:** - Newly created appraisal templates do not appear in the selection list. **cause:** - When a new template is created, the company field is automatically set by default. - However, the domain used to fetch templates does not include the company condition, causing the newly created template to be excluded from the results. **Solution:** - remove domain and use check_company=True to get the company. Task-5416593 Forward-Port-Of: odoo/enterprise#102108
A technical issue in the Odoo loyalty program tour was preventing users from completing the setup. This fix addresses a problem caused by an infinite scroll feature within the pop-up modal, which was causing the tour to get stuck. Merging this change will ensure the loyalty program tour functions correctly for all users.
Original PR description
fw-port fails because of infinite scroll in pop modal .modal .partner-list 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#218604
This update resolves an issue that prevented users from clicking 'Show', 'Force CFDI', or 'Retry' buttons on invoices after cancelling payments. The fix addresses a technical error related to missing payment information, ensuring invoices can be processed correctly in the MX electronic invoicing process.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386 Forward-Port-Of: odoo/enterprise#102248
This update removes an unnecessary warning related to credit notes from the GSTR report, streamlining the reporting process. Previously, a warning appeared on invoices when a credit note was linked, which has now been corrected to clear only when the credit note is fully processed and checked. This simplifies reporting for users.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#104701 Forward-Port-Of: odoo/enterprise#102106
This update resolves a technical error in the WPS report test process. Specifically, the test was incorrectly creating a bank account record. This change ensures the test accurately reflects the report generation process, improving the reliability of the test results.
Original PR description
The test was creating a res.partner.bank with the id of company passed as partner_id. This commit fixes this issue by passing the partner_id of the company instead. build_error-237562
This update prevents Attendance: Officer/Admin users from accessing the employee onboarding feature within the Attendances app. Previously, users lacked the necessary permissions, leading to a traceback error. This change ensures that only users with full Employee rights can access this functionality, improving data security and usability.
Original PR description
# Issue Getting a traceback when trying to access the onboarding menu with just Attendance: Officer access right. # Steps to reproduce 1. Log in with a demo user, with just Attendance: Officer access right. 2. Navigate to Attendances app, and yes, you don't see Configuration, but still you can access the Onboarding menu by typing some random text on search. 3. Now, navigate to the Onboarding menu, and try setting a badge of an employee 4. You get a traceback. # Fix Attendance: Officer/Admin without Employee rights (either Officer/Admin) will not be able to access the Attendances Onboarding menu. Only the user with both the rights can access it. task-5267189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235965
This update fixes a bug where the user's final answer in the chatbot wasn't saved or shown in the side panel. The change ensures the final answer is correctly recorded, displayed, and the chat session is properly closed, improving the user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due…
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due to the `isLast` check in `_goToNextStep()`. As a result, `_process_answer()` was not executed, and the user's final answer was not saved, which resulted in the `rawAnswer` field remaining empty and the answer not appearing in the side panel. The chat session was also not marked as closed since the backend route was never called. **Current behavior before PR:** --------------------------------- - The final chatbot answer is not visible in the side panel - The chat session remains open after the final step **Desired behavior after PR is merged:** ----------------------------------------- - The final chatbot answer is saved and displayed in the side panel - The backend route is triggered for the last step - The chat session is properly marked as closed **Task:** 5172125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235102
This update fixes a technical issue that caused errors when Odoo servers were shut down. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures a smoother and more reliable server shutdown process.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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#244481
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV exports. Now, invoices with foreign currency settings will accurately reflect the correct rates when generating reports for Datev, ensuring data consistency and accurate financial reporting. This resolves a previous reporting discrepancy.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239649
This update fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the currency rates set on invoices, ensuring accurate financial reporting for German customers. This improves the reliability of data exported to Datev.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 Forward-Port-Of: odoo/enterprise#101910
This update corrects a technical issue where the kiosk system wasn't correctly receiving payment information from IoT payment terminals. The fix ensures the kiosk retrieves the accurate response data, improving the reliability of self-order transactions. This resolves a potential disruption to the customer ordering process.
Original PR description
In v19.0, IoT Boxes respond with a dict containing a `result` key holding the actual response of the action. The kiosk couldn't get the terminal answer as it was reading directly in the response dict, instead of its `result` key. Forward-Port-Of: odoo/enterprise#104799
This update prevents unnecessary WebRTC testing when working with stable IoT Boxes. This change avoids a potential performance issue and ensures the 'Test' button functions correctly for the intended use case. It improves the overall user experience for IoT Box management.
Original PR description
We now avoid testing WebRTC when pressing "Test" button on the IoT Box record, when the IoT Box is a stable IoT Box (which does not support it). Task: 5490291 Forward-Port-Of: odoo/enterprise#104716
A recent test failed due to a problem with how payment providers were being set up across multiple companies in our demo data. This update ensures that each payment provider is linked to the correct website company, resolving the error and improving the reliability of the website's payment functionality. This fix prevents potential issues with assigning payment providers to different companies.
Original PR description
What is fixed ------------- The test_payment_provider_visibility_with_portal didn't pass due to a multi company issue. In demo data, "Demo" payment provider exists for different companies which led the search method to return every one of them. Trying to assign the shop website id to each of them then raises an error as their company_id are inconsistent. The fix ------------- We now ensure only one provider is selected and its company is the same as the website's company. Runbot error : 237822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244441
This update resolves an error preventing branch companies from registering for Peppol when sending from the parent company. The change allows users to correctly activate Peppol in both the main and branch companies, ensuring seamless integration with the Peppol network. This resolves a previous registration issue.
Original PR description
1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company; 3. Activate Peppol in the branch and select "Send from parent company"; => Error message: "Cannot register a user with a receiver application". opw-5725278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244520
This update fixes a minor usability issue in the contact record view. The GLN field was awkwardly positioned and lacked a label, making it difficult for users to find. The change repositions the field before the notes field for better clarity and discoverability.
Original PR description
The field is placed weirdly in the view when opening the contact view of the delivery address. There is no label, making it almost impossible to discover, and it is in the middle of everything. Let's put it down before the notes field. Before: <img width="971" height="510" alt="image" src="https://github.com/user-attachments/assets/2e0e7d96-1a7f-4fe5-b17d-4c5b25a3e7bf" /> After: <img width="824" height="554" alt="image" src="https://github.com/user-attachments/assets/3bc47f20-72a9-4247-8dd3-9e939046c6d7" /> task-none Forward-Port-Of: odoo/odoo#244554
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, leading to posting failures. Now, the system correctly applies company-specific payment terms, streamlining inter-company transactions.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745 Forward-Port-Of: odoo/enterprise#102986
This update resolves an issue where the SAFT export process would fail for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly validates that each company has at least one contact before generating the SAFT file. This prevents export errors and ensures accurate reporting.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear no-task Forward-Port-Of: odoo/enterprise#104633 Forward-Port-Of: odoo/enterprise#104144
This update corrects a minor issue related to testing within the live chat feature. Previously, outdated tests were causing problems. The PR removes these unnecessary tests, ensuring the canned response functionality works as intended and avoids potential conflicts.
Original PR description
In [1], auto focus was removed for canned responses in the navigable list. The intent was to avoid conflicts with emojis. In [2], the shortcut for canned response was changed to `::` and the auto focus behavior was restored. However, tests added in [1] were not removed. Since they were fragile (negative assertion), they are passing most of the time. This PR removes the tests that are now outdated. runbot-233358 [1]: https://github.com/odoo/odoo/pull/170900 [2]: https://github.com/odoo/odoo/pull/192953 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#244472
This update resolves a bug in the website builder that caused crashes when customizing shadow settings. The fix prevents errors when shadow values are not in the expected format, ensuring a more stable and reliable builder experience for users. This improves the overall usability of the website customization tool.
Original PR description
Forward-Port-Of: odoo/odoo#244244
This update resolves a technical issue that was preventing a test from running correctly for embedded actions. The fix ensures that the test accurately reflects how the action's dropdown menu opens, improving the reliability of our testing process. This change ensures our embedded actions function as expected.
Original PR description
In this commit, we fix an embedded action test that failed because when clicking on the sliders to show the top bar, the dropdown was directly opened as there is only one visible action (since this commit: https://github.com/odoo/odoo/pull/208005/commits/a5709e870e033b83d50a2f581c81cceb2a98d91b). We then adapt the test to wait for the dropdown to open automatically, and then when it's the case, create the new custom embedded action. runbot error~237752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244508
This update clarifies the reasons why Stripe might reject authorization requests for expense payments. It now includes a specific 'authorization_controls' reason, translating it into a user-friendly explanation for better tracking and resolution of payment issues. This improves transparency and helps streamline the expense reimbursement process.
Original PR description
When Stripe refuses an authorization due to the maximum allowed being reached, there is a specific technical reason "authorization_controls" that wasn't mentioned in their documentation. This adds the reason with a user-friendly translation See [doc](https://docs.stripe.com/api/issuing/authorizations/object?api-version=2025-01-27.acacia#issuing_authorization_object-request_history-reason) Forward-Port-Of: odoo/enterprise#104744
This update resolves a minor issue where the email invite tour occasionally interfered with the automatic opening of the channel member list. The fix ensures the tour waits for the member list to open, preventing a brief conflict. This improves the overall user experience for inviting partners to channels.
Original PR description
The `test_01_invite_by_email_flow` test ensures we can invite partners to a channel using their email. The tour opens the invitation panel, then sends an email. However, it conflicts with the auto-open of the member list. Sometimes, the member list opens after clicking on the invite panel button. This only occurs because the tour runs very fast. It's very unlikely that this occurs to a real user. This commit fixes the tour in order to wait for the member list to open initially. runbot-237994 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#244527
A bug was causing errors in the self-order kiosk (specifically on IoT devices) due to a missing user ID. This update sets a default value of '0' to ensure the kiosk can function correctly, particularly when used with a Six terminal. This resolves a technical issue impacting the kiosk's functionality.
Original PR description
In self order, user id is undefined, so we get a traceback on the IoT Box for missing `userId` key. We default to `0` to allow using a Six terminal with the kiosk.
This update fixes a technical issue preventing a key test from running successfully on the Odoo system. The change adds group permission controls to the payroll module, ensuring proper access and functionality for users. This resolves a potential restriction impacting payroll processing.
Original PR description
The test_employee_fields_groups unit test from hr/tests/test_self_user_access.py was not successful on the runbot due to access restriction. I added the groups parameters to the l10n_sa_gosi_api_is_available field definition in the hr_employee extension from the l10n_sa_hr_payroll_gosi module. Runbot error: 233954
This update fixes default printer settings for Point of Sale, ensuring users are presented with the most appropriate printer type (receipt or preparation) when creating new printers. It also adds a required field for product categories when creating preparation printers, reducing potential errors and improving data accuracy.
Original PR description
The goal of this pr was to set the printer type by default as `receipt` when a quick create was done from the "Receipt Printers" category and as `preparation` when it's done in the "Preparation Printers" category, both in `pos.config` and in `res.config`. Also, in the `pos.printer` form view, for a preparation printer, products categories are now required when creating a printer to avoid user oversights. And, a quick fix to make the default receipt printer as required, under the "Receipt Printers" category in the `res.config` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where free product reward lines incorrectly displayed a non-zero price in the shopping cart. The issue stemmed from an override in the `sale_subscription` module that was causing unnecessary discount calculations. The fix filters reward lines to prevent this recalculation, ensuring accurate pricing for free products.
Original PR description
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on…
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on configuration. 3- Create a `promotion`: - rule: minimum quantity: 0, minimum purchase: 10 - reward: free product, quantity: 1 4- Set a non-zero price on reward product from product page. 5- Create a product with price of 6 and publish it on the website. 6- On website, add 1 unit of created product to cart. 7- Open cart, and increase the quantity. 8- As you see the free product is added to cart but the price is non-zero. ### Cause: Based on #89397, the reward line have the discount of 100. In the `_compute_discount` this discount is set to 0: https://github.com/odoo/odoo/blob/e48a7f1b03f23a4c96e35ee4350029439ec73e47/addons/sale/models/sale_order_line.py#L797 As `compute_discount` only depends on `product_id`, `product_uom_id`, `product_uom_qty` this shouldn't cause issue. However, in `sale_subscription` its override includes `sale_order.plan_id` as dependency: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/sale_subscription/models/sale_order_line.py#L86-L90 Which setting `plan_id` to `False` here makes discount to be recomputed: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/website_sale_subscription/models/sale_order.py#L27-L30 ### Fix: This can be avoided by filtering reward lines in a `_compute_discount` override. As none of reward lines regardless of reward type are expected to have a discount calculated this fix will not break any other flows. It's noteworthy to mention that in the test, `_compute_discount` is directly called in order to mimic the flow without the need to install `sale_subscription`, as the `sale_subscription` is not root cause of the issue and the same issue could reproduced by any other modules overriding `_compute_discount`. opw-5485796 Forward-Port-Of: odoo/odoo#243827
This update corrects a technical issue where the payment callback URL was incorrectly triggered, causing verification problems. The fix ensures the callback URL only activates when a redirect is expected, aligning with Razorpay's documentation and improving payment reliability for UPI transactions.
Original PR description
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only…
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only trigger when `redirect` is `True`. Cause: - In Razorpay documentation it's not clearly mention it will only trigger `callback_url` when `redirect` is `True`, so in some cases it redirect to `callback_url` even `redirect` is `False` which is cause issue during signature verification as it try to verify signature according to `is_redirect` with `razorpay_secret` but in oAuth `razorpay_secret` is not set. Razorpay doc link: https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/integration-steps/#123-checkout-options <img width="670" height="537" alt="image" src="https://github.com/user-attachments/assets/81c855c0-aaca-4953-bcff-942bc11a32d2" /> Fix: - Only set `callback_url` for `REDIRECT_PAYMENT_METHOD_CODES` PMs where we expect it to redirect to `return_url` and not in the oAuth flow, Instead relying on the `redirect` option of the Razorpay. opw-5389499 Forward-Port-Of: odoo/odoo#243596 Forward-Port-Of: odoo/odoo#243054
This update resolves an issue where grouping accounting records by their root account was failing, resulting in an error. The change allows for full domain optimization during record retrieval, ensuring accurate grouping and displaying the expected nested records. This improves the functionality of the chart of accounts feature.
Original PR description
Access records in a grouped by `account_root` list failed, showing an error message:
Unsupported operator on Root 'Account' (account.account) in [('root_id', 'any', [('display_name', 'in', [10])])]
Step to reproduce:
- New DB with `accountant` module
- Accounting -> Chart of accounts
- Group By "Root"
- Open any grouped record set
When opening the record set, Odoo fetches data using the domain `[('id', '=', '10')]`
The domain goes through optimization as follows:
```
[('id', '=', '10')]
basic : [('id', 'in', ['10'])]
full : [('root_id', 'any', [('display_name', 'in', [10])])]
```
However, the `_search_account_root` method protects the technical field `account_root`.
This commit adapts it to allow full optimized domain search and solving the error.
Ticket [link](https://www.odoo.com/odoo/project.task/5178896)
opw-5178896
Forward-Port-Of: odoo/odoo#238841This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for UPS, FedEx, USPS, and DHL. By mapping these modules, the connector now functions seamlessly with these major shipping carriers, ensuring accurate order processing and fulfillment.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update optimizes how the attendance tracking module requests location data. By default, location tracking is disabled when in an office or event setting, reducing unnecessary requests to external services. This improves performance and efficiency.
Original PR description
Use the _get_localisation helper that uses geoip when available Disable geolocalisation of device by default (i.e. in the context of an office/event, all requests are in the same spot) In addition to #243073 Forward-Port-Of: odoo/odoo#243117
This update resolves an issue preventing correct Spanish translations in reports. The fix ensures the translation process has access to necessary data (like user and context) during the translation lookup, resulting in accurate and complete Spanish reports. This improves the user experience for Spanish-speaking customers.
Original PR description
Problem --------- Currently, the lazy translation is executed inside the Markup frame. This has the consequence of having the frame pretty much empty (no context, no user, no cr) when looking for the language. Thus, the lazy translate cannot retreive any language. Solution --------- Use `str` in the compute method so that the frame used to compute the translation is actually the compute method (which has data needed to retreive the language) and not the markup. Before: -> compute ..|-> Markup (the frame used) ....|-> _lt => fail After: -> compute (the frame used) ..|-> _lt ....|-> Markup error-237535 error-237536 Forward-Port-Of: odoo/enterprise#104776
This update resolves an issue where embedded buttons in the control panel were getting cropped due to incorrect height calculations during dragging. The fix ensures that the buttons display their actual size, preventing visual distortion and improving the user experience. This change improves the appearance and usability of the control panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234120
This update resolves an issue where Odoo invoices with discounts generated for the Danish Nemhandel system were failing validation. The fix ensures discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the accuracy of financial data and avoids potential disruptions in payment processing.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241789 Forward-Port-Of: odoo/odoo#241614
This update resolves a compatibility issue with an older version of Odoo's spreadsheet functionality. Specifically, it ensures that the ODOO.FILTER.VALUE feature continues to work correctly across different Odoo releases. This prevents disruptions for users relying on this spreadsheet tool.
Original PR description
Task-5477426 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#244218
This update fixes an issue where the Odoo Studio export process incorrectly excluded certain fields. The fix separates the handling of computed and related fields, ensuring more accurate exclusion based on their type and writeability. This improves the reliability of exported models, confirmed by the Industry team.
Original PR description
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but…
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but there are subtle differences that cause the excluded fields to sometimes be wrong. While analyzing the heuristic with the ORM team, we decided to separate the computation of related and computed fields. After this commit, we have a refined computation of excluded fields for related and computed fields: - for computed fields (that are not related ones), we always exclude them except when they are writeable (i.e. stored or with inverse) - for related fields, we always exclude them when the relation is in the list of related models to exclude. We also exclude them when they are not writeable on the current record only (not the source record), except if they are required. Some export scenarios have been tested manually and brought with them adaptations in the hardcoded lists of default fields to exclude. The Industry team agreed with these changes. Task id: opw-4974787 Forward-Port-Of: odoo/enterprise#87530
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's HTML was converted to plain text. The fix prevents this duplication, ensuring users receive messages with URLs correctly formatted and avoiding potential confusion. This improves the clarity and usability of WhatsApp communication within Odoo.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises…
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#104252 Forward-Port-Of: odoo/enterprise#101083
This update fixes an issue where the preferred delivery carrier wasn't automatically applied when adding shipping to a sale order. The change ensures that the carrier specified for a customer partner is now correctly used, streamlining the shipping process and improving order accuracy. This resolves a previous bug impacting order fulfillment.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Go to partner *Azure Interior*: - Set 'property_delivery_carrier_id' to any carrier - Create a sale order: - Customer: Azure Interior - Add 1 unit of P1 - Click on "Add shipping" Problem: Since this commit: https://github.com/odoo/odoo/pull/203955/files#diff-9f1fd37c63903c4c029f099d485a3f9831446850be55695a4603c05ef298885bL134-L137 the carrier defined on the partner is no longer loaded by default. Solution: Check if the carrier defined on the partner is among the allowed carriers, and if so, set it automatically. opw-5220118 Forward-Port-Of: odoo/odoo#235336
This update resolves an intermittent issue where live chat sessions would unexpectedly crash. The fix addresses a timing conflict between chat closing and agent member deletion, ensuring a reliable session end. This improves the overall stability and user experience of the live chat feature.
Original PR description
This commit fixes the `visitor leaving ends the livechat conversation` test that was sometimes failing. There is a race between the simulation of the guest leaving the chat that uses `withGuest` which is known to be problematic and the `action_unfollow` method, called when the chat window is closed. The unfollow method deletes the agent member, but since the guest cookie is still present, the `channels_as_member` rpc retrieves the guest member. The rest of the code doesn't expect this mismatch and a crash occurs. This commit ensures the `channels_as_member` rpc is properly done before closing the chat window. runbot-237947 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 formatting error in the Korean localization files (ko.po) that was causing issues with the display of documents. The fix ensures proper line wrapping, resulting in accurate and consistent translations for users. This improves the overall quality and usability of the Enterprise version.
Original PR description
EOL error due to incorrect line wrap
This update corrects a bug where the website generation process wasn't correctly setting a key value. The fix ensures that the website generation feature always defaults to 'True', guaranteeing that new websites are created when the /startwebsite flow is initiated. This resolves a potential issue preventing website creation.
Original PR description
Missing the 'import_website' value, and since /startwebsite always creates a website it should always be True.
This update increases the timeout for the main Odoo test suite to handle the growing number of tests. Previously, the suite would frequently fail due to lengthy run times, but this change provides a longer window to ensure all tests complete successfully. This improves the stability of nightly builds.
Original PR description
This commit increases the timeout of the main (desktop) hoot test suite. Since [1], the suite is split by sub-builds, such that each sub-build only runs the tests defined in the addons that are tested by that sub-build. So the suite never timeouts anymore on regular builds. However, in nightly, we still run the whole suite "old school", i.e. all tests in the same run. In that case, the suite sometimes (in 19.1) or often (in master) exceeds the previous timeout (50m). With 1 hour, we hope that it will be enough. Note that the number of tests keeps increasing, hence the need to increase the timeout. [1] https://github.com/odoo/odoo/pull/234132 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 an issue where inserting pivots from spreadsheets could cause errors or prevent resizing. Now, the spreadsheet pivot insertion process is streamlined, automatically adding necessary columns and matching the resizing behavior of web pivots, ensuring a smoother user experience.
Original PR description
Current behavior before PR: - Inserting a pivot from a spreadsheet could trigger spill errors when the pivot had more columns than the default columns. - Columns could not be resized when inserting a pivot from a spreadsheet, unlike insertion from a web pivot view. Desired behavior after PR is merged: - Both pivot insertion flows are combined into a single implementation to remove duplicated code. - Required columns are added automatically to prevent spill errors. - Columns are resized when inserting a pivot from a spreadsheet, matching the behavior of web pivot insertion. Task: [5404283](https://www.odoo.com/odoo/2328/tasks/5404283)
This update ensures that the minimum wage is accurately calculated and pro-rated based on employee work time. The change addresses a previous issue where the minimum wage wasn't correctly adjusted, ensuring compliance with Belgian labor laws. This update improves payroll accuracy and reduces the risk of non-compliance.
Original PR description
Since changes made in 302bf2b4e201da8f56b1da012dd7f03c81a85e22 the minimum wage should be pro-rated to the work time rate. Forward-Port-Of: odoo/enterprise#104419
This update fixes an issue where Live Chat reports consistently displayed days starting with Sunday, regardless of the user's preferred week start day setting. Now, the reports accurately reflect the user's language-defined 'First Day of Week', providing more accurate and relevant reporting data. This ensures consistency and a better user experience.
Original PR description
**Current behavior before PR**: The "Day of Week" group by in the Live Chat report always treats Sunday as the start of the week, ignoring the "First Day of Week" configured in the user's language settings. **Desired behavior after PR is merged**: "Day of Week" group by now correctly takes into account the user's configured "First Day of Week", as set in their language settings. **task**-[4808640](https://www.odoo.com/odoo/project.task/4808640) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234708 Forward-Port-Of: odoo/odoo#213307
This update resolves a problem where the payer company was incorrectly identified in the 1099 report when using multiple companies. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving report accuracy and compliance. This impacts users with multi-company configurations.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes a usability issue by moving the GCC Format checkbox to the 'Customer Invoices' section within the settings. This ensures that users can always access this important setting, even when the broader Fiscal Localization section is hidden, streamlining the invoicing process.
Original PR description
This fix moves the GCC Format checkbox under the 'Customer Invoices' block so it remains accessible in branches where the Fiscal Localization section is hidden. task-5723793 Forward-Port-Of: odoo/odoo#244652
This update ensures that live chat and member lists automatically open by default, regardless of which panel is currently active. Previously, opening one panel would disable the other. This change provides a better user experience by maintaining the preferred default view for both live chat and non-live chat conversations.
Original PR description
*: crm_livechat, im_livechat 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…
*: crm_livechat, im_livechat 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 runbot-237994 [1]: https://github.com/odoo/odoo/pull/238472 https://github.com/odoo/enterprise/pull/104435 Forward-Port-Of: odoo/odoo#243864
This update combines member and live chat information automatically when creating tickets through the website helpdesk and WhatsApp channels. Previously, this data was handled separately, leading to a less streamlined experience for users. This change ensures a more complete and accurate view of customer interactions within tickets, improving support efficiency.
Original PR description
*: website_helpdesk_livechat, whatsapp Task-5496830 https://github.com/odoo/odoo/pull/243864 Forward-Port-Of: odoo/enterprise#104435
This update fixes a bug that prevented users from correctly unbuilding manufactured products when the same serial number was used multiple times within a manufacturing order. The fix ensures that the system accurately tracks component usage, preventing validation errors and ensuring accurate inventory management. This improves the reliability of the manufacturing process.
Original PR description
Steps to reproduce the bug: - Create a storable product P1 - Tracking: Serial Number - BoM: Component: 1 unit of C1, tracked by Serial Number - Update the inventory of C1 - 1 unit with SN1 - 1 unit…
Steps to reproduce the bug:
- Create a storable product P1
- Tracking: Serial Number
- BoM: Component: 1 unit of C1, tracked by Serial Number
- Update the inventory of C1
- 1 unit with SN1
- 1 unit with SN2
- Create a Manufacturing Order to produce 2 units of P1
- Confirm and validate the MO using serials SN1-P1 and SN2-P1
- SN1 and SN2 of C1 are consumed
- Unbuild 1 unit of P1 with serial SN1-P1 Result: SN1 of C1 is correctly restored
- Unbuild 1 unit of P1 with serial SN2-P1
- Try to validate the unbuild
Problem:
A user error is raised:
"The serial number SN1 has already been assigned"
This happens because _action_unbuild attempts to reuse the same component serial number (SN1 of C1) without checking whether it has already been consumed by a previous unbuild operation on the same Manufacturing Order.
Solution:
This fix ensures that, when unbuilding tracked products, component serial numbers already used by previous unbuilds of the same MO are excluded from the candidate move lines.
This prevents reassigning the same serial number multiple times and avoids the validation error.
opw-5441256
Forward-Port-Of: odoo/odoo#242882This update resolves an issue preventing the generation of QR codes for invoices when using automated workflows. The fix ensures the system correctly accesses necessary configuration data, allowing QR codes to be created without requiring a direct HTTP request. This improves invoice automation and payment processing.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF"; 2. create an automation rule for the `account.move` model; 3. set "Trigger" to…
Versions
--------
- saas-18.3+
Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
```python
env['account.move.send']._generate_and_send_invoices(records)
```
7. call `action_post` on an invoice via RPC or Odoo Shell.
Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound
Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.
When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.
[^1]: feature added via commit bcb73cd159885
Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.
opw-5487075
Forward-Port-Of: odoo/odoo#244610
Forward-Port-Of: odoo/odoo#243528A glitch prevented users from removing all avatars from a website feature, leading to errors when trying to add new ones. This fix ensures the system correctly handles rapid avatar removal, preventing a disruption to the user experience.
Original PR description
**Problem** Users could remove all avatars from the `s_avatars` snippet by clicking the "Remove avatar" button rapidly. This also causes an error when attempting to add a new avatar afterward.…
**Problem** Users could remove all avatars from the `s_avatars` snippet by clicking the "Remove avatar" button rapidly. This also causes an error when attempting to add a new avatar afterward. **Reproduction** 1. Drop the `s_avatars` snippet. 2. Click very quickly on the "Remove avatar" button multiple times. **Cause** The code relied on preventing the removal of the last element by disabling the "Remove avatar" button based on DOM state. Because rendering is asynchronous, rapid clicks could be registered before the button was disabled, allowing the last avatar to be removed. **Fix** Add a check in `AvatarsHeaderMiddleButtons.removeAvatar` to prevent removal when only one avatar remains, covering cases where clicks occur before the UI updates. The components `CarouselItemHeaderMiddleButtons` and `NavTabsHeaderMiddleButtons` use the same logic of `AvatarsHeaderMiddleButtons` and could fail similarly, thus they have been fixed too, even if the bug is not currently reproducible on them. task-5462816
This update fixes a technical error that occurred when sale orders lacked an invoice date. The fix ensures that stock movements related to subscriptions are correctly filtered, preventing errors and improving the reliability of subscription order processing. This resolves a potential disruption to order fulfillment.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557 Forward-Port-Of: odoo/enterprise#75717
Users were experiencing blocks in the Point of Sale UI due to preparation printers ignoring print requests. This change reverts a recent update to restore normal print functionality and remove the blocking issue. It ensures users can consistently use the Point of Sale feature.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit fcd0aab5f1349310e161b175f118eb8d3db818e4. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/odoo#243981
A recent change in the Odoo POS system was causing users to be blocked from printing, leading to frustration. This pull request reverts a previous update to restore the normal printing functionality and resolve this blocking issue.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit 5e290c264f14108e036344663fc459bf77da265e. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/enterprise#104421
This update fixes a potential issue in the Turkish accounting module (l10n_tr_nilvera) by correcting the default journal type used when fetching documents. Previously, the default was set incorrectly, which could lead to errors. The change now sets the default to 'purchase' to ensure proper accounting practices and prevent misuse.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update resolves a technical issue preventing the Odoo IoT box from starting correctly. The addition of a required dependency, geoip2, was necessary for the Odoo application to function on the IoT environment. This ensures stable operation of the Odoo instance on the IoT box.
Original PR description
This PR adds geoip2 to packages required by the iot box in saas-19.2 Without geoip2 odoo doesn't start on the iot box Backport of https://github.com/odoo/odoo/pull/243751 to allow to use saas-19.1 images with dbs in master
This update ensures the Apps application accurately displays the number of industry modules categorized by type. Previously, the count was always shown as zero due to a change in the underlying data source. This change corrects the display to provide a more precise count for users.
Original PR description
Before this commit, the count of industry modules by category in Apps application was always 0. With the change of API of apps.odoo.com, there is a possibility to display the exact count by category. In this aim, this commit adds the version to the route arguments such that the count is correctly displayed. task-5222706 Forward-Port-Of: odoo/odoo#243482
This update corrects a bug that occurred when users attempted to change a tax lock date to a date in the past. The fix prevents the system from generating incorrect default values and triggering an error, ensuring accurate reporting. This improves the stability and reliability of financial reports.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the BR Point of Sale module. The change ensures the module aligns with recent legal requirements and automatically installed features. The fix prioritizes accurate reporting for Brazilian businesses.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835 Forward-Port-Of: odoo/enterprise#104671
This update reverts a recent change that added new features to the mobile dashboards. It now returns the dashboards to display only charts, simplifying the user experience. Adaptations were made to ensure existing features like the carousel and granularity selector continue to function correctly.
Original PR description
### [REV] spreadsheet_dashboard: go back to chart-only mobile dashboard This commit reverts 5cde5114d971a9edc12c9708ae0ea86bfb6db3b2, so the mobile dashboards go back to showing only the figures. Some adaptations were necessary to make the new features (carousel, granularity selector, ...) work. Task: [5447027](https://www.odoo.com/web#id=5447027&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242288
A recent issue prevented users from successfully obfuscating their databases using the Odoo command-line interface. This update corrects a problem where the command incorrectly processed database names, causing an error. The fix ensures the obfuscate command functions as intended, allowing users to securely protect their data.
Original PR description
It is not possible to use the obfuscate command Steps to reproduce: 1. Initialize a database `test` 2. In a terminal, try to obfuscate the database with the command `python odoo/odoo-bin obfuscate --pwd=1234 -d test` 3. An error occurs Issue: `config['db_name']` returns a list Solution: Make sure we use obfuscate with a single database and get the first (and only) database in the list opw-5480280 Forward-Port-Of: odoo/odoo#244577
This update prevents the HTML Builder editor from freezing due to rare errors. A timeout mechanism is now in place to release the editor and alert the user to potential data issues during saving. This enhances the user experience and prevents data loss.
Original PR description
Before this commit, if an error occurred within the mutex that did not explicitly throw, the mutex could remain locked indefinitely. This blocked subsequent actions and prevented the user from saving. This commit introduces a timeout mechanism for Operations. This is intended for very rare cases as a last resort to prevent the editor from becoming completely unresponsive. When a timeout occurs: - The mutex is released, allowing the user to recover (e.g. by deleting the faulty snippet). - The user is notified of the issue. - A warning is displayed during saving to indicate that the content might be in a corrupted state. Additionally, the `canTimeout: false` flag is added to options that are expected to remain open for long periods (such as the snippet modal). task-5152911 Forward-Port-Of: odoo/odoo#233079
This update resolves an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The fix applies a standard image scaling method (object-fit: cover) to ensure avatars display correctly and consistently across all user profiles. This improves the overall user experience and visual presentation.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243434 Forward-Port-Of: odoo/odoo#242320
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring correct price difference calculations and accurate financial reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243941 Forward-Port-Of: odoo/odoo#238428
This update resolves an issue where certain carriers weren't correctly integrated with shipping partners within the website sale module. The change ensures that carrier options align properly with available shipping partners, leading to more accurate shipping calculations and a smoother customer experience. This improves the reliability of the online ordering process.
Original PR description
Forward-Port-Of: odoo/odoo#244649 Forward-Port-Of: odoo/odoo#244035
This update fixes an error in the financial reporting for Vietnam (l10n_vn_reports) that resulted in inaccurate calculations for key balance sheet codes (420.1 and 420.2). The changes ensure these figures accurately reflect equity and profit, improving the reliability of financial statements.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104786 Forward-Port-Of: odoo/enterprise#104373
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain clear and adhere to API specifications, improving the accuracy of VAT processing for Vietnamese businesses.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994