Odoo Changelog — 2025-07-29

Tuesday, July 29, 2025

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] hr_recruitment: fix applicant interview meeting count

PR #220970

Core17.0hr_recruitment

Applicant interview counts now include meetings scheduled by candidates through the appointment app. This ensures recruiters see the correct meeting status on applicant records and can track interview progress reliably.

Original PR description

In this bug, the number of interview meeting of applicant is not shown correctly. The meetings which are scheduled by applicant in appointment app, are not take into account.

To reproduce:
1- Create a db with appointment and recruitment installed.
2- Create a new job position, with email template to let applicant schedule a meeting.
3- Move forward the applicant to interviewing stage, and use the link provided to the applicant to set an appointment.
4- Open applicant. As you see, the smart button is showing: `No Meeting`

This bug, is result of not setting `applicant_id` in the `calender.event` when the event is set by the applicant. When db user schedules the event, the context has a default value `default_applicant_id`, but this is missing for the case when applicant sets the interview themsevles resulting `applicant_id` to be empty.

opw-4784349

#recruitment#appointments#interviews

[FIX] web: restrict filter operators for binary fields

PR #213608

Core17.0web

The custom filter builder now only offers valid choices for image and file fields. This prevents users from saving filters that cause errors and keeps searches on records with attachments working reliably.

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

#filters#binary fields#attachments#error prevention

[FIX] l10n_fr_invoice_addr: prevent error when try to remove field

PR #218974

Core17.0l10n_fr_invoice_addr

French invoicing now handles cases where the Delivery Address field has been removed from the invoice view. This prevents an error from interrupting users who customize invoice forms with 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

[FIX] l10n_din5008_stock: remove vat from address

PR #218757

Core17.0l10n_din5008_stock

Dropship delivery slips using the DIN 5008 layout no longer show the vendor's VAT under the customer's address. This avoids confusing or misleading information on customer-facing delivery documents.

Original PR description

When printing the delivery slip of a dropship operation using the DIN 5008 layout, the customer's address is correctly displayed, but the VAT of the vendor is shown beneath it. This is misleading.…

When printing the delivery slip of a dropship operation using the DIN 5008 layout, the customer's address is correctly displayed, but the VAT of the vendor is shown beneath it.  This is misleading. Actually we do not need vat at all.

**Step to reproduce:**
- Install `l10n_din5008_stock` and `sale_management`
- Go to setting 
    -> configure document layout -> set `DIN 5008` as layout 
    -> enable `dropshipping`
- Create a product, enable Purchase, and select Dropship route.
- Assign Azure Interior as the vendor in purchase tab.
- Create a SO with that product and Deco Addict as customer, confirm it
- Click on purchase smart button, confirm it,  click on dropship smart button
- print delivery slip Observation: Below the customer's address, the vendor's VAT is printed.

**Issue:**
- issue lies in this condition 
- `not (o.picking_type_id.code == 'outgoing' and main_address.id != o.partner_id.commercial_partner_id.id)`
- as `o.picking_type_id.code` is `dropship`
- here, condition evaluates to true, which incorrectly assumes the customer and vendor is same, and prints partner i.e vendor's VAT

**Fix:**
- no need to display vat,so we remove it

<img width="1519" height="244" alt="image" src="https://github.com/user-attachments/assets/d8630fa5-c568-4208-a97e-7e4ceb371109" />


**Before**

<img width="803" height="366" alt="image" src="https://github.com/user-attachments/assets/e2148bb0-7413-4efe-b312-ba7a577e0b62" />

**After**

<img width="615" height="244" alt="image" src="https://github.com/user-attachments/assets/526cfae3-4d8b-4755-b59c-54dfce79526c" />


opw-4929680


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] mrp_workorder: prevent error when changing start date in time tracking

PR #68014

Enterprise17.0mrp_workorder

Fixes a crash that could occur when users cleared and then re-entered a start date in work order time tracking. This keeps manufacturing time tracking usable and prevents users from being blocked by an error during routine production 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

[FIX] l10n_ch_hr_payroll_elm_transmission: prevent translation export…

PR #91219

Enterprise17.0l10n_ch_hr_payroll_elm_transmission

This fix prevents translation export checks from failing when the Swiss payroll ELM transmission module is installed on supported Python versions. It improves release and testing reliability without changing payroll features or user workflows.

Original PR description

… failure

Steps to reproduce
==================

- Use python 3.10 or 3.11
- Run the test `test_export_translatable_resources` with l10n_ch_hr_payroll_elm_transmission installed

Unexpected logs found: ['ERROR:odoo.tools.translate:Failed to extract terms from /data/build/enterprise/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_transmission_mixin.py Traceback (most recent call last):
  File "/data/build/odoo/odoo/tools/translate.py", line 1293, in _babel_extract_terms
    for extracted in extract.extract(extract_method, src_file, keywords=extract_keywords, options=options):
  File "/venv/main/lib/python3.10/site-packages/babel/messages/extract.py", line 325, in extract
    for lineno, funcname, messages, comments in results:
  File "/venv/main/lib/python3.10/site-packages/babel/messages/extract.py", line 487, in extract_python
    value = eval(code, {'__builtins__': {}}, {})
  File "<string>", line 2, in <module>
NameError: name 'month' is not defined']"

Cause of the issue
==================

Babel cannot extract translatable strings when f-strings are used inside `_()` in Python 3.10, resulting in a `NameError` during evaluation.

Solution
========

Move the f-string outside the _() call

runbot-163675

In this bug, the number of interview meeting of applicant is not shown correctly. The meetings which are scheduled by applicant in appointment app, are not take into account. To reproduce: 1- Create a db with appointment and recruitment installed. 2- Create a new job position, with email template to let applicant schedule a meeting. 3- Move forward the applicant to interviewing stage, and use the link provided to the applicant to set an appointment. 4- Open applicant. As you see, the smart button is showing: `No Meeting` This bug, is result of not setting `applicant_id` in the `calender.event` when the event is set by the applicant. When db user schedules the event, the context has a default value `default_applicant_id`, but this is missing for the case when applicant sets the interview themsevles resulting `applicant_id` to be empty. opw-4784349

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

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

When printing the delivery slip of a dropship operation using the DIN 5008 layout, the customer's address is correctly displayed, but the VAT of the vendor is shown beneath it. This is misleading. Actually we do not need vat at all. **Step to reproduce:** - Install `l10n_din5008_stock` and `sale_management` - Go to setting -> configure document layout -> set `DIN 5008` as layout -> enable `dropshipping` - Create a product, enable Purchase, and select Dropship route. - Assign Azure Interior as the vendor in purchase tab. - Create a SO with that product and Deco Addict as customer, confirm it - Click on purchase smart button, confirm it, click on dropship smart button - print delivery slip Observation: Below the customer's address, the vendor's VAT is printed. **Issue:** - issue lies in this condition - `not (o.picking_type_id.code == 'outgoing' and main_address.id != o.partner_id.commercial_partner_id.id)` - as `o.picking_type_id.code` is `dropship` - here, condition evaluates to true, which incorrectly assumes the customer and vendor is same, and prints partner i.e vendor's VAT **Fix:** - no need to display vat,so we remove it <img width="1519" height="244" alt="image" src="https://github.com/user-attachments/assets/d8630fa5-c568-4208-a97e-7e4ceb371109" /> **Before** <img width="803" height="366" alt="image" src="https://github.com/user-attachments/assets/e2148bb0-7413-4efe-b312-ba7a577e0b62" /> **After** <img width="615" height="244" alt="image" src="https://github.com/user-attachments/assets/526cfae3-4d8b-4755-b59c-54dfce79526c" /> opw-4929680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

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

… failure Steps to reproduce ================== - Use python 3.10 or 3.11 - Run the test `test_export_translatable_resources` with l10n_ch_hr_payroll_elm_transmission installed Unexpected logs found: ['ERROR:odoo.tools.translate:Failed to extract terms from /data/build/enterprise/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_transmission_mixin.py Traceback (most recent call last): File "/data/build/odoo/odoo/tools/translate.py", line 1293, in _babel_extract_terms for extracted in extract.extract(extract_method, src_file, keywords=extract_keywords, options=options): File "/venv/main/lib/python3.10/site-packages/babel/messages/extract.py", line 325, in extract for lineno, funcname, messages, comments in results: File "/venv/main/lib/python3.10/site-packages/babel/messages/extract.py", line 487, in extract_python value = eval(code, {'__builtins__': {}}, {}) File "<string>", line 2, in <module> NameError: name 'month' is not defined']" Cause of the issue ================== Babel cannot extract translatable strings when f-strings are used inside `_()` in Python 3.10, resulting in a `NameError` during evaluation. Solution ======== Move the f-string outside the _() call runbot-163675