Daily updates from Odoo
Saturday, December 20, 2025
11 changes
5 changes
Resolved issues and error corrections
This update resolves an error that prevented vendor bills from being correctly sent to eTIMS. The issue stemmed from incorrect eTIMS configuration during company setup. Now, the system will correctly handle sending bills to eTIMS when the eTIMS settings are properly configured.
Original PR description
Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills. Steps to Reproduce: - Install `l10n_ke_edi_oscu` module without demo data. - Create a New company with `Kenya` as…
Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.
Steps to Reproduce:
- Install `l10n_ke_edi_oscu` module without demo data.
- Create a New company with `Kenya` as the Country and switch to it.
- Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
- Confirm it, then click `Send to eTIMS`.
Traceback:
```py
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
content = move._l10n_ke_oscu_json_from_move()
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
tax, line_tax_details = next(
StopIteration: null
```
This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.
Here we raise a warning when the `eTIMS` configuration is not set up correctly.
[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93
sentry-7083978544
Forward-Port-Of: odoo/enterprise#101319This update resolves a bug where custom embedded actions weren't consistently displayed across different Odoo projects. The fix ensures that actions are correctly loaded and available in the top bar, regardless of which project a user is currently working in or if they refresh the page. This improves the user experience and functionality of embedded actions.
Original PR description
Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces…
Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs:
- Create a project A and project B, activate the top bar in both projects
- Create a new custom embedded action in project A
- Switch to project B (by changing the URL), the custom action of project A is present in project B
- In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar.
It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action.
We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction".
task-5269261
Forward-Port-Of: odoo/odoo#240558
Forward-Port-Of: odoo/odoo#237695This update resolves an issue where administrators could access employee details from the Point of Sale (PoS) frontend. The fix simply disables the ability to open the employee form, aligning with the intended use of employee data within the backend system. This improves the user experience and prevents unnecessary access.
Original PR description
Steps to reproduce ------------------ 1. Enable "Log in with Employees" 2. Login with any employee and make an order 3. Switch to the admin, "Mitchell Admin" usually 4. Go to the paid orders (we are still in PoS UI not in the backend), and select the order paid in step 2. 5. Click on "Details", the order form will appear, click on the "Cashier" name A traceback will appear, saying 'Cannot find key "hr_employee_form" in the "views" registry'. The fix ------- We simply disable the employee_id field; it will not try to open the employee form anymore. That is much simpler than adding all the required hr assets to the PoS frontend. Employee details are meant to be seen and navigated from the backend. opw-5252486 Forward-Port-Of: odoo/odoo#240012
This update enhances how other Odoo modules can customize activity actions. By separating the action execution step, developers can now easily add specific behaviors, like loading custom views, without needing to duplicate existing logic. This improves flexibility and integration with other parts of the system.
Original PR description
The `openActivityGroup` method in `ActivityMenu` currently handles both the preparation of filters (domains, contexts) and the actual execution of the action. This coupling prevents other modules from intercepting the action execution to inject specific behaviors—such as loading a specific server-side action or specialized views—without completely overriding the method and duplicating the filter logic. This commit extracts the final execution step into a new method `executeActivityAction`. This allows extending modules (e.g., `documents`) to customize the action load (e.g., to ensure specific JavaScript hooks are initialized) while relying on the base implementation for domain and context generation. Task-5187045 Forward-Port-Of: odoo/odoo#240560 Forward-Port-Of: odoo/odoo#238377
This update resolves an issue where navigating to documents from the 'Activities' icon caused the custom document view to fail, preventing features like document previews. The fix ensures the correct custom view is loaded, guaranteeing the desired functionality works as expected for users.
Original PR description
When navigating to documents from the 'Activities' systray icon, the system would load an action that correctly filtered for "My Activities" but lacked the specific view definitions of the main Documents app. This caused the 'List' view-switcher to load the default list view instead of the custom one, breaking features like document preview that depend on the custom view's JavaScript. This patch fixes the issue by ensuring that the correct, custom view definitions from the main Documents app are loaded. This guarantees that the custom list view and all its features work correctly, regardless of how the user navigates to it. This ensures the correct custom list view is loaded while preserving the "My Activities" filter. Task-5187045 Forward-Port-Of: odoo/enterprise#102442 Forward-Port-Of: odoo/enterprise#98979
3 changes
Resolved issues and error corrections
This update resolves an issue where sending vendor bills to eTIMS would fail due to incorrect eTIMS configuration. Specifically, the system requires the 'eTIMS Server Mode' to be set up correctly for the process to function. This change ensures the system correctly handles new company setups and prevents the error.
Original PR description
Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills. Steps to Reproduce: - Install `l10n_ke_edi_oscu` module without demo data. - Create a New company with `Kenya` as…
Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.
Steps to Reproduce:
- Install `l10n_ke_edi_oscu` module without demo data.
- Create a New company with `Kenya` as the Country and switch to it.
- Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
- Confirm it, then click `Send to eTIMS`.
Traceback:
```py
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
content = move._l10n_ke_oscu_json_from_move()
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
tax, line_tax_details = next(
StopIteration: null
```
This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.
Here we raise a warning when the `eTIMS` configuration is not set up correctly.
[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93
sentry-7083978544
Forward-Port-Of: odoo/enterprise#101319This update resolves a bug that prevented administrators from accessing employee details within the Point of Sale (PoS) interface. The fix simply disables a feature that was causing errors, streamlining the user experience and ensuring PoS functionality remains stable. Employee information is intended to be managed from the backend.
Original PR description
Steps to reproduce ------------------ 1. Enable "Log in with Employees" 2. Login with any employee and make an order 3. Switch to the admin, "Mitchell Admin" usually 4. Go to the paid orders (we are still in PoS UI not in the backend), and select the order paid in step 2. 5. Click on "Details", the order form will appear, click on the "Cashier" name A traceback will appear, saying 'Cannot find key "hr_employee_form" in the "views" registry'. The fix ------- We simply disable the employee_id field; it will not try to open the employee form anymore. That is much simpler than adding all the required hr assets to the PoS frontend. Employee details are meant to be seen and navigated from the backend. opw-5252486 Forward-Port-Of: odoo/odoo#240012
This update resolves an issue where the ‘eas’ field was incorrectly focused during Peppol registration. By removing the field’s focusability, the system now correctly pre-selects this field, streamlining the registration process for users and ensuring accurate data input.
Original PR description
During registration on Peppol, the eas field is focused first, which makes no sense as it's supposed to be correctly preselected, and users aren't supposed to touch it So this commit makes it non-focusable 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#240679
2 changes
Resolved issues and error corrections
This update allows users to export Intrastat reports in XML format, addressing previous limitations that caused submission issues. Previously, reports were automatically generated in a specific format, now users can select the desired format and data inclusion, ensuring accurate report submissions to OneGate.
Original PR description
**Behavior:** Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This…
**Behavior:** Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This causes issues for some users that want more specific formats like standard over extended, only arrivals/dispatches or both, etc... And this can cause them to not be able to submit their reports. The solution is to currently reenable the user to export their report to XML from a cog menu in the Intrastat Report view. While still leaving the current flow through account.return possible, until a better solution is thought of. **Steps to reproduce:** - Connect to a company under Belgian Localisation. - Create a product and, under the Accounting tab, specify a Commodity code (eg Live asses) and Country of Origin (Belgium) - Create an Invoice containing the product to a Client in another EU Country (eg Luxembourg) and under the 'Other Info' tab, specify Intrastat Countrt (Belgium) - You can choose to leave out Intrastat Transport Mode and Incoterm, this will make the resulting XML have some missing informations - Create a Bill with the product with the same settings - If you go to Intrastat Report, after changing the 'Report' filter to Intrastat (Goods) you will now be able to see an arrival and a dispatch. The extended mode filter is enabled by default, if you didnt fill Intrastat Transport Mode and Incoterm, you will see these missing. - From this view there is currently no way to export the XML, to do that click the Returns button (select an Opening Date for accounting if needed), click on 'New' and specify Intrastat in the Return Type and a time window containing your Invoice and Bill. - Then you will see an Intrastat Report show up and after selecting Review, then Submit, you will be able to download the XML. which will contain dispatches and arrivals and will be in Extended Mode. Which, if missing Transport/Incoterm, will fail when submitted to OneGate opw-5347238 Forward-Port-Of: odoo/enterprise#102531
This update resolves an issue where WhatsApp sign requests from multiple companies were failing due to template access restrictions. The fix ensures users only see templates they are authorized to use, regardless of the company sending the request, improving the reliability of WhatsApp sign functionality.
Original PR description
Currently, WhatsApp templates are linked to the default company, causing access errors when sending sign requests from other companies. This patch filters templates based on the user's access rights to avoid AccessErrors and clarify which templates are available per company. task-5424781 Forward-Port-Of: odoo/enterprise#102456
1 change
Resolved issues and error corrections
This update corrects a bug where manually adjusted prices on customer invoices were being reset when the invoice's fiscal position was changed. The fix ensures that prices remain as the user set them, mirroring the behavior in Sale Orders. This improves invoice accuracy and reduces manual adjustments.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a customer invoice with at least one product line. * Manually adjust the **price_unit** on the invoice line. * Change the fiscal position on the invoice. * Click the **Update Taxes and Accounts** button. **Observed behavior:** * The manually adjusted price is reset to the product’s default sales price (e.g., 1000). * This occurs even though neither the product nor the UoM changed. * In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation. **Cause:** * `action_update_fpos_values` method call the recomputation of unit price each time when we click update taxes and accounts button on invoice. **Fix:** * Add a condition to **skip price recomputation** when fiscal position changes. * This preserves manual prices when only the fiscal position changes. opw-5252832