Tuesday, July 29, 2025
20 changes · 18.0
Enhancements to existing features
This update adds a new customization point in the stock module for calculating dates during push rule processing. It does not change current behavior, but makes future customizations easier and safer for implementers.
Original PR description
This eases inheritance. No behavior is changes with this PR, it is just a new inheritance point. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
After a user starts fetching bank transactions from the accounting dashboard, the fetch button is hidden to prevent repeated clicks. This helps avoid duplicate provider requests and reduces the chance of synchronization errors.
Original PR description
The button `Fetch Transactions` shown on a bank in the accounting dashboard can possibly be clicked multiple times in a row by a user. This would cause several calls to the provider causing potential errors. This commit prevents the user from being able to fetch transactions multiple times by removing this button once clicked. task-4900188 Forward-Port-Of: odoo/enterprise#89127
Resolved issues and error corrections
Users can no longer choose filter options that cause errors when filtering image or file fields. The filter builder now only offers choices that are valid for these fields, reducing failed searches and improving reliability.
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 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#213608Features or functions removed from Odoo
An old internal test that was not part of the normal official test process has been removed because it had become broken. This cleanup reduces maintenance noise without affecting customer-facing Odoo functionality.
Original PR description
`test_parse_inline_template` has never been run "officially" since it's not in a module's test directory, which is where the built-in test harness looks things up. Miraculously it actually worked…
`test_parse_inline_template` has never been run "officially" since it's not in a module's test directory, which is where the built-in test harness looks things up. Miraculously it actually worked still if one managed to get it run (via some other test harness), however with #212315 it's now broken: - #212315 unconditionally looks up the `test_tags` during `__init__` - way back when test tags were added in b356b190338e3ee032b9e3a7f670f76468965006, a default value for test tags was only set on classes defined somewhere within the `odoo.addons` namespace, this was kept on all subsequent updates (even after the `module` was removed from the test tags and moved to a separate attribute) As a result, when running `test_parse_inline_template` the initialisation of each test now fails with an `AttributeError` right in the `__init__`. Can't be arsed to move the test to a place where it's run, and clearly nobody's cared in the last 4 years. Forward-Port-Of: odoo/odoo#220832 Forward-Port-Of: odoo/odoo#220768
Miscellaneous changes
The calendar "more" popover now keeps a solid background, preventing events behind it from showing through. This improves readability and keeps the calendar experience clear, especially on non-working days.
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
This fixes a small visual issue in form views where adjacent input fields could show misaligned borders because extra spacing was applied twice. The change improves the consistency and polish of forms without affecting 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
This fixes an error that could appear while creating a time off allocation if the employee field was temporarily cleared and the allocation was measured in hours. Users can now edit these allocation records without encountering a crash, improving reliability in the Time Off workflow.
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
This corrects a sales test so it uses the proper type of order data when creating invoices. It helps prevent failures in customized sales invoice flows, improving reliability for businesses using tailored Odoo setups.
Original PR description
At [1], `_create_invoices()` expects a recordset, not a dictionary. The test case currently passes because the `advance_payment_method` is set to `percentage`. However, if someone overrides `_create_invoices()` and uses a different `advance_payment_method` (e.g., 'delivered'), it will fail. Traceback: --- `AttributeError: 'dict' object has no attribute '_create_invoices'` [1]- https://github.com/odoo/odoo/blob/4cd24dc73d46b714cd5a764ed3f003e9507b0777/addons/sale/tests/test_accrued_sale_orders.py#L150-L152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users create a parent task directly from an existing task, the new parent task now automatically uses the same project. This prevents unassigned parent tasks and keeps project task structures consistent, while also hiding the parent task field for private tasks where it should not apply.
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#209434
This fixes an issue where users could not update progress bar values in Firefox, even though the same action appeared to work in other browsers. The progress bar input now saves changes consistently across supported browsers, reducing browser-specific user frustration.
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#215770
Printing a follow-up letter from the partner actions menu no longer fails when some report settings are missing. This helps accounting users generate overdue payment follow-up documents reliably from the partner page.
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
This fix prevents an error when users clear and then reselect a start date while editing time tracking on a manufacturing work order. It keeps the workflow usable and avoids an unexpected traceback during routine manufacturing updates.
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 no longer appears on deliveries that use 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
Shared Helpdesk ticket portal pages now show the logo and branding of the company linked to the ticket, even when the viewer is not logged in. This avoids confusion for customers in multi-company setups and ensures the right brand is presented on public ticket links.
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
Users can now open signature requests even if the employee or user who created them has since been deleted. This prevents an error page and keeps access to existing signing documents working as expected.
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
This fix ensures Australian Single Touch Payroll zeroing reports include the correct payslip dates. It helps keep payroll reporting accurate and avoids missing date information in compliance-related submissions.
Original PR description
steps to reproduce: 1. install l10n_au_hr_payroll_account 2. run the test `TestSingleTouchPayroll.test_stp_zeroing` the dates of the payslips are not set in the STP report build_error-228503
This update corrects an automated test for the Knowledge calendar command so it selects a visible calendar item and verifies the correct event time after drag and drop. It helps keep the Knowledge feature's calendar behavior reliably tested and reduces false build failures.
Original PR description
fixed css selector that is being used as the previous selector wasn't visible so item was found but not visible , and the updated start and stop timings according to the action of dragging and dropping from 9:00:00 to 11:00:00 the start time should be 11:00:00 and stop time should be 12:00:00 build_error-163015
The Philippine BIR 2307 Excel export checks were updated to match the latest required format. This helps ensure reports include ZIP codes and use the correct tax-based payment description, reducing filing inaccuracies.
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