Wednesday, July 30, 2025
20 changes · saas-18.2
Enhancements to existing features
The IoT Box homepage warning now says the SSL certificate is invalid instead of incorrectly suggesting a missing subscription. This avoids confusion because a subscription is no longer required to obtain a valid certificate.
Original PR description
When the IoT Box doesn't have a valid ssl certificate, we used to display a warning telling that there is no valid subscription. As users don't need a subscription anymore to get a valid certificate, we now only tell that the certificate is invalid. Task: 4978644 Forward-Port-Of: odoo/odoo#221152
Resolved issues and error corrections
Users can now only choose filter options that work correctly for image and file fields. This prevents errors when saving custom filters and keeps searches reliable for records with attachments.
Original PR description
The system encountered an error when users attempted to apply invalid filters on `binary fields` (e.g., `image_1024`). The error occurs when operators like 'is in' with empty string values ('') are…
The system encountered an error when users attempted to apply invalid filters on `binary fields` (e.g., `image_1024`). The error occurs when operators like 'is in' with empty string values ('') are used, as binary fields are stored As attachments only support existence checks.
**Steps to produce:-**
1. Add a filter like `[('image_1024', 'in', [])]` in the custom filter where the image exists(eg, Products) and save.
2. Error triggered.
**Error:-**
`Binary field 'Image 1024' stored in attachment: ignore image_1024 in [''] .`
**Solution:-**
- The `web` client's filter operator selection logic has been updated to restrict options for `binary` field types. Now, for binary fields, only the `is set` (`!= False`) and `is not set` (`= False`) operators will be available in the custom filter builder.
**Sentry - 6236134077**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#220997
Forward-Port-Of: odoo/odoo#213608Miscellaneous changes
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a closing entry for the tax report 3) Open the miscellaneous Operations from Accounting Dashboard 4) Open the above-created entry by removing the default filter 5) Post the closing entry, a wizard opens. 6) Validate the values. 7) A traceback appears **Error:** ``` account.journal' objec
Original PR description
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a…
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a closing entry for the tax report 3) Open the miscellaneous Operations from Accounting Dashboard 4) Open the above-created entry by removing the default filter 5) Post the closing entry, a wizard opens. 6) Validate the values. 7) A traceback appears **Error:** ``` account.journal' object has no attribute '_get_report_options_from_tax_closing_entry' ``` **Cause:** When the user tries to post the closing entry from the accounting dashboard, its active_model is `account.journal`, and the active_id should be the current id of the miscellaneous journal. This leads to the above traceback, as the method `_get_report_options_from_tax_closing_entry` is not available in account.journal. **Solution:** To resolve this issue, we can browse the current move from the `ctx['l10n_it_moves_to_post']`, since the value of the `l10n_it_moves_to_post` is also self.ids. Which is the current active id for that closing entry. https://github.com/odoo/enterprise/blob/3d89d9fe6be8e789278dee9bc706e091ee5a0ec5/l10n_it_xml_export/models/account_move.py#L19 opw-4783958 Forward-Port-Of: odoo/enterprise#87527 Forward-Port-Of: odoo/enterprise#86791
This fixes an error that could interrupt users while creating time off allocations measured in hours. If the employee field is temporarily cleared, the form now avoids a crash and lets the user continue correcting the record.
Original PR description
A traceback occurs when a user removes the Employee field while creating a time off allocation record. **To reproduce the issue:** 1) Install the `Time Off` module. 2) Create a new time off…
A traceback occurs when a user removes the Employee field while creating a time off allocation record. **To reproduce the issue:** 1) Install the `Time Off` module. 2) Create a new time off allocation record. 3) Navigate to the `Related Time Off Type` record. 4) Change the `Take Time Off in` option to Hours. 5) Return to the allocation and remove the Employee field. **Error:** ``` ZeroDivisionError: float division by zero ``` **Cause:** - When the Employee field is cleared, the `_compute_number_of_days` method is triggered. - Since the allocation_unit is set to Hours, this method attempts to calculate `number_of_days` using `_get_hours_per_day`. https://github.com/odoo/odoo/blob/96d4bd7911ba122610fd42c009da0a8e565e50ec/addons/hr_holidays/models/hr_leave_allocation.py#L256-L262 - However, when `employee_id` is missing, `_get_hours_per_day` returns 0, resulting in a division by zero. https://github.com/odoo/odoo/blob/96d4bd7911ba122610fd42c009da0a8e565e50ec/addons/hr_holidays/models/hr_employee.py#L140-L143 **Solution:** Since the employee_id is a required field in allocation, Adding an extra check for employee_id will resolve this issue. opw-4937893 Forward-Port-Of: odoo/odoo#219403
Fixed an issue in the French invoicing setup where removing the Delivery Address field from an invoice form could crash the system. Users can now customize invoice views without triggering this error, improving reliability for French companies using Studio.
Original PR description
The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'. **Steps to Produce:-** - Install `l10n_fr` and `web_studio` with…
The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'. **Steps to Produce:-** - Install `l10n_fr` and `web_studio` with demo data. - Switch to `FR Company`. - Go to `Invoicing > Customers > Invoices`. - Open any invoice > Toggle studio > Click on `Delivery Address` > and then click on `REMOVE FROM VIEW`. - Observe the error. **Error:-** `IndexError: list index out of range` **Root Cause:-** - At [1], the `_get_view` method unconditionally expects the `partner_shipping_id` field to be present in the invoice form view. - It performs an `xpath` search for the field and immediately attempts to access the first element of the result list. **Solution:-** - Now, if the `partner_shipping_id` field exists in the view, then the logic proceeds as before. If it's not found, the code block is simply skipped. [1]: https://github.com/odoo/odoo/blob/044833804c9e10048ec10d7e982c98c4f33f4cf4/addons/l10n_fr_invoice_addr/models/account_move.py#L16 **sentry-6746543069** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218974
This fixes an employee presence display issue where a changed work location for the current day could still show as "unspecified" before saving. HR users now see the correct current work location when hovering over the presence icon, reducing confusion in daily employee availability tracking.
Original PR description
Step to reproduce:
------------------
* Go on Employees
* Click on one Employee
* Change a today worklocation "office" (don't save, you need to have the little cloud)
* Hover over hr presence icon
This title will be "unspecified" and not "office".
Reason:
--------
name_work_location_display is computed but doesn't depends of daily worklocation field (monday_worklocation, tuesday...)
Solution:
---------
Depends of these daily worklocation field
task-4948488
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#220359
Forward-Port-Of: odoo/odoo#219222The Peru localization data now spells Huancayo correctly by removing an unintended space in the city name. This helps ensure accurate city information in customer, company, and address records using Peruvian localization.
Original PR description
The Huancayo has an extra space in the name. Instead of Huancayo it is written Hua ncayo in the csv file. opw-4947526 Forward-Port-Of: odoo/odoo#219888
This fix removes extra spacing that caused some form inputs to appear misaligned when placed next to fields containing nested inputs. It improves the visual consistency of Odoo form screens without changing business workflows or functionality.
Original PR description
Inside form views when an input is displayed next to an other which contains nested `o_input`, the border is misaligned. This is due to a duplication of the `o_input` style in `form_controller.scss` which overrides the rule handling nested `o_input` in `fields.scss` resulting in 2x the necessary padding. [task-4974502](https://www.odoo.com/web#id=4974502&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220751
Calendar popovers now keep a solid background when showing additional events, including on non-working days. This prevents events behind the popover from showing through, making the calendar easier to read and use.
Original PR description
This commit resolves a visual issue with the FullCalendar "more" popover, where its background could appear partially transparent—causing events behind it to show through and creating a poor user experience. The problem was introduced with the update to FullCalendar v6.1.10, which applies cell-related classes (like o_calendar_disabled) to the popover. On non-working days, this class applies a semi-transparent grey background, affecting the popover's readability. The fix ensures that the popover background remains opaque in this specific case, restoring proper visual separation from underlying content. task-4916099 Forward-Port-Of: odoo/odoo#218877
Creating a parent task directly from an existing task now automatically assigns it to the same project. This prevents newly created parent tasks from being left unassigned and keeps project task organization consistent; the parent field is also hidden for private tasks where it should not be used.
Original PR description
Before this commit, when the user creates a parent task on the fly in the list view of tasks or even in the form view of task, the parent task creates does not have the project of the task by default. This commit adds the project of the task as default value for the new parent task when the user creates a parent task in the parent_id field. Steps to reproduce the issue ---------------------------- 0. Install project. 1. Go to Projects > All tasks. 2. Show the parent task field. 3. Edit the parent_id field in the list view of an existing to create a new parent task. 4. Go to form view of the parent task Expected Behavior ----------------- The parent task should have the same project than the task in which we create the parent task. Current Behavior ---------------- The parent task created has no project set by default. task-4781342 Forward-Port-Of: odoo/odoo#220530 Forward-Port-Of: odoo/odoo#209434
Fixed an issue where users could not update progress bar values in Firefox. This makes inline editing behave consistently across supported browsers and avoids failed updates for Firefox users.
Original PR description
Before this commit, the input of the progressbar field couldn't be updated on firefox. It works on the other browsers by chance. In the list renderer, we call `preventDefault` on enter keydown. The event is first catch by the list renderer. This call is enough to prevent "change" event to trigger but on chromium browsers it is actually triggered (but should not). The progressbar field catches it and saves the new value. On firefox, the "change" event is never triggered. The commit fixes the input by using the input field hook to make it behave correctly. task-4881210 Forward-Port-Of: odoo/odoo#218860 Forward-Port-Of: odoo/odoo#215770
This update corrects an automated website test so it no longer waits for an element to become hidden when it only moves off screen. This helps keep website quality checks reliable and reduces false test failures during releases.
Original PR description
## Version 18.0+ ## Issue The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never…
## Version 18.0+ ## Issue The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never actually becomes `hidden` after the scroll-triggered animation ends — it remains in the DOM and visible. ## Cause Commit 7e85f88214b6b57db87a6c1964286f0b7813f6ff attempted to fix a selector that was always true by adding `:hidden`, assuming the element would be hidden once the scroll animation completed. But since the element’s visibility is never changed via `display: none` or `visibility: hidden`, the `:hidden` condition never matches, blocking the tour. ## Fix Remove the `:hidden` pseudo-class from the trigger. Instead, wait for the `.o_animating` class to be removed (indicating the end of the animation), then: - Add a short delay to ensure animation processing is complete. - Check that the element is outside of the viewport (scrolled out). - Verify that `animation-delay` is approximately 0. runbot-227077 Forward-Port-Of: odoo/odoo#219979 Forward-Port-Of: odoo/odoo#215567
Starshipit delivery requests now include the second address line when it is provided. This helps ensure shipping labels and carrier instructions contain the complete customer address, reducing delivery issues caused by missing apartment, suite, or unit details.
Original PR description
Current behaviour: --- When using Starshipit, street2 is not included in the payload sent to the API. Expected behaviour: --- Street and Street2 should be both included if street2 is set, separated by a space. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method 3. Create an Australian partner 4. Make sure street2 is set 5. Make a new sale order 6. Set the Australian partner 7. Set a product and click on "Add shipping" 8. Set starshipit as the method to use 9. Confirm and validate the delivery 10. Only the first street is sent opw-4907475 Forward-Port-Of: odoo/enterprise#90775 Forward-Port-Of: odoo/enterprise#89725
Creating a new UK BACS direct debit mandate no longer triggers an error before the record is fully saved. This helps users complete mandate setup reliably and avoids disruption in direct debit workflows.
Original PR description
`mapped()` was returning id of record before being persisted in DB, therefore SQL query was failing. using `filtered()` instead for retrieving ids of records in DB. task-4630586
Sign requests created by users who were later deleted no longer fail when opened. This prevents an error screen and lets teams continue accessing affected signature documents normally.
Original PR description
## Issue: ## Before this commit, opening a sign request created by a deleted user would raise an Owl Error ## Cause: ## The `action.params` are used as a fallback in the signRequest setup But sometimes sometimes the `action.params`are undefined, causing access to `action.params.create_uid` to fail ## Fix: ## The document can be open with `create_uid` set to False So we just added a check for `action.params` to be set before accessing his properties If the create_uid isn't in the context or in the params, it will be set to False ## Steps to reproduce: - Create a user (to be deleted later) - Create a sign request with this user - Delete the user - Try to open the sign request - The error should be displayed opw-4786368 Forward-Port-Of: odoo/enterprise#88758
Fixes an error that could occur when printing a Follow-up Letter from a customer's action menu. The report now uses the available customer follow-up information when specific print options are missing, allowing users to generate the letter normally.
Original PR description
### Steps to reproduce: - Settings > Technical > Reporting > Reports - Search for "Print Follow-up Letter" - Click on "Add to the Print menu" - Create an overdue invoice for a partner - On the partner page, click the gear to show the actions - Then click "Print Follow-up Letter" - Traceback ### Cause: This [line](https://github.com/odoo/enterprise/blob/82375d181cd138b497e695e747b63c009c0538fc/account_followup/models/res_partner.py#L291) tries to read `options['followup_line']` but with this flow `followup_line` is not in the options. ### Solution: Use `get` and fallback on the followup line on the partner. opw-4864880 Forward-Port-Of: odoo/enterprise#88543
This fixes validation around the Philippine BIR 2307 Excel export so ZIP codes and payment descriptions are checked correctly. It helps ensure tax certificate exports reflect the right partner details and tax descriptions for compliance reporting.
Original PR description
The BIR 2307 XLS export was missing the `ZIP_code` and incorrectly showing the `nature` of payment from the invoice line instead of the tax description. In this commit: --- - updates the tests to include the `zip_code` column and fetch the correct `nature` from the tax description. - adjust name fields to reflect individual vs company partner logic. community-PR- odoo/odoo#214940 --- task-4880921 Forward-Port-Of: odoo/enterprise#91120
Shared Helpdesk ticket pages now show the logo and branding of the company linked to the ticket, even when opened by someone who is not logged in. This prevents customers from seeing the wrong company identity in multi-company setups.
Original PR description
**Steps to reproduce**: 1. Install `helpdesk` only 2. Create a second company and configure a distinct logo for both the default and new companies. 3. Create a Helpdesk ticket under the new company.…
**Steps to reproduce**: 1. Install `helpdesk` only 2. Create a second company and configure a distinct logo for both the default and new companies. 3. Create a Helpdesk ticket under the new company. 4. Use the 'Share Ticket' (gear icon) feature to generate a portal link. 5. Open the link in an incognito window or a different browser (where no user is logged in). 6. Observe the logo shown in the portal navigation bar. **Observed behavior**: The portal incorrectly displays the logo and branding of the default/main company, even when the Helpdesk ticket belongs to a different company. **Issue**: When no portal user is logged in, the `res_company` used in the portal rendering context defaults to the system’s primary company (`env.company`). The template expects `res_company` to be explicitly set to reflect correct branding. See: https://github.com/odoo/odoo/blob/880954ebfc1106411b7f7a7d60aee05dfae60893/odoo/addons/base/models/ir_qweb.py#L781 **Solution**: Explicitly pass `ticket_sudo.company_id` as `res_company` in the portal view context to ensure correct company branding is used. opw-4855281 Forward-Port-Of: odoo/enterprise#90600
Fixes an error that could occur when a user cleared and then reselected a start date while editing time tracking on a manufacturing work order. This helps manufacturing users complete time tracking updates without interruption or support intervention.
Original PR description
When the user removes the value of the start date and selects the value again in the start date, a traceback will appear Steps to reproduce the error: - Create one mo > Work orders > Add a line >…
When the user removes the value of the start date and
selects the value again in the start date,
a traceback will appear
Steps to reproduce the error:
- Create one mo > Work orders > Add a line > Click on Open work order button
- In Time Tracking > Add a line > Remove the start date >
Select the start date again > Apply
Traceback:
```
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1007, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 7028, in _apply_onchange_methods
res = method(self)
File "addons/mrp/models/mrp_workcenter.py", line 448, in _date_start_changed
self._loss_type_change()
File "addons/mrp/models/mrp_workcenter.py", line 473, in _loss_type_change
if self.workorder_id.duration > self.workorder_id.duration_expected:
File "odoo/fields.py", line 1208, in __get__
self.recompute(record)
File "odoo/fields.py", line 1423, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1396, in apply_except_missing
func(records)
File "odoo/fields.py", line 1445, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 5037, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 101, in determine
return needle(*args)
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder_hr_account/models/mrp_workorder.py", line 62, in _compute_duration
super()._compute_duration()
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 762, in _compute_duration
wo.duration = wo.get_duration()
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 838, in get_duration
duration += self._intervals_duration([(t.date_start, t.date_end or now, t) for t in times])
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 826, in _intervals_duration
for date_start, date_stop, timer in Intervals(intervals):
File "addons/resource/models/utils.py", line 124, in __init__
for value, flag, recs in sorted(_boundaries(intervals, 'start', 'stop')):
File "addons/resource/models/utils.py", line 51, in _boundaries
if start < stop:
```
https://github.com/odoo/enterprise/blob/1f626176d28762683dc32ddbb351d994be894a71/mrp_workorder/models/mrp_workorder.py#L787 Here when "date_start" is empty,
It leads to the above traceback.
sentry-5679416830
Forward-Port-Of: odoo/enterprise#68014The Starshipit shipping cost banner will no longer appear on deliveries using other delivery methods. This prevents confusing messages for warehouse and shipping users when Starshipit is not involved.
Original PR description
A Strashipit banner was appearing on all deliveries, un-depending on the Delivery Method. Steps to reproduce: * Install 'delivery_starshipit' * Create a delivery with another Delivery Method selected, and a Carrier Price of 0. * The Starshipit banner "The Shipping Cost is being fetched in the background" appears Fix: Filter out 'invisible' condition on non-Starshipit delivery methods opw-4940717 Forward-Port-Of: odoo/enterprise#90994