Daily updates from Odoo
Tuesday, June 23, 2026
116 changes
2 changes
Resolved issues and error corrections
This update enhances the Helpdesk system by adding tests to ensure automatic reminder emails are sent correctly before tickets close. It also corrects a calculation error in the reminder timer, preventing delays and ensuring timely notifications for support staff. This improves the overall efficiency of ticket resolution.
Original PR description
- add tests for the auto reminder email before auto-closing tickets - fix issue with the reminder timer calculation --- task-5438678 Forward-Port-Of: odoo/enterprise#120540
This update corrects a bug in the SaaS version of Odoo (19.3) where sales orders without products (note lines) would prevent the 'deliver' button from appearing. The change ensures that all sales order lines, regardless of product association, can be delivered correctly. This resolves an issue that arose after a previous update.
Original PR description
In saas-19.2, note lines on SO's are no longer have a calculated
"manual" qty_delivered_method value. In the previous code, these would
prevent the deliver button showing on SO's (when stock was not
installed). These would also cause issues with the deliver action.
On Runbot (no apps installed):
1. Install Sales
2. Create SO with a product
3. Confirm SO
4. See deliver button dissapear
This change will correct a previous change so that sale order lines without a product will remain with a manual delivered method
opw-6280551
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2704403 changes
Resolved issues and error corrections
This update resolves an issue where the timesheet icon disappeared from the toolbar when 'Attendances from Backend' was disabled. The fix ensures the icon remains accessible, allowing users to log hours directly from the toolbar regardless of the backend attendance settings. This improves usability for users who prefer to log timesheets manually.
Original PR description
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet…
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet systray` from the `registry` and merges it inside the attendance dropdown. When `attendance_from_systray` is off, the dropdown hides itself and takes the timesheet icon with it, leaving no way to log hours from the toolbar. Expected behavior: Timesheet icon should remain accessible when attendance from systray is disabled. Issue: `registry.remove()` at module load made the timesheet icon impossible to restore. Fix: Keep the timesheet systray registered. Patch TimesheetSystray to read `display_systray from lazy_session` on startup and show itself standalone when attendance from systray is off. The template no longer replaces nodes. Header and total_hours are toggled via `position="attributes"` (`t-if="!props.signInOut"`, a prop only passed by the attendance dropdown), and a self-contained dropdown-only footer with the Check out button is added after total_hours. Ref: odoo/enterprise#104347 task-6285068
This update prevents a frustrating access error that occurred when users opened the timesheet task suggestion dropdown. The fix filters task suggestions to only include tasks the user currently has permission to view, ensuring a smoother timesheet experience. This resolves an issue impacting user productivity.
Original PR description
Steps to reproduce: - 1. Log in as a user who can see their own timesheets and has already logged time on tasks that are now in projects they can no longer read (e.g. Marc Demo in the demo data). 2. Open the Timesheets timer in the systray and check in. 3. Click the task field to open the suggestions dropdown. Issue: - An access error is raised when the task dropdown is opened. Cause: - The timer's `project.task` `name_search` override suggests recently used tasks via `account.analytic.line.sudo()._get_recently_used_records()`. The sudo surfaces task ids the user can no longer read. `name_search` returns them, raising the access error. Fix: - Filter the aggregation result so only tasks the user can read are returned. task-6319815
This update corrects a technical issue where new version creations were inadvertently duplicating notes, which should be specific to each version. This change ensures that each version's note is accurately recorded, improving data consistency and reducing potential confusion. It's a small, internal fix that enhances the reliability of our versioning system.
Original PR description
When we create a new version, we don't want to copy the note which should be version specific task-6304034 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#271379 Forward-Port-Of: odoo/odoo#270110
1 change
Resolved issues and error corrections
This update fixes an issue where bank verification timestamps were incorrectly displayed to users in Poland. The change converts timestamps from the local Polish timezone to UTC, ensuring accurate time representation and preventing display errors for users in the UTC+2 timezone. This improves the reliability of the bank verification process.
Original PR description
The gov API returns a 'requestDateTime' in str format in PL timezone. This commit converts it back to UTC timezone for a better display in payment form. fields.Datetime assume the value is in UTC time and so when a field of this type is displayed, it's converted to the user timezone. This cause issue with the PL API call because the API will send us 9:25 PL TZ but if we store it directly, it will be interpreted by the ORM as 9:25 UTC and displayed to the user that's in UTC+2 as 11:25 task-6314380 Forward-Port-Of: odoo/odoo#270839
1 change
Resolved issues and error corrections
This update resolves an issue that caused the Odoo website builder to crash when switching between different form models using the 'More models' feature. The fix ensures both the current and newly selected models are retained in the system's memory, preventing errors and improving overall stability.
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878
3 changes
Resolved issues and error corrections
This update corrects inconsistencies between Odoo module manifests and actual file usage. The changes ensure that all dynamically loaded files are properly listed, and outdated files have been removed, resolving warnings flagged by the Odoo linter. This improves the stability and maintainability of the core Odoo Enterprise modules.
Original PR description
Since that they are already loaded from python scripts
This update corrects a technical issue preventing the 'Invoicing & Banks' user group from accessing the necessary data within the account reports module. The missing access control record was corrected, ensuring proper functionality for this user group. This resolves a potential restriction on reporting capabilities.
Original PR description
The `ir.model.access` giving read access to model `account.return` for group "Invoicing & Banks" hasn't been migrated properly.
This update fixes an issue where custom fields linked to employee or applicant records weren't automatically updating after a signature was completed. The fix ensures that these fields are correctly synchronized, allowing for accurate record-keeping. This improves the reliability of the signature process.
Original PR description
Version - saas-19.3 Steps to Reproduce: 1. Create a custom Sign field (e.g. "Passport No") with "Update Field" enabled, linked to Employee (For Applicant, same any custom field). 2. Employee flow:…
Version - saas-19.3 Steps to Reproduce: 1. Create a custom Sign field (e.g. "Passport No") with "Update Field" enabled, linked to Employee (For Applicant, same any custom field). 2. Employee flow: Employee app -> open an employee -> gear icon -> Signature Request -> send. Applicant flow: Recruitment app -> Applicants list view -> select an applicant -> Actions -> Signature Request -> send. 3. Complete the signature. 4. Check the linked record's "Passport No" field -> field is not updated. Issue: The field linked to the employee/applicant record is not updated after signing. Cause: Both the `hr.contract.sign.document.wizard` and `hr.recruitment.sign.document.wizard` create the `sign.request` in `validate_signature()` without setting `reference_doc`. `_get_auto_field_target_record()` relies on `reference_doc` to resolve the record to sync auto fields against. With `reference_doc` empty, it returns `None`, so `sign.request._sync_auto_field_value()` skips the item before it ever reaches the write step. Solution: Set `reference_doc` to the corresponding `hr.employee`/`hr.applicant` record when building the `sign.request` values in `validate_signature()`, so auto fields linked to those models can resolve their target record and sync back normally after signing. taskid-6308532 Forward-Port-Of: odoo/enterprise#121152
2 changes
Resolved issues and error corrections
This update resolves a stability issue in the point-of-sale tour. The tour previously failed due to asynchronous order processing, leading to duplicate requests. By adding a delay to ensure requests complete, the tour now runs reliably, preventing errors and improving the testing process.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#121237 Forward-Port-Of: odoo/enterprise#110909
This update resolves a problem where the Italian fiscal printer in the POS system would stop printing and return incomplete orders due to unsupported characters in product or payment method names. The fix replaces these characters with spaces, aligning with official EPSON documentation to ensure proper printing functionality.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089) Forward-Port-Of: odoo/enterprise#120169
3 changes
Enhancements to existing features
This update cleans up invoices by hiding technical e-reporting details that weren't relevant for standard users. Instead, e-reporting status and errors are now logged in the invoice chatter, providing easier troubleshooting. Additionally, address validation errors for B2C invoices are now ignored to streamline the e-reporting process.
Original PR description
E-reporting technical fields were displayed directly on invoices, adding noise for regular invoicing users. Hide the e-reporting status columns and technical block from the standard invoice views, while keeping them available for debugging. Log the relevant e-reporting flow, status and blocking errors in the invoice chatter instead, with a link to the related flow. Also avoid reporting address validation errors on B2C invoices, as they are not required for Flux 10 e-reporting. Task-6273226
Resolved issues and error corrections
This update resolves an issue where Shopee's buyer identifiers were exceeding the expected int32 format. To maintain stability, the system now uses a backup method – matching contacts based on a different identifier field – when Shopee IDs are too large. This ensures seamless contact creation and synchronization.
Original PR description
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. Since we are in stable and cannot change the column type, this commit falls back to the `ref` field of the `res.partner` model to store and match Shopee contacts whose identifier doesn't fit within an int32. opw-6325948 See also: - master: https://github.com/odoo/enterprise/pull/121507 - upgrade: https://github.com/odoo/upgrade/pull/10578
This update resolves an issue where the 'Time Spent' cell in the Timesheets app incorrectly displayed an orange color due to minor rounding errors when calculating hours. The fix ensures accurate color coding based on expected work hours, providing a more reliable visual representation of employee time tracking.
Original PR description
## Issue In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color…
## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.
## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
- Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__
## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157
We obtain the following values:
```js
> monday = section.cells[1]
> monday.value
8.333333333333336
> workingHours[monday.column.value]
8.333333333333332
> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```
This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172
## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.
opw-61931811 change
Resolved issues and error corrections
This update fixes an issue where short URLs generated in Email Marketing were incorrectly using a default website domain instead of the configured `web.base.url`. This change ensures that URLs generated for automated tasks like mass mailings consistently use the correct domain, regardless of the context. It resolves a discrepancy in URL generation that could lead to incorrect links being created.
Original PR description
The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24) override builds link.tracker short URLs…
The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24) override builds link.tracker short URLs from `website.get_current_website()` and the current company's website domain. It was introduced by https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a for a multi-company backend flow (users switching companies to post social marketing links), but it runs for every compute, including CRON contexts with no HTTP request such as the mass-mailing queue. Without a request, `get_current_website()` picks an arbitrary website (the first in the database) and `self.env.company` resolves to the user's main company, so the short URL uses that company's website domain instead of `web.base.url`. Fall back to `super()._compute_short_url_host()` (which uses `web.base.url`) when no website is resolvable from the request, session, or context. Backend flows with a real request still hit the company-aware branch. Steps to reproduce: 1. Install Email Marketing and Website. 2. Settings > Companies: create a second company B. Settings > Websites: ensure website A points to company A with domain A, and create website B for company B with domain B. 3. Settings > Technical > Parameters > System Parameters: set `web.base.url` to a third domain C, and add `web.base.url.freeze` = `True`. 4. On company A, Email Marketing: create a mailing with body `<a href="http://example.com">test</a>` and a recipient list, then click Send. 5. Settings > Technical > Automation > Scheduled Actions > "Mass Mailing: Process queue" > Run Manually. 6. Email Marketing > Configuration > Link Tracker: open the tracker generated for the mailing. => The Tracked URL uses domain A. => The Tracked URL uses domain C. Ticket [link](https://www.odoo.com/odoo/project.task/6038590) opw-6038590