Daily updates from Odoo
Thursday, January 8, 2026
16 changes · saas-18.4
Resolved issues and error corrections
This update prevents the loss of delivery orders when label creation fails during integration with Starshipit. Previously, a failed label attempt would delete the order, now users can correct the data and retry validation without losing their existing order information. This enhances the reliability of the delivery process.
Original PR description
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the…
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order. ## Steps to reproduce: 1. Validate a delivery order integrated with Starshipit. 2. Trigger a label generation failure (e.g., bad address). 3. Observe that the created Starshipit order is deleted. ## Cause of the issue: The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order. ## Fix: Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual. ## Additional note: The _() wrapper in the error line was removed because the Starshipit service has no env or language context. Since translations cannot be resolved there, Odoo raised a warning. Removing _() avoids this warning and keeps the error clean. opw-5306979 Forward-Port-Of: odoo/enterprise#103354 Forward-Port-Of: odoo/enterprise#101174
This update resolves an issue where users without administrator permissions encountered errors when opening duplicated reports within the Studio feature. The fix prevents a traceback by ensuring the system handles permission errors gracefully, improving the user experience for all users.
Original PR description
When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised. Steps to reproduce the error: - Install ``account`` and ``web_studio`` - Login as…
When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised. Steps to reproduce the error: - Install ``account`` and ``web_studio`` - Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo - Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report - Login as Mitchell Admin, remove administrator right of Marc Demo - In Mark Demo, Open the duplicated report Traceback: ```py UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value ``` https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``. For users without the required permissions, this ``search()`` raises an AccessError. https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400 Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound. However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``. sentry-7149350379 Forward-Port-Of: odoo/enterprise#103017
This update ensures that report views in Odoo Enterprise consistently use unique keys, regardless of a template's active or inactive status. Previously, inactive templates could cause duplicate keys, leading to customization issues and potential conflicts. This fix improves report stability and prevents unexpected behavior.
Original PR description
Before this commit: ------------------------- The sequence used in the template key was computed based only on the last active template. If the next sequence number corresponded to an inactive…
Before this commit: ------------------------- The sequence used in the template key was computed based only on the last active template. If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template. After this commit: ----------------------- The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive. This ensures that template keys remain unique across all report templates. Why this commit: ----------------------- if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys. This fix prevents such conflicts by ensuring unique template key generation. Forward-Port-Of: odoo/enterprise#101894
This update resolves an issue where grouped Kanban cards in the Knowledge Articles module were displaying incorrectly due to a change in the Kanban template design. The fix simply removes a no-longer-needed CSS class, ensuring consistent and correct card heights are displayed.
Original PR description
Since commit https://github.com/odoo/enterprise/pull/70460 and the reworking of the Kanban templates, the h-100 class was no longer correct. This PR fixes the issue by removing this class. task-5439265 Forward-Port-Of: odoo/enterprise#102801
This update corrects a previous approach to handling tax information for Brazilian service invoices related to the recent fiscal reform. Now, all required tax details specific to the reform must be consistently included in the XML reports, ensuring accurate compliance. This change improves the reliability of tax reporting for our Brazilian customers.
Original PR description
Before the fiscal reform, we deliberately avoid sending back informative taxes for service invoices because they may change depending on how and when the invoice is paid and they only need to appear on the XML optionally. New informative taxes specific to the fiscal reform are required to appear on the XML and therefore we must always send them. task-5450142
This update fixes a problem where invoice names weren't correctly linked to Avalara transactions. By reverting to a previous method of recreating transactions after posting, Odoo ensures that Avalara receives the necessary invoice information for accurate tracking. This improves the reliability of tax processing and cross-referencing.
Original PR description
In the external tax refactor [1] I wanted to use the commit endpoint to commit transactions in Avalara after posting. It works, but now transactions on Avalara's side are missing the Odoo invoice name references. It's still possible to cross-reference transactions using avatax_unique_code, but it's less convenient. The reason is that we create transactions for draft invoices. They don't have a name yet. Avalara doesn't have a way to update just the code so we revert back to the pre-refactor approach of recreating the entire transaction right after posting with `'commit': True`. `account_external_tax` calculates the taxes right before `_post()`, so we're reasonably sure they should remain the same. In master we can remove all the commit-specific methods and code. [1] https://github.com/odoo/enterprise/pull/82623 opw-5382268
This update fixes an issue where string values entered in the Odoo Studio were incorrectly formatted with extra quotes and slashes. Now, string field options are correctly displayed and saved, ensuring accurate data input and consistency within the Studio interface.
Original PR description
Have a field widget with an option of type "string" (supportedOption meta field of the widget) In studio, change the value for that option. Before this commit, the value appeared in the input as escaped: there were supplementary quotes and slashes After this commit, the string value is correctly displayed. Forward-Port-Of: odoo/enterprise#103476 Forward-Port-Of: odoo/enterprise#103364
This update fixes an issue where the wrong manager was sometimes assigned to approval requests. The change ensures the correct manager, based on the request, is always identified, preventing errors and improving approval processing. This resolves a potential inconsistency in the approval workflow.
Original PR description
The previous code added the manager by searching for the first employee that matches the request_owner_id. If there are multiple such employees, it's possible that an employee from a different company than the approval can be selected. Ticket: [5185449](https://www.odoo.com/odoo/project.task/5185449) Forward-Port-Of: odoo/enterprise#99978
This update resolves a technical error that prevented recruitment officers from correctly updating applicant stages. The fix ensures that the system handles access restrictions properly, preventing errors when moving applicants to the 'qualified' stage and updating related email templates. This improves the reliability of the recruitment process.
Original PR description
Problem: Recruitment officers don't have the rights to create `appointment.type` nor `appointment.interview`, Hence when they move an applicant to the qualified stage an error is raised during the rendering the body of the qweb mail template. Fix: Override the controller to use sudo and pybass the access check. Task-5262936 Forward-Port-Of: odoo/enterprise#100648
This update fixes a visual issue where a duplicate dropdown menu appeared when editing or deleting social stream posts. The fix ensures the existing 'social_crm' dropdown correctly integrates with the new 'social' dropdown, maintaining a consistent user experience. Additionally, the 'is_author' field was re-introduced to manage button visibility for personal posts.
Original PR description
Following https://github.com/odoo/enterprise/commit/c9ddf1c a new dropdown has been added to "social" to allow the edition and deletion of a social stream post. This new dropdown didn't take into account the one already existing in "social_crm" resulting in a duplicated dropdown menu. Fixing the issue by making sure the dropdown from "social_crm" is correctly extending the one from "social". As the "Create Lead" action is set above the "Edit" and "Delete" ones, making sure it's also the case for the stream post comments dropdown menu for consistency. Re-inserting the "is_author" field (removed here https://github.com/odoo/enterprise/pull/69650) in the kanban view to make sure the "Edit", "Delete" and "Create Lead" buttons visibility are correctly managed for your own posts. Task-5270180 Forward-Port-Of: odoo/enterprise#103409 Forward-Port-Of: odoo/enterprise#101679
A recent update to the 'account_no_followup' module, automatically installed to support another module, triggered a memory error in existing Odoo databases. This fix avoids the error by initializing the module's data directly in the database, preventing the system from running out of memory.
Original PR description
The module `account_no_followup` is a new module added in odoo/enterprise#96627. Since it's marked as `auto-install=True` and since it's a dependency of the new `pos_no_followup` module, it may be installed on existing 18.0 databases with a lot of account.move.lines. In this case, the module installation will raise a MemoryError as there's a new stored computed field on journal items called `no_followup`. Computing this field and storing the value in cache will overfill `self.env._cache` and reach the 2GB threshold. This commit fixes that by adding an overwrite of the `_auto_init` method to initialize the field's value in raw SQL, circumventing the issue. Forward-Port-Of: odoo/enterprise#102330
This update resolves an issue where refreshing Facebook account statistics could fail due to differences in how the datetime library handles timezones. The fix ensures compatibility across different Python versions by standardizing the timezone format, preventing errors related to '+0000' versus '+00:00'.
Original PR description
Bug
===
When refreshing the statistics of a Facebook account, an error can happen, depending on the datetime library version.
The following work in python 3.11, but not on python 3.10 and earlier, due to `+0000` instead of `+00:00`.
```py
import datetime
datetime.datetime.fromisoformat('2025-11-16T08:00:00+0000')
```
Task-5473117
Forward-Port-Of: odoo/enterprise#103456This update fixes an issue where applying full amounts to bank statement lines was incorrectly triggering tax calculations. This change ensures that tax calculations are only applied to lines that actually require them, improving the accuracy of financial reporting. The fix was implemented to address a bug introduced in a previous commit.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/5893005187fd67613baaae38e58e126dc9e28544 It could happens that on lines that come from an invoice or a payment (so lines with reconciled_lines_ids. Applying the full amount would trigger the edit_tax_line function which shouldn't be the case since those lines cannot have tax set on them. no task id Forward-Port-Of: odoo/enterprise#103334
This update fixes an issue where changes to rental order dates weren't automatically reflected in the transfer schedule. The fix mimics the rescheduling behavior of purchase orders, ensuring rental transfers are updated accurately when a rental order's dates are adjusted. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#102437 Forward-Port-Of: odoo/enterprise#101334
This update resolves a recurring test failure related to a specific date used in the l10n_mx_edi module. By setting a more standard test date, the tests are now consistently passing, ensuring reliable development and preventing disruptions.
Original PR description
Some tests are making "self.frozen_today - timedelta(days=1)". It means some tests are failing only the first of January. To avoid that, let's make "frozen_today" to be in the middle of the year. Forward-Port-Of: odoo/enterprise#102827 Forward-Port-Of: odoo/enterprise#102772
This update resolves an issue where precommit hooks in Odoo's database system could cause errors due to manual flushing requirements. By allowing the ORM to handle flushing automatically, this change enhances database stability and prevents potential infinite loops. This ensures data consistency and reduces the risk of disruptions.
Original PR description
In the existing implementation sometimes precommit hooks need to flush manually because they are ran after the flush is executed in the cursor. A precommit that triggers ORM changes may be not flushed unless it is done explicitly, however an explicit call may turn into an infinite loop. This removes the need to flush in precommit hooks and let the ORM handle it safely. Flushing of the environment was already done in #220379. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242248