Thursday, January 8, 2026
8 changes · saas-18.2
Resolved issues and error corrections
This update resolves an issue where users without administrator permissions would encounter an error when attempting to open duplicated reports within the Studio interface. The fix prevents a critical error by ensuring the system handles permission restrictions 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 prevents issues where inactive report templates could inadvertently share the same template keys, leading to customization conflicts and incorrect report generation. By ensuring unique keys for all templates, this fix improves the reliability and accuracy of report views across the Odoo Enterprise platform.
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 a technical issue where order completion with UrbanPiper resulted in an 'undefined street' error. The fix ensures the system correctly checks if a customer is assigned before completing an order, preventing this error and allowing users to successfully mark orders as ready and print receipts.
Original PR description
Steps to produce: ==== - Place an online delivery order through urbanpiper - Edit the order and remove customer - Complete the order as Marks as Ready - Print Reciept Issue: ==== - TB occurs stating undefined street Fix: ==== - Check whether partner is assigned or not task-5407001 Forward-Port-Of: odoo/enterprise#102100
A previous change prevented users from selecting analytic items when clicking on them within the accounting module. This update corrects that issue, ensuring users can now properly access and work with analytic items from the accounting interface. This fix was implemented by reverting a previous problematic commit.
Original PR description
Amls are not selectable from the modal on analytic items Steps: - Go to Accounting > Analytic Items - Select new - Open Journal Item selection field and click on 'Search More' - Select a line -> Nothing happen The bug has been introduced by 5a5f59471e827a369ee040d9bd4acb70e2b2348c that overrides `openRecord` to prevent the default form view to be opened when clicking on the line. This issue has been properly fixed with https://github.com/odoo/odoo/commit/295995896550f7ea389b7dc799631fa7213fd5cb therefore we can revert 5a5f59471e827a369ee040d9bd4acb70e2b2348c opw-5359355 Forward-Port-Of: odoo/enterprise#101210
This update fixes a bug where read-only accounting users couldn't access customer statements. The previous system restricted access based on user type, even for read-only users. This change ensures all accounting users, regardless of their access level, can view customer statements.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#102683
This update fixes an issue where the wrong manager was sometimes assigned to approval requests. Previously, the system selected the first matching employee, potentially leading to approvals being handled by the incorrect person. This change ensures the correct manager is always identified, improving approval accuracy and efficiency.
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 bug that caused Facebook statistics refreshes to fail due to inconsistencies in how date and time information was handled across different Python versions. The fix ensures compatibility with older Python versions by standardizing the date format, preventing errors and improving the reliability of Facebook account statistics updates.
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 the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting. The change ensures that contract overlap dates are limited to the payslip period, preventing inflated durations and improving payroll accuracy. This resolves a potential reporting discrepancy.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103425 Forward-Port-Of: odoo/enterprise#100700