Tuesday, September 15, 2026
14 changes · 19.0
Resolved issues and error corrections
Some accounting report actions were missing names, which could make them appear unclear or incomplete to users. This fix adds the missing labels so users can better identify and launch the right reporting actions.
Original PR description
opw-6471896
This fixes an issue in Discuss where quickly clicking delete more than once on the same attachment could trigger an error, especially on slow connections. The system now tracks attachments already being deleted, preventing duplicate requests and making attachment handling smoother for users.
Original PR description
**Steps to reproduce:** - Open Discuss app - Open any conversation - Setup the browser with throttled connection (e.g. Slow 4G) - Select multiple files to attach but don't send the message - While…
**Steps to reproduce:**
- Open Discuss app
- Open any conversation
- Setup the browser with throttled connection (e.g. Slow 4G)
- Select multiple files to attach but don't send the message
- While some are loading, double click the delete button of one of the loaded attachment preview
- Traceback will appear: `404 Not Found`
**Issue:**
On click the delete button triggers a deletion request on `/mail/attachment/delete`.
Repeatedly clicking the delete button before the first request was completed (and the `AttachmentList` get updated) but after the attachment was deleted, will cause a `404 Not Found` due to the `raise NotFound()` which was added by [1] in `mail_attachment_delete`.
```py
attachment = request.env["ir.attachment"].browse(int(attachment_id)).exists()
if not attachment or not attachment._has_attachments_ownership([access_token]):
request.env.user._bus_send("ir.attachment/delete", {"id": attachment_id})
raise NotFound()
```
**Fix:**
Prevent concurrent deletion requests for the same attachment by keeping track of attachments currently being deleted.
[1] https://github.com/odoo/odoo/commit/50f45dd436b97027cb1461410efeee7057dad4e8#
opw-6499125Users can now click at the end of text inside an editor button without the cursor jumping outside the button. This makes editing button labels in the HTML editor more predictable and reduces small formatting frustrations.
Original PR description
Problem: When trying to place the caret at the end of a button's content with the mouse, the caret always moves outside of the button instead of staying inside it. Cause: This happens because of the previous commit https://github.com/odoo-dev/odoo/commit/c8e93dbc806b5ea511cce695afbc9e81e30a1ca9 (which aimed to fix placing the caret after a link when at the end of a paragraph in the editable), which was not fixing the issue properly. Solution: Check if the click happens at the end of a link and the caret will move inside the link then manually place the selection after the link. Steps to reproduce: - Add a button with one character. - Try to put selection after that character. - Selection always jumps after the button. opw-6499237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284197
This update prevents an automated stock workflow test from failing when the Turkish Nilvera e-Dispatch module is installed. It adjusts the test to recognize the customized stock list view, improving reliability for localized Turkish deployments without changing business functionality.
Original PR description
### Steps to reproduce: - Install `l10n_tr_nilvera_edispatch` (e.g. the `tr` country build) - Run `test_basic_stock_flow_with_minimal_access_rights` > The tour times out on step 6/31, "check that at…
### Steps to reproduce: - Install `l10n_tr_nilvera_edispatch` (e.g. the `tr` country build) - Run `test_basic_stock_flow_with_minimal_access_rights` > The tour times out on step 6/31, "check that at least one picking is present in the view". ### Cause of the issue: The step triggers on `.o_stock_list_view_view`, a class the web client derives from the `js_class` of `stock.vpicktree`: https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/stock/views/stock_picking_views.xml#L66-L70 https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/web/static/src/views/utils.js#L45-L68 `l10n_tr_nilvera_edispatch` overwrites that attribute to plug in its e-Receipt upload button, so the root carries `o_l10n_tr_edispatch_tree_view` instead and the trigger never matches: https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/l10n_tr_nilvera_edispatch/views/stock_picking_views.xml#L4-L13 Only the class name changes: `L10nTrNilveraEdispatchListView` spreads `StockListView`, so the rendered list is identical. runbot-947260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds a test to ensure batch invoicing handles each subscription order using its own date range. It helps prevent invoices from accidentally including timesheet entries from the wrong billing period when multiple orders are invoiced together.
Original PR description
A test case to guarantee that batch invoicing multiple orders respects their individual time frames. This test is made to assert the fix in this [PR](https://github.com/odoo/odoo/pull/284781) opw-6507110 Forward-Port-Of: odoo/enterprise#129404
Fixes an issue where Save and Discard buttons could remain visible after a user retyped an equivalent value and discarded changes. This ensures forms correctly show that there is nothing left to save, reducing confusion during data entry.
Original PR description
**Description of the issue/feature this PR addresses:** Fixes #287978 In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only trigger the `FIELD_IS_DIRTY` bus event with…
**Description of the issue/feature this PR addresses:** Fixes #287978 In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only trigger the `FIELD_IS_DIRTY` bus event with `false` when the newly typed value actually differs from the value already stored on the record. When the typed text parses to the *same* value as what is already on the record (e.g. retyping `6,250` after the field already holds `6,25`), the code takes the `else` branch, which only resets the displayed text and never notifies the bus that the field is no longer dirty. `form_status_indicator.js` keeps whatever `fieldIsDirty` state it last received from that bus event, and shows the Save/Discard buttons whenever `root.dirty || fieldIsDirty`. Since nothing ever fires `FIELD_IS_DIRTY(false)` in that `else` branch, `fieldIsDirty` stays stuck at `true`. `Discard` correctly resets `root.dirty`, but has no way to reset `fieldIsDirty`, so the Save/Discard buttons keep showing even though the record is clean. **Current behavior before PR:** 1. Edit a field to a new value, click away (value committed, indicator shows Save/Discard as expected). 2. Edit the same field again, this time typing different text that parses to the *same* value (e.g. `1.20` when the field already holds `1.2`), click away. 3. Click **Discard**. The record is reverted, but the Save/Discard buttons remain visible. They stay stuck until the page is reloaded. **Desired behavior after PR is merged:** Retyping different text that parses to the same value clears the field's dirty state like any other case where the field ends up unchanged, so Discard (or any other action) correctly hides the Save/Discard buttons once there is nothing left to save.
Product tax selection now shows both goods and service taxes when users search for more options. This prevents unnecessary restrictions and gives businesses more flexibility to apply the correct sales or purchase taxes.
Original PR description
With this commit:- - We remove the tax-scope filter from the Search more taxes in the product page's tax fields (Sales taxes and Purchase taxes). - The purpose of doing so is that we should not restrict the user from using service taxes in goods and vice versa. task-6527424
This fixes an attendance issue where tiny timestamp differences could cause the same employee day to be treated as two separate overtime entries. Overtime recalculation is now more reliable when check-in and check-out times have different precision.
Original PR description
When an attendance check-out contains microseconds while its check-in does not, _get_day_start_and_day() preserves those microseconds while normalizing the time. This can produce two different grouping keys for the same employee day and make overtime recomputation attempt duplicate (employee_id, date) records. Normalize the day start completely before using it as a grouping key. A regression test covers an attendance whose check-in and check-out differ in microsecond precision. Fixes #280573 Forward-Port-Of: odoo/odoo#281986
This fixes the Discuss emoji picker so holding Shift while choosing an emoji no longer closes the picker. It makes it easier for users to add multiple quick reactions without repeatedly reopening the menu.
OSS sales in Spain are now reported in the correct VAT declaration box, moving affected amounts from box 124 to box 123. This helps businesses file Spanish VAT reports with the expected values in the right field.
Original PR description
OSS sales were being mapped to mod_303_casilla_124_balance where it should be mapped to mod_303_casilla_123_balance. These amounts must be reported values in casilla 123. This commit updates es_assec, es_common, es_full and es_pymes tax templates from 124 to 123 and updates test_country_tag_from_spain. task-6360387 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284984
KPI reporting now correctly excludes archived tax returns, so hidden or inactive returns do not distort dashboard figures. The related test was also made more reliable when other company data exists in the database.
Original PR description
[FIX] account_reports: KPI provider: properly ignore inactive returns Returns can be archived (setting the 'active' field to False) from the UI, so that the user can hide them when not needed, without risking them being regenerated by the cron, and without havin to mark them as completed, which could give misleading information when browsing the history. The problem was here the KPI provider did not properly ignore such returns. ======================================== [FIX] account_reports: make KPI provider test with existing data in db The KPI provider query completely ignores multi-company. Because of that, the test wasn't properly sandboxed, and could fail if any non-test company of the database contained a return made from any untested return type, as it would add one element to the result of get_account_reports_kpi_summary. We now make sure to archive all existing returns, whatever their company, before running the test.
Odoo now correctly brings the payment reference from imported CII XML invoices into the generated vendor bill. This helps accounting teams keep payment details accurate and avoids manual re-entry after invoice import.
Original PR description
### Issue before this commit: When importing a CII XML invoice containing a PaymentReference, the value is not transferred to the generated vendor bill in Odoo. ### Steps to reproduce the issue: 1. Download Accounting 2. Try to import the invoice in the ticket 3. See that in the tab other info the payment reference is not imported ### Cause of the issue: During a previous refactoring (ffbdf29a816d0ff4136488d26b55b9707fc37fc6), the helper function responsible for extracting the payment reference during the import process was omitted. ### Reason to introduce the fix: Add the missing extraction logic to ensure the payment reference is correctly retrieved from the XML and assigned to the Odoo invoice. opw-6530627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287216
This fix ensures demo custom fields in Quality Control Worksheets are properly identified by the system. It prevents unnecessary warning messages during automated module checks, improving system reliability without changing user-facing functionality.
Original PR description
The runbot test that uninstalls web_tour module triggers the following warning: `Field x_quality_check_worksheet_template_2.x_product with unknown comodel_name 'product.product'` It could be due to the fact that `x_product` demo field is created without xmlid. runbot-233632 Forward-Port-Of: odoo/enterprise#129497
FedEx shipping labels generated in ZPLII format now download with a standard .zpl file extension instead of being saved as a text file. This prevents confusion for users and helps ensure labels can be opened or sent to printers as expected.
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
Forward-Port-Of: odoo/enterprise#126620