Wednesday, July 30, 2025
24 changes · saas-18.3
Enhancements to existing features
The IoT Box homepage now shows a more accurate warning when its SSL certificate is invalid. The message no longer incorrectly suggests that a missing subscription is the cause, reducing confusion for users and support teams.
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
The point of sale now loads the barcode setup records it needs for product scanning rules to work correctly. This helps ensure barcode behavior is available consistently during point-of-sale sessions, reducing configuration gaps in sales workflows.
Original PR description
In this commit: ------------------- - Added records for `barcode.nomenclature` and associated `barcode.rule` entries required for the nomenclature. - Patched WebSession to apply the defined nomenclature. task- 4945645 Related PR: https://github.com/odoo/enterprise/pull/91117
Odoo now keeps database time aligned with simulated application time during specialized test runs. This makes time-based automated tests more realistic and reliable without affecting normal production use.
Original PR description
[IMP] sql_db: replace now to reflect the time offset When using the faketime lib to test Odoo, only the Odoo processes are affected, so it does not reproduce the reality. With this commit, when an environment variable `ODOO_FAKETIME_MODE` is set, the cursor `now` function is altered the same way faketime alters the Odoo processes. See https://github.com/wolfcw/libfaketime Forward-Port-Of: odoo/odoo#220865 Forward-Port-Of: odoo/odoo#219671
This update adds automated tests for enterprise point-of-sale custom behavior, helping ensure key sales and preparation display flows keep working as expected. It reduces the risk of future changes accidentally breaking these business-critical retail operations.
Original PR description
This commit adds hoot tests for the overriden methods of point_of_sale in the pos_enterprise module. taskId: 4945820
Resolved issues and error corrections
The Peru localization data now spells Huancayo correctly, removing an accidental space in the city name. This helps users select and display the correct city name in Peruvian address records and related documents.
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#220835 Forward-Port-Of: odoo/odoo#219888
Miscellaneous 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 issue where unsupported devices connected to an IoT box caused repeated device updates to be sent every few seconds. The change reduces unnecessary database requests and log noise without changing normal device behavior.
Original PR description
In the forward port of odoo/odoo#218109, a bug was introduced where if an unsupported device is connected, the device list is always detected as being changed, so the IoT box sends devices to the database every 3 seconds. This doesn't cause any problems other than spamming the logs and the DB with requests, but should be fixed regardless. After this commit, the unsupported devices are taken into account correctly when detecting device changes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a mail thread issue where access and thread existence information could be missing when a request contained an empty list. Users should see more consistent mail and discussion behavior when opening or interacting with records.
Original PR description
Even if the request is an empty array, access (and existence of thread) should be sent. How to reproduce: https://github.com/odoo/odoo/pull/220605 Forward-Port-Of: odoo/odoo#220924 Forward-Port-Of: odoo/odoo#220774
Users can now update progress bar values reliably in Firefox. This fixes an inconsistency where edits saved in some browsers but not in Firefox, improving data entry reliability in list views.
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 fix updates an automated website tour so it correctly detects when a scroll animation has finished. It helps keep website testing reliable and prevents false failures during quality checks.
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
The calendar now keeps the "more" event popover fully opaque, even on non-working days. This prevents events behind the popover from showing through, improving readability and the overall scheduling experience.
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
Users can now create project tasks with one, two, or three priority stars directly from the shortcut text. This fixes a limitation in quick task creation, making it faster to capture the intended priority without editing the task afterward.
Original PR description
Issue:
------------
Currently, when creating a task using the shortcut, it is not possible to set multiple priority levels.
Fix:
---------
With this commit, users will be able to set multiple priority levels (up to 3) when creating a task using the shortcut syntax.
Supported priority levels:
-----------------
- 1 star: task1 @admin #high !
- 2 stars: task1 @admin #high !!
- 3 stars: task1 @admin #high !!!
Steps to Reproduce:
--------------
- Install the Project module.
- Go to the Project app.
- In the Kanban view, create a task using the shortcut.
- Paste the following into the task name field:
`task1 @admin #high !!!`
task-3935867This fix prevents an error when a user clears the employee field while creating a time off allocation measured in hours. It keeps the allocation form stable and avoids an unexpected crash during normal data entry.
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
The custom filter builder now limits image and other binary fields to checks for whether a value exists or not. This prevents users from saving unsupported filters that could trigger errors when working with records such as products.
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#213608French-company invoice forms no longer crash when users remove the Delivery Address field through Studio. The change safely skips address-specific layout logic when that field is not present, helping users customize invoice screens without errors.
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 a visual alignment issue in form views where some input fields displayed extra padding and misaligned borders when placed next to nested input fields. The change improves consistency and polish in forms without affecting business logic or user workflows.
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
Fixes an employee presence display issue where changing today's work location could still show as unspecified before saving. The displayed location now refreshes when daily homeworking fields change, giving managers and employees more accurate presence information.
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#219222Companies in Greece and Ireland with valid VAT numbers will now correctly see the Intra-Community Valid checkbox for VIES verification. This fixes a country-code mismatch so eligible businesses are properly recognized for EU VAT validation.
Original PR description
Current behavior before PR: - Intra-Community Valid checkbox (for vies verification) was not showing for Greece and Ireland companies with valid VAT number. This was because Greece ISO is GR and Ireland ISO in IX, but their VAT start with EL and IE Desired behavior after PR is merged: - Checkbox is shown despite differences between ISO and beginning of VAT Link to task : - https://www.odoo.com/odoo/project/967/tasks/4575784 Forward-Port-Of: odoo/odoo#201630
The Philippine BIR 2307 spreadsheet export now aligns with required reporting details by accounting for ZIP codes and using the proper tax description for payment nature. This helps businesses produce more accurate withholding tax certificates and reduces the risk of reporting mistakes.
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#91202 Forward-Port-Of: odoo/enterprise#91120
This fix prevents an error in manufacturing work orders when a user clears and then reselects a start date in time tracking. Users can now adjust time tracking entries without encountering a blocking traceback.
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#91259
Forward-Port-Of: odoo/enterprise#68014Starshipit shipping requests now include the second address line when it is provided. This helps ensure complete delivery addresses are sent to the carrier, reducing the risk of shipping errors or missing address 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
Fixed an issue where a signing document created by a user who was later deleted could fail to open. This helps users continue accessing and processing affected signature requests without encountering an error screen.
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 partner's action menu. Users can now generate follow-up letters for overdue invoices through this flow without encountering a traceback.
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
The Starshipit shipping cost banner now appears only for deliveries using a Starshipit delivery method. This avoids confusing users working with other carriers when shipping costs are not set.
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