Monday, September 14, 2026
4 changes · 17.0
Resolved issues and error corrections
Installing the Ecuador inventory localization no longer fails when an optional inventory accounting component is not installed. The setup now skips account-specific configuration unless the needed accounting fields are available, allowing businesses to install the module independently.
Original PR description
Steps to reproduce the bug:
- On a database without stock_account installed:
- Install l10n_ec_stock alone (single-module install, no auto-install cascade)
Problem:
Installing l10n_ec_stock raised:
ValueError: Invalid field 'valuation_in_account_id' on model 'stock.location'
The post_init_hook calls _l10n_ec_setup_location_accounts(), which writes valuation_in_account_id and valuation_out_account_id on stock.location (addons/l10n_ec_stock/models/account_chart_template.py). These fields are defined by stock_account, not by stock or l10n_ec, which are the module's only dependencies. When stock_account happens not to be installed, the fields don't exist on the model and the write() fails.
Solution:
Guard _l10n_ec_setup_location_accounts() with a check that valuation_in_account_id exists on stock.location before writing to it, skipping the valuation account setup when stock_account isn't installed.
runbot-237915This update adjusts automated tests to handle small rounding differences correctly. It helps keep validation reliable for field service sales and Belgian payroll accounting without changing day-to-day user functionality.
Original PR description
See community PR opw-6227836
This fixes how recruitment creates a linked contact for an applicant by using the intended applicant-related values. It helps ensure applicant contact records are created accurately, reducing data errors during hiring workflows.
Original PR description
The values associated with the applicant's linked partner must be used during creation. Task-6479653
FedEx ZPLII shipping labels are now saved with a .zpl extension instead of .zplii, preventing browsers from incorrectly adding .txt to the filename. This makes downloaded labels easier to use directly with compatible label printers and avoids manual renaming.
Original PR description
TL;DR When downloading a `.zplii` shipping label from the chatter on a Delivery Order (using FedEx), the browser automatically adds .txt to the end of the filename, saving it as `.zplii.txt` Step to…
TL;DR
When downloading a `.zplii` shipping label from the chatter on a Delivery Order
(using FedEx), the browser automatically adds .txt to the end of the filename,
saving it as `.zplii.txt`
Step to reproduce:
- install `delivery_fedex_rest` with demo
- open shipping method menu -> Fedex Us -> label format = `zplii` -> save
- create a SO, click on 'Add Shipping",
- select fedex as shipping method -> get rate -> add -> confirm SO
- go to delivery and validate
- notice, in thread, a attachment with ZPLII extension appears
- download (.txt is appended to file)
Issue:
- `fedex_rest_send_shipping` post message with documents with extension as
`fedex_rest_label_file_type` i.e. `ZPLII`
https://github.com/odoo/enterprise/blob/735490d7ba9bdc6d0df7a0bd07c0d4e36d1ed2d4/delivery_fedex_rest/models/delivery_fedex.py#L193-L195
- when the attachment is created for this document , it's mimetype is computed
to be `text/plain` from [guess_mimetype](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/tools/mimetypes.py#L192) method, as data is plain ASCII code
- moreover, when downloading, [_get_stream_from](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/addons/base/models/ir_binary.py#L89) tries to guess extension
using [get_extension](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/tools/mimetypes.py#L210) which return `None` as len('zplii') > 4, [see](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/tools/mimetypes.py#L221)
- finally, as we got `None`, and mimetype is `text/plain`, `.txt` is appended [here](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/addons/base/models/ir_binary.py#L149)
Fix:
- we use `zpl` as extension for file instead of `zplii` as there is not
difference between them from printing perspective
- as length of 'zpl' is <=4 , `get_extension` will considered it as valid
opw-6410968