Wednesday, March 25, 2026
18 changes · saas-18.3
Resolved issues and error corrections
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a threshold of €1,000 in total turnover (from invoices and credit notes), ensuring more reliable financial reporting.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111503 Forward-Port-Of: odoo/enterprise#101333
This update corrects a technical issue preventing users from accessing public website content (like blog posts) without logging in. The fix ensures that website access rules are correctly evaluated, resolving a 404 error. This improves the overall user experience for browsing public content on the website.
Original PR description
\* = test_website_modules ### Issue: When accessing a record from the website without logging in, a `404` error occurs if a public record rule filters records by website related domain, for example…
\* = test_website_modules
### Issue:
When accessing a record from the website without logging in, a `404`
error occurs if a public record rule filters records by website related
domain, for example `[('website_id', '=', website.id)]`.
### Steps to reproduce:
- Install the 'website_blog' module and create at least one website.
- Enable debug mode.
- Go to Settings > Technical > Database Structure > Models.
- Open the `blog.post` model.
- Go to the 'Record Rules' tab.
- For the record 'Blog Post: public: published only', change the domain
from `[('website_published', '=', True)]` to
`[('website_id', '=', website.id)]`.
- Go to Website > Configuration > Blogs.
- Open a blog (e.g., Travel).
- Select 'My Website' in its 'Website' field.
- Open 'My Website' without logging in.
- Click on the 'Blog' menu and the blog listing will appear correctly.
- Try opening a blog post and a `404` error occurs.
### Reason:
<pre>
┌─────────────────────────────────────────────────────────┐
│ Request Lifecycle │
├─────────────────────────────────────────────────────────┤
│ │
│ User Request (not logged in) │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 1. _pre_dispatch │ │
│ │ ↓ │ │
│ │ check_access_rule │ │
│ │ ↓ │ │
│ │ _eval_context (compute domain) │ │
│ │ ↓ │ │
│ │ get_request_website() │ │
│ │ ↓ │ │
│ │ request.website = None │ ← Issue │
│ │ ↓ │ │
│ │ Domain evaluation FAILS │ │
│ │ ↓ │ │
│ │ Access DENIED → 404 Error │ │
│ └──────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 2. _frontend_pre_dispatch │ │
│ │ (NEVER REACHED) │ │
│ │ ↓ │ │
│ │ request.website initialized ✓ │ ← Too Late │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
</pre>
Because `request.website` is initialized later in
`_frontend_pre_dispatch`, access rules evaluated earlier in
`_pre_dispatch` cannot rely on website context. As a result, record
rules depending on `website_id` are evaluated before `request.website`
is available, incorrectly denying access to public records.
### Fix:
Avoid totally relying on `get_request_website` during access rule
evaluation. Use the `request.is_frontend` attribute as a fallback, which
is set earlier, to detect frontend requests and ensure correct access
handling.
task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213143This update corrects a problem where printed POS receipts were displaying incorrect QR codes for subsequent orders. The issue stemmed from how the system cached QR code images, leading to the reuse of outdated information. This fix ensures that each order generates a unique QR code for accurate scanning and tracking.
Original PR description
**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt -…
**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt - click on "Print receipt" - repeat above steps for one more order **Observation:** - when we print the second order receipt, the QR still points to 1 order invoice **Issue:** - [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355 ) was trimming query strings when generating cache keys. URLs like: ` http://localhost:9000/report/barcode/?barcode_type=QR&value=... ` were reduced to: ` http://localhost:9000/report/barcode/` - As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders. **Solution:** Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly. opw-5455807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251139
This update resolves an issue where attachment updates for invoices were sometimes failing, leading to inconsistencies in the system. By updating the attachment within the same transaction as the move update, we ensure both changes are reliably committed, maintaining data integrity. This prevents data discrepancies and improves the reliability of invoice processing.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255440 Forward-Port-Of: odoo/odoo#255262
This update ensures Odoo uses the latest, pre-built wheel version of the cbor2 library, aligning it with Debian Bookworm and Ubuntu Jammy. This improves stability and performance by utilizing optimized pre-compiled code.
Original PR description
This commit sets the cbor2 library's version to match more closely the Debian Bookworm/Ubuntu Jammy packaged versions and to match the ones with a prebuild wheel. Note: while the 5.4.2 already matched the one from Jammy, it didn't provided a corresponding wheel, which the 5.4.2.post1 did fix (cf. https://github.com/agronholm/cbor2/releases/tag/5.4.2.post1). runbot-238903 Forward-Port-Of: odoo/odoo#254638
This update fixes a potential issue where users could inadvertently create incorrect group assignments to inherited views, leading to upgrade errors. The change adds a validation rule to prevent this, ensuring groups are defined directly within the view's XML configuration for stability and easier management.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the…
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the Views section. - Upgrade the module. **Issue:** - Odoo already prevents assigning groups directly on inherited view records in ir.ui.view. However, it is still possible to indirectly assign groups to inherited views through res.groups via the view_access relation. - This creates entries in ir_ui_view_group_rel and can trigger a ValidationError during module upgrades. As a result, users may unknowingly create invalid group-view relations, leading to errors and confusion. **Solution:** - Add a validation constraint on res.groups to prevent linking groups to inherited views via the view_access relation. - Raise a ValidationError when such an assignment is attempted, with the message: "Groups should instead be defined using the 'groups' attribute inside the view XML definition." This ensures that inherited views cannot be assigned to groups, avoiding invalid configurations and preventing errors during module upgrades. **opw-6015526** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255411 Forward-Port-Of: odoo/odoo#254849
A test failure in the restaurant POS module was caused by a timing issue during order synchronization. The test incorrectly added order lines while a synchronization process was still running, leading to data overwrites. This fix ensures the test runs correctly and highlights a potential data inconsistency.
Original PR description
The tour `test_preset_timing_restaurant` from the test suite was failing because the steps were executed too quickly. When creating a new order, the preset timing popup is opened, which triggers a synchronization of the order. At that moment, the order has no order lines, and the synchronization takes some time to complete. During this delay, the tour adds a new order line while the sync is still in progress. As a result, when the `sync_from_ui` response returns, the frontend data is updated with the synchronized order (which still has no order lines), overriding the order line that was just added. runbot error: 234567 --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/234567
A recent update to Odoo Enterprise prevented the deletion of newly created approval rules within the Studio module. This issue arose during an upgrade from version 18.0 to 19.0 and was caused by the way the system automatically updated these records. This fix ensures that these records are properly managed, preventing data loss.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update prevents data merge operations from failing silently when they take too long. Instead, a warning is displayed, suggesting users merge smaller groups of records. Upon successful completion, the model is automatically reloaded, ensuring data consistency and a smoother user experience.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update fixes an issue where project budget totals were incorrectly summing expense and revenue budgets. The fix adjusts how the system calculates totals, ensuring that expenses and revenue budgets are treated as separate values when displaying the overall project financial status. This improves the accuracy of project reporting.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent between the document tree view and version management tools due to a UTC timezone issue. This fix converts all datetime values to the user's local timezone for a more reliable and user-friendly experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update fixes an issue where receipts were displaying company information twice. The problem arose after a previous code change. This ensures that receipts consistently show the correct company details for customers.
Original PR description
Before this commit, the receipt was showing the company information twice. It happened after the commit https://github.com/odoo/odoo/commit/dca40d16481ba504d608cc65d82e7821e01c5932. opw-6053013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a technical issue where Mail Defender services were inadvertently cancelling appointments through automated URL clicks. To resolve this, the system has been updated to use a form instead of a direct link for cancellation/rescheduling, preventing unintended actions by bots. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#111159 Forward-Port-Of: odoo/enterprise#79831
This update resolves a performance issue during testing by proactively generating Odoo's bundled code. Previously, bundles were created on-the-fly during tests, causing delays. Now, the system identifies and pregenerates these bundles, resulting in faster and more reliable test execution.
Original PR description
tl;dr: look for lazy loaded bundles and add them to the bundles' list to pregenerate before running tests to avoid generation on the fly. Forward-Port-Of: odoo/odoo#248256
This update corrects a potential issue where an employee's work email could be unintentionally modified when linked to a user. This change ensures data integrity by preventing unauthorized email updates, particularly for employees connected to a user account. It maintains consistent employee data and avoids potential conflicts.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111821 Forward-Port-Of: odoo/enterprise#111243
This update corrects a technical issue within the website editor that prevented users from correctly loading custom snippets, specifically related to Google Maps. The fix ensures that custom snippets are not loaded when the base snippet is disabled, improving the user experience and preventing errors.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787 Forward-Port-Of: odoo/odoo#250236
This update resolves an issue preventing superuser administrators from deleting obsolete work entry types within the Odoo Enterprise payroll module. This change allows for better management of payroll configurations and ensures users have the necessary permissions to maintain accurate payroll settings. It improves operational efficiency and reduces potential data inconsistencies.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update corrects a problem with translations in the Chilean VAT reporting module (l10n_cl_edi_factoring). The change improved how translations were handled, specifically on Ubuntu Jammy and Debian Bookworm operating systems. This ensures accurate VAT reporting for our Chilean customers.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951 Forward-Port-Of: odoo/enterprise#111147