Monday, February 9, 2026
7 changes · saas-18.4
Resolved issues and error corrections
Odoo now converts invoice dates to Taiwan time before sending them to ECPay. This prevents ECPay searches from using the wrong date and failing to find invoices, reducing errors in Taiwan electronic invoicing workflows.
Original PR description
sending to ECPay The date store in Odoo is in utc format, we need to convert it to tw time when sending the date to ECPay. The APIs are using the date to search for the invoices, if the date is not correct, it cannot find the invoices and return error. task-5884616 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#246039
This fixes an error that could occur when a company kept a previously selected invoice sending option after the related feature was disabled or uninstalled. Users can continue sending invoices without hitting an unexpected failure, improving reliability around accounting settings changes.
Original PR description
Currently, an error occurs when a company-dependent selection field (e.g. invoice sending method) keeps a value after the related module is uninstalled. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs when a company-dependent selection field (e.g. invoice sending method) keeps a value after the related module is uninstalled. **Steps to Reproduce:** 1. Install the Accounting app. 2. Disable 'Snailmail' from settings. 3. Send any invoice, make sure wizard Print & Send has selected "by Post" option. 4. Click on the Send button. **Error:** `AssertionError` **Cause:** Fields defined with `company_dependent=True` are stored as property fields rather than regular values. In PostgreSQL, these fields are stored as **JSONB** values keyed by company id. When a selection value is removed (e.g. during module uninstallation), it attempts to compare the JSONB column directly with a string value, resulting in an invalid comparison and triggering the error. - [1] **Fix:** Update the SQL query to extract the value for the active company using JSON operators (->>), ensuring correct comparison with the expected selection value. [1] - https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/odoo/addons/base/models/ir_model.py#L1812-L1815 sentry-6970900918 Forward-Port-Of: odoo/odoo#241248
Odoo now avoids replacing a user's active login session when Firefox loads certain images that were redirected through external email security scanners. This prevents unexpected logouts while viewing chatter content, especially for users behind tools like Cisco Secure Email or Microsoft SafeLinks.
Original PR description
## Problem A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this…
## Problem
A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this flow:
- A user (Person A) opens an Odoo record. The chatter contains an image previously sent by a correspondent (Person B) whose email client or mail server rewrote the image URL to point to a security proxy.
- Firefox tries to load the image. The URL points to `cisco.com/...`. (for example)
- The proxy scans the link and redirects the browser back to the original Odoo URL: `odoo.com/web/image/...`.
- Firefox follows the strict (now deprecated) `rfc6265bis` rule: it looks at the whole redirect chain.
Since it sees a cross-site hop (cisco.com), it flags the final request as cross-site.
-> Because Odoo's session_id is `SameSite=Lax`, Firefox refuses to send
the cookie on this "false" redirect
- Odoo receives the request at `/web/image` without a session_id.
- Odoo creates a new, empty session to process the request.
- At the end of the request, because save_session is True by default, Odoo sends a `Set-Cookie: session_id=NEW_EMPTY_ID` header in the response.
- The browser receives this `Set-Cookie` header, and this time *applies a different policy*: it considers the header as same-origin, allowing it to overwrite the previously valid session cookie with this new one that corresponds to a fresh, unauthenticated session.
- The user is instantly logged out of their current Odoo tab.
## Context on Web Compatibility
This "redirect chain consideration" was a controversial part of the `RFC6265bis` draft.
Chrome and Safari never fully implemented it because telemetry showed it broke ~1% of the web. In March 2024, the HTTP Working Group (HTTPWG) officially decided to remove this requirement from the spec (reverting to a more permissive model) because it was deemed not web-compatible. Firefox, however, still enforces this strict behavior in many versions.
## How to we fix this
We set `routing={'save_session': False}` on the `/web/image controller`.
- This prevents Odoo from sending the `Set-Cookie` header if the session is dirty or new.
- Even if Firefox sends the request without a cookie, Odoo won't "reply" with a new session ID.
- The user's legitimate session cookie remains untouched in the browser.
## Sources
- HTTPWG Decision (March 2024): https://github.com/httpwg/http-extensions/issues/2104
- Reverting RFC6265bis: https://github.com/httpwg/http-extensions/pull/2750
opw-5184217
opw-4698750
opw-5166151
Forward-Port-Of: odoo/odoo#242582
Forward-Port-Of: odoo/odoo#242061This fixes a Safari-specific issue that could crash the editor when users collaborated on content changed in Chrome with undo actions. Users can now open and edit shared descriptions more reliably across browsers without hitting an error.
Original PR description
Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps: 1. In chrome, use an existing task with…
Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps: 1. In chrome, use an existing task with empty description or create a task in the project (first create the task title in the kanban view, then click edit), enter 4 lines of text 2. In one of the middle lines, delete one character --> undo --> add a new character 3. Save the task, open the task in Safari incognito, log in as demo (not admin), go to the task and click the description field 4. TraceBack: IndexSizeError: The index is not in the allowed range. After this commit: we use the range of the DOM selection to set the offsets of activeSelection. If the DOM selection is too wrong to be corrected, e.g. the selection's anchor node isn't the same with range's start container (or end container if direction is right to left), we do not set new activeSelection but just return the previous activeSelection task-5428788 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247484 Forward-Port-Of: odoo/odoo#246056
This update ensures that a failure message is now correctly displayed when a quality check is marked as failed. Previously, the system didn't show the intended failure notification. The fix corrects a technical issue related to how the system handles quality check states, ensuring users receive the expected feedback.
Original PR description
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t…
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown. **Steps to produce:** * Install `Quality` and `Manufacturing` with demo data * Go to MRP > Configuration > Operations > Manual Assembly * Create a pass/fail quality point with a failure message * Create and confirm an MO for `Table Top` * Go to Shop Floor > Activate work centers if inactive > Manual Assembly * Fail the assembly using the quick-action button Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing) **Observed Behavior:** * No failure message is displayed when the quality check is failed. **Root cause:** * This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears. **Solution:** * Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions. **Before:** <img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" /> **After:** <img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" /> [1]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 [2]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 [3]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 [4]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 [5]: https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161 opw-5403465 Forward-Port-Of: odoo/enterprise#102095
This update fixes an issue where Modelo 390 reports for past years were generating empty BOE files. The fix ensures the report correctly uses the specified year's data, resolving a discrepancy between the report and the actual tax information. This improves the accuracy of tax reporting for Spanish companies.
Original PR description
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374 Forward-Port-Of: odoo/enterprise#106676 Forward-Port-Of: odoo/enterprise#104928
A recent page refresh issue was preventing the restaurant appointment tour from working correctly. This update refactors the tour to maintain a consistent simulated time, ensuring appointments remain visible and the tour functions as expected after a reload. This improves the user experience for restaurant bookings.
Original PR description
The `RestaurantAppointmentTour` fails when page refreshes reset the mock clock to system time, causing the frontend to filter out mock appointments and the tour to timeout. Refactor the tour to use the new `withTimeFreeze` helper, ensuring the simulated date persists across reloads so appointments remain visible. runbot-232601 Related Community PR: odoo/odoo#247596