Saturday, December 20, 2025
5 changes · saas-18.4
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