Daily updates from Odoo
Tuesday, January 20, 2026
63 changes · master
Resolved issues and error corrections
A recent issue prevented users from configuring their websites after installing the website module. This fix ensures the website configurator automatically launches during installation, streamlining the setup process and allowing users to quickly begin customizing their online presence. This resolves a critical blocker for new website deployments.
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 Forward-Port-Of: odoo/enterprise#104789
This update ensures live chat agents consistently receive the latest conversation updates by correctly subscribing to the necessary channels. Previously, the system wasn't reliably setting up the bus subscription, leading to potential delays in receiving updates. This fix guarantees that agents always see the most current information in live chat sessions.
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 Forward-Port-Of: odoo/odoo#244512
This update fixes an issue where the product comparison bar was hidden behind other website elements, particularly grid-based snippets. 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 products created through the website automatically appeared as published without a category assigned. The fix removes code that forced publishing and ensures products remain unpublished until a category is selected, aligning with the user's expected experience. This improves consistency and prevents accidental product listings.
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#244414 Forward-Port-Of: odoo/odoo#242779
This update ensures the website's product barcode lookup functionality aligns with a recent community change. Previously, products created through the website weren't automatically published if a category wasn't selected. This fix corrects the test to accurately reflect this behavior, preventing potential issues with product visibility.
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#104709 Forward-Port-Of: odoo/enterprise#103778
This update fixes an issue where newly created appraisal templates weren't showing up in the selection list during campaign setup. The problem stemmed from a technical detail in how the system filtered templates, now it correctly includes templates created within a campaign, ensuring a smoother workflow for performance reviews.
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
This update resolves an issue where the link popover remained open after a snippet was removed from the website builder. The fix ensures the popover closes automatically when a snippet is deleted, improving the user experience and preventing visual clutter. This change was made to enhance the stability and usability of the website editing tool.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its pointerdown handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document pointerdown listener, but this also triggered when interacting with the link type dropdown and color picker, closing the popover triggers applyCallback and causing nested links to be created.
After this commit:
- Close the link popover from on_will_remove_handlers before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243556
Forward-Port-Of: odoo/odoo#237679This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' actions on MX electronic invoices. The problem stemmed from a system error when payments were cancelled, leading to incorrect data. This fix ensures these actions function correctly without causing errors.
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 prevents Attendance Officer/Admin users from accessing the employee onboarding feature within the Attendances module. Previously, users with limited access could trigger a traceback when attempting to set badges. This change ensures that only users with full Employee rights can access this functionality, improving stability and security.
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 resolves a test failure in the live chat module. The issue stemmed from a mismatch between the demo data's time zone setting and the test's expectations. The fix ensures the test accurately reflects the OdooBot's time zone, improving the reliability of the live chat testing process.
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 Forward-Port-Of: odoo/odoo#244422
This update resolves a sporadic failure in the 'Copy Message Link' test within Odoo. The previous test relied on unreliable keyboard shortcuts, leading to inconsistent results. The updated test uses a more robust method to ensure the copy functionality works correctly and reliably.
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 Forward-Port-Of: odoo/odoo#244547
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV report exports. Now, invoices with specified foreign currency rates will accurately reflect those rates when generating the CSV file, ensuring accurate financial reporting. This resolves a potential discrepancy in data export.
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 foreign currency rate set on invoices, ensuring accurate reporting for our German clients. This improves the reliability of financial 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 test failure related to user access permissions within the Odoo Enterprise payroll system. A change was made to allow specific group access to the GOSI API, resolving a technical issue that prevented automated testing. This ensures consistent and reliable payroll testing.
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 resolves a bug that prevented users who are employees in multiple companies from accessing their timesheets. The fix ensures the correct company-specific resource is selected, allowing seamless timesheet access. This improves usability for employees managing time across different business units.
Original PR description
In this commit, we fix an issue that occurs when opening Timesheets with the current user being an employee in multiple companies. Previously, an error was raised because there are multiple resources associated to the current user. The issue is fixed by selecting the resource associated to the employee of the current user in the current company. # Steps to reproduce the issue - Create new company and select it - Go to "users", select current user (i.e., admin) and click on "create employee" (must be in debug mode) - Open timesheets # Expected Behavior - Should open the timesheets of the current user in the current company # Current Behavior - Crashes as there are multiple resources for the user (one per company) task-5729113
This update resolves two issues related to overtime calculations. First, it prevents the creation of overtime work entries when no 'paid' rules are present in a ruleset. Second, it corrects a bug where regenerating work entries caused shifts in hours between consecutive days. This ensures accurate overtime tracking and payroll processing.
Original PR description
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that…
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that normally generates overtime. - Navigate to the work entries in payroll. - Overtime work entries are created! This fix will skip generating work entries when their will be no `paid` rules in a ruleset. # Bug 2: ## Steps to reproduce: - Create attendances with overtime for multiple consecutive days. - Navigate to Work Entries in Payroll. - Click on Reset->"Regenerate Work Entries” on the same period for bulk regeneration. - Observe that attendance and overtime hours are shifted between days. ### Fix: In `_get_overtime_intervals`, the overtime list was recreated inside the per-day loop, causing previously computed overtime intervals to be lost when multiple days were involved. Overtime intervals are now accumulated per resource across all days in the requested range before building the final Intervals. task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151) Forward-Port-Of: odoo/enterprise#104295 Forward-Port-Of: odoo/enterprise#103028
This update resolves an error that occurred when users deleted the 'Balance' line in the General Ledger Report. The fix prevents the report from crashing when a balance isn't present, ensuring a smoother user experience. This improves the reliability of a core accounting function.
Original PR description
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting >…
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting > Configuration > Accounting (section) > Accounting Reports - Open the General Ledger report - Delete the balance line from the Column tab - Go to Reporting > General ledger >> Error occurs (If an error does not occur, try opening the detailed view of the journal in the report.) Error: `KeyError: 'balance'` This issue was generated because at code line [1] tries to access `balance` key from the `colname_to_idx[col_group_key]` but since the user deleted `balance` it will not fount there and we got an error. This commit fixes the issue by preventing the processing of `line_balance` when the balance key is not present in `colname_to_idx[col_group_key]`. [1]: https://github.com/odoo/enterprise/blob/340abdc1b00df4d3d6130b26650519ae8354d199/account_reports/models/account_general_ledger.py#L326 sentry-7105657812 Forward-Port-Of: odoo/enterprise#104170 Forward-Port-Of: odoo/enterprise#102113
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 properly completing the tour and accessing related features. The fix ensures the tour waits for form autosaves, guaranteeing a clean and functional experience.
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 Forward-Port-Of: odoo/enterprise#104725
This update fixes a problem that occurred when Odoo servers stopped, causing errors related to database connections. The fix ensures these errors are ignored during shutdown, preventing disruptions and maintaining stability. This improves the overall reliability of the Odoo platform.
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
A recent test failed due to a problem with how payment providers were linked to companies within the demo data. This update ensures that each website has only one payment provider assigned, and that provider's company is aligned with the website's company information. This prevents errors and improves the reliability of the website's payment functionality.
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 improves the ability to utilize Peppol for international payments.
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 resolves an issue that prevented users from exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly validates the presence of at least one contact for the company partner. This improves the reliability of SAFT report generation.
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 fixes a reporting issue related to Bebat, a Belgian organization recycling batteries. It ensures the correct tax codes (64 for 'Special agreement' and CAV for 'Battery collection and recycling') are used when generating UBL invoices, aligning with Bebat's activities and regulatory requirements.
Original PR description
[FIX] account_edi_ubl_cii: EPD allowance/charge code should be 64, not 66 64 stands for "Special agreement" 66 stands for "New outlet discount" opw-5478324 [FIX] account_edi_ubl_cii: Bebat allowanceChargeReasonCode should be CAV Bebat is a non-profit organization in Belgium that collects, sorts, and recycles used batteries. Currently, whatever the recycling tax applied, we report is as AEO for "Collection and recycling - The service of collection and recycling products." However, since Bebat is about recycling batteries, we have to use CAV instead for "Battery collection and recycling - The service of collecting and recycling batteries." opw-5474752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243064
This update resolves a crash issue within the website builder when users customize shadow properties. The fix prevents errors caused by mismatched shadow formats, ensuring a more stable experience for users modifying column styles. This improves the overall reliability of the website builder.
Original PR description
Forward-Port-Of: odoo/odoo#244244
This update resolves a technical issue preventing a key test for embedded actions in the Odoo web interface. The fix ensures the test correctly handles the opening of dropdown menus, improving the reliability of our action testing process. This contributes to a more stable and functional Odoo experience.
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 fixes a performance issue in the translation sidebar. By preloading translated elements, the sidebar now renders fully before tests begin, preventing delays and ensuring tests pass consistently. This improves the reliability of our translation testing 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#244519 Forward-Port-Of: odoo/odoo#242490
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 within the discount computation, 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 prevents errors when creating inter-company invoices by ensuring that 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 removes a recent change that was causing performance issues and instability within our spreadsheet dashboards. 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 a stable and reliable experience for users.
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 Forward-Port-Of: odoo/odoo#244274
This change removes a recent update that was causing issues with spreadsheet functionality. The effort to implement etag computation in spreadsheets was deemed too costly compared to the benefits, so this reversion restores the previous spreadsheet behavior. This resolves existing problems and prevents future complications.
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 Forward-Port-Of: odoo/enterprise#104615
This update resolves an issue where grouping accounting records by their root account was failing, resulting in an error. The change allows for optimized domain searches, ensuring that grouped record sets display the expected nested data. 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 enhances the reliability of website content generation by ensuring images are correctly updated and reducing database queries. The changes address a previous issue where customized images weren't being replaced properly and optimize the process for better performance and stability.
Original PR description
Added commit_progress during website generation, this is now required due to the reduction of the timeout delay of crons as well as to ensure robustness. Fixed bug where the customized images where not replaced correctly. It happens because we were copying the original instead of fetching the modified one. Switch to record operations in batch to reduce number of queries. Forward-Port-Of: odoo/enterprise#104521
This update fixes a minor usability issue in the contact view of delivery addresses. The GLN field was awkwardly positioned and lacked a label, making it difficult to find. The change repositions the label before the notes field for better clarity and ease of use.
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 corrects a technical issue that prevented test cases from running correctly. The team moved fields related to rental agreements from one Odoo module to another, but some related code wasn't updated. This fix ensures all test cases now run smoothly.
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 Forward-Port-Of: odoo/enterprise#104817
This 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 properly 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 corrects a technical issue where the payment callback URL was being triggered incorrectly, causing verification problems. The fix ensures that the callback URL only activates when a redirect is expected, aligning with Razorpay's documentation and improving payment processing reliability. This resolves a potential disruption to UPI payments.
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 clarifies the reasons why Stripe might reject an expense authorization request. It now includes a specific 'authorization_controls' reason, translating it into a user-friendly explanation for better expense reporting and reconciliation. This ensures accurate tracking of Stripe authorization issues.
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 an issue where copying headings caused URL redirection problems due to duplicate IDs. It also optimizes the heading link button's behavior, preventing unnecessary layout adjustments triggered by mouse movements. These changes ensure a smoother and more reliable experience when working with headings in the knowledge editor.
Original PR description
### [FIX] knowledge: prevent heading link id duplication on copy/paste Prior to this commit, copy/pasting a heading would preserve its `data-heading-link-id` resulting in mismatches for URL redirections. After this commit, such ids are always reset to guarantee unicity. ### [FIX] knowledge: throttle mousemove for heading link button Prior to this commit, every `mousemove` event could cause a layout trashing to reposition the heading link button. After this commit, the repositioning is debounced at a more reasonable rate. task-5384684 Forward-Port-Of: odoo/enterprise#104530 Forward-Port-Of: odoo/enterprise#101445
This update resolves an issue where the final chatbot answer wasn't saved or shown in the side panel. The fix ensures the user's response is correctly recorded and displayed, and the chat session is properly closed after the final step. This improves the user experience and data accuracy for chatbot interactions.
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#244558 Forward-Port-Of: odoo/odoo#235102
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 URLs were appearing twice in WhatsApp messages due to a technical formatting error. The fix prevents the duplication of URLs by adjusting how the Odoo UI's HTML is converted to plain text for WhatsApp messaging, ensuring a cleaner and more accurate message experience for users.
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 removes an unnecessary credit note warning from the GSTR report, streamlining the reporting process. Previously, the warning conflicted with credit note confirmation, requiring manual intervention. Now, the warning disappears automatically when the credit note is fully processed and checked.
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#104752 Forward-Port-Of: odoo/enterprise#102106
This update resolves a technical error in the l10n_ae_hr_payroll module's testing process. Specifically, a test was incorrectly creating bank records, which has now been corrected to ensure accurate reporting. This ensures the integrity of financial data within the system.
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 Forward-Port-Of: odoo/enterprise#104797
This update resolves a bug where alternative purchase orders were calculating prices incorrectly due to a conflict during testing. The fix aligns the test with recent currency rate updates, ensuring accurate price comparisons for alternative purchase orders. This ensures correct pricing calculations for a critical business process.
Original PR description
Issue before this commit: ========================= The test_12_alternative_po_line_different_currency test was moved to the purchase_alternative module in this…
Issue before this commit: ========================= The test_12_alternative_po_line_different_currency test was moved to the purchase_alternative module in this [PR](https://github.com/odoo/odoo/pull/218612). At the same time, the currency rate logic was updated in another [PR](https://github.com/odoo/odoo/pull/231948). During conflict resolution, the test was mistakenly reverted to the old behaviour, causing the test to break. As a result, the alternative PO price comparison became incorrect. Steps to Reproduce: ========================= - Install the purchase_alternative module. - Run the test: test_12_alternative_po_line_different_currency test case. - The test fails at: self.assertEqual(best_price_ids[0], po_alt.order_line.id) Cause of the issue: ========================= Recent currency rate changes introduced in [PR](https://github.com/odoo/odoo/pull/231948), That PR ensures that Currency rates are valid only starting the next day. During conflict resolution, these changes were removed from the test, causing invalid currency rates, leading to incorrect price comparisons. With This Commit: ========================= Ensure the test runs correctly by aligning it with the updated currency rate logic. runbot-build-error: [237989](https://runbot.odoo.com/odoo/runbot.build.error/237989)
This update resolves a compatibility issue with an older version of Odoo's spreadsheet functionality. Specifically, it ensures the spreadsheet feature continues to work correctly with older Odoo releases. This prevents disruptions for users who haven't yet upgraded to the latest Odoo version, maintaining a smoother experience.
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 prevents portal users with existing sales orders from modifying their country information through the profile settings. Previously, this setting was restricted for system administrators but not for portal users. This change ensures data consistency and prevents users from overriding important business information linked to their accounts.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241908 Forward-Port-Of: odoo/odoo#237781
This update resolves an issue where the 1099 report incorrectly assigned the payer company when generating reports with multiple companies. The fix ensures that each line item in the 1099 report accurately reflects the correct payer company, improving the accuracy of tax reporting. This impacts users utilizing the multi-company accounting setup.
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 validation error that occurred when users attempted to unbuild tracked products. The issue stemmed from the system incorrectly reusing previously consumed serial numbers within the same manufacturing order. This change ensures accurate inventory tracking by preventing the re-assignment of serial numbers, improving order processing reliability.
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 simplifies the logging from our IoT drivers to improve readability and reduce unnecessary data. We've removed irrelevant details like process IDs and database names, and now securely identify the IoT Box using a shared token. This enhances log analysis and troubleshooting.
Original PR description
To ease readability in db's logs, we removed PID number and useless database name (as we don't have a db on the IoT Box) from the logs sent to the db. In addition, we now ensure IoT Box identity using the shared token, provided as an authorization header. see odoo/enterprise#102890
This update fixes a technical error that prevented users from correctly scheduling resource appointments within the Odoo system. The change adjusts how appointment availability is calculated, ensuring compatibility with the latest data format and preventing a 'ValueError' from occurring. This improves the reliability of the appointment scheduling process.
Original PR description
Steps to reproduce =================== 1. Open appointment app. 2. Click on resource appointment to open gantt view. => ValueError: too many values to unpack With commit [1], `_get_unavailable_intervals` now returns an interval object instead of a list of datetime ranges. However, the gantt resource unavailability logic was still expecting a list and unpacking start/stop values. This commit updates the logic to handle interval objects and extract the expected start and stop dates correctly. [1] https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be Task-5785529
This update adjusts the location of the GCC format checkbox within the Odoo settings, placing it within the 'Customer Invoices' section. This ensures 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 resolves an issue where outdated tests were lingering after a change to the canned response shortcut. The tests were removed to streamline the suite and ensure accurate results moving forward. This change improves the stability and reliability of the live chat feature.
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#244655 Forward-Port-Of: odoo/odoo#244472
This update resolves a recurring error on the IoT box where the Bluetooth adapter wasn't immediately ready, causing connection problems. The fix ensures the system handles the initial adapter startup more gracefully, preventing errors and improving the device's ability to connect to Bluetooth devices. This improves the reliability of the IoT box's functionality.
Original PR description
This PR fixes the bluetooth exceptions seen on the iot box when the bluetooth adapter isn't ready ``` 2026-01-14 10:05:48,596 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in…
This PR fixes the bluetooth exceptions seen on the iot box when the bluetooth adapter isn't ready
```
2026-01-14 10:05:48,596 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in thread Thread-3:
2026-01-14 10:05:48,743 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-01-14 10:05:48,745 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/odoo/.local/lib/python3.13/site-packages/gatt/gatt_linux.py", line 138, in start_discovery
self._adapter.SetDiscoveryFilter(discovery_filter)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
return self._proxy_method(*args, **keywords)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
return self._connection.call_blocking(self._named_service,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
self._object_path,
^^^^^^^^^^^^^^^^^^
...<3 lines>...
args,
^^^^^
**keywords)
^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/connection.py", line 696, in call_blocking
reply_message = self.send_message_with_reply_and_block(
message, timeout)
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: dbus.exceptions.DBusException: org.bluez.Error.NotReady: Resource Not Ready
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger:
During handling of the above exception, another exception occurred:
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
self.run()
~~~~~~~~^^
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/bluetooth_interface_L.py", line 66, in run
dm.start_discovery()
~~~~~~~~~~~~~~~~~~^^
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/odoo/.local/lib/python3.13/site-packages/gatt/gatt_linux.py", line 142, in start_discovery
raise errors.NotReady(
"Bluetooth adapter not ready. "
"Set `is_adapter_powered` to `True` or run 'echo \"power on\" | sudo bluetoothctl'.")
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: gatt.errors.NotReady: Bluetooth adapter not ready. Set `is_adapter_powered` to `True` or run 'echo "power on" | sudo bluetoothctl'.
```
Forward-Port-Of: odoo/odoo#243870This update corrects a bug where invoice XML files were incorrectly using the customer's VAT number instead of their company registration number (ondernemingsnummer) for key identification fields. The change ensures invoices comply with EU e-invoice standards, improving data accuracy and avoiding potential processing issues. This was achieved by prioritizing the company registry data source.
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#244518 Forward-Port-Of: odoo/odoo#243143
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 reflect the remaining points owed. Now, the system recalculates loyalty programs to ensure points are updated accurately after quantity changes, improving the accuracy of customer rewards.
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#244082 Forward-Port-Of: odoo/odoo#242816
This update corrects a technical issue preventing access to certain payroll features for specific user groups. The change adds group permission controls within the HR employee configuration, ensuring proper access rights are enforced. This resolves a test failure and improves the stability of the payroll system.
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 Forward-Port-Of: odoo/enterprise#104883
This update resolves an issue where changing a tax lock date to a past date would trigger an error. The fix prevents the system from generating default external values when the lock date is set in the past, ensuring smoother operation and preventing unexpected errors.
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 previous issue where the Apps application incorrectly showed zero industry module counts. By adding version information to the route arguments, the system now accurately displays the exact number of modules by category, aligning with changes in the apps.odoo.com API.
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 fixes a technical issue where a new fiscal reform field was incorrectly used in the Point of Sale module. The change was identified late due to legal requirements and automatic installation. The fix moves the necessary logic to the correct module for proper functionality and ensures compliance with the latest regulations.
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 resolves an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The change ensures avatars are displayed correctly using the 'object-fit: cover' style, providing a consistent and professional user experience. This improves the visual quality of user profiles.
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 reverts a recent change that introduced new features to the mobile dashboards. It now returns the dashboards to display only charts, simplifying the user experience. Some adjustments 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
This update optimizes the calculation of product costs within Odoo, specifically addressing a performance bottleneck in the inventory module. By separating the cost calculation logic, the system now avoids unnecessary database queries, resulting in significantly faster loading times for common inventory views. This improves overall system responsiveness.
Original PR description
Issue: With the recent changes for valuation, multiple product valuation fields are computed via one compute method _compute_value. One such field is avg_cost, which will always call the…
Issue: With the recent changes for valuation, multiple product valuation fields are computed via one compute method _compute_value. One such field is avg_cost, which will always call the _get_standard_price_at_date method under all circumstances. _get_standard_price_at_date results in additional queries being run, which become costly en-mass in the case of many products being read. This results in unnecessary overhead for workflows which only read one of the other fields in the compute, such as total_value. For instance, when accessing the locations list view in the inventory application, roughly 2/3 of the execution time is spent running queries to calculate avg_cost even though the field is not being read. Solution: A new compute method _compute_avg_cost must be made, which simply separates the avg_cost logic from the multi-field _compute_value method. This way, additional queries resulting from _get_standard_price_at_date are avoided for workflows which do not require such information. Benchmark: Loading the inventory > locations list view for a DB with several thousand locations and products: | Before | After | |----------|---------| | 2.9 sec | 0.9 sec | opw-5224646
This update fixes an issue where product names on invoices were being incorrectly concatenated, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain separate and adhere to API specifications, improving invoice clarity and compliance.
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