Monday, May 26, 2025
20 changes
5 changes
Resolved issues and error corrections
The Dutch SBR tax report now handles cases where no closing entry exists without crashing. This keeps report generation stable after changes to the tax return process.
Original PR description
After the introduction of the new tax return process, `None` may now be returned as a closing entry, instead of an empty `recordset`. The SBR report may traceback if no closing entry is found.
ESG Initiative pages now keep the correct web address instead of showing a generic tasks link. This prevents crashes when users copy the link to another browser or enter and leave Studio, making the ESG workflow more reliable.
Original PR description
Have esg_project installed Got to ESG => Act => Initiatives Check the url Before this commit, the url was /odoo/tasks. This posed a number of issues: - Copying this URL in another browser crashed because the context of this action was lost - Entering then leaving studio crashed too, for the same reason. After this commit, the path of the action is correct and reloading it in another browser works correctly. runbot-error-198568
The test process for importing French FEC accounting files now reads the full file every time, avoiding occasional failures with larger files. This improves build reliability without changing user-facing functionality.
Original PR description
The JS unit test of the FEC parser was having a flaky build error because for reading files, the test was using `.getReader().read()` which would read only one chunk from the stream, causing incomplete files to be processed for large files. This commit makes the unit test use `response.arrayBuffer()` instead to guarantee the processing of the complete files all the time. build_error-161014
A display issue in accounting reports was fixed so the submission date now appears as expected in the Kanban view. This helps users quickly see when returns were submitted without opening each record.
Original PR description
The submission date is never visible due to incorrect record access in Kanban view. used `record.date_submission.raw_value` Instead of incorrect direct usage.
Importing a Winbooks ZIP file with empty data files no longer causes an error. This prevents accounting users from being blocked when an export contains no partner records to import.
Original PR description
Currently, an error is produced when importing a **Winbooks** `.zip` file that contains empty `.dbf` data files. **Steps to reproduce:** - Install the `accountant`, `l10n_be` and…
Currently, an error is produced when importing a **Winbooks** `.zip` file that contains empty `.dbf` data files. **Steps to reproduce:** - Install the `accountant`, `l10n_be` and `account_winbooks_import` module. - Change the default company to **BE Company CoA**. - Navigate to accounting settings and Under **Accounting Import** click to **import** button. - Click **Import WBK** button and upload [this](https://drive.google.com/file/d/1wsLin2kOvlZvl0HcrzUafgRxPOVxPrcS/view?usp=sharing) file. **Error:** `AssertionError` Here, an error occurs because `partner_data_dict.values()` at [1] returns an `dict_values` object, which may be empty. This value is passed directly to `ResPartner.create(...),` but the ORM method requires a list or tuple, by an assertion added at [2]. [1] - https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/account_winbooks_import/wizard/import_wizard.py#L126 [2] - https://github.com/odoo/odoo/blob/6ef8565053352e4f679d26032e5485474fda62ce/odoo/orm/models.py#L4309 This commit resolves the issue when files are empty and no partner data is available for import. Sentry - 6611894804
15 changes
Resolved issues and error corrections
This fix automatically matches Point of Sale customer account charges with their related settlements. It prevents settled POS amounts from incorrectly appearing as available credit for other invoices, reducing customer billing confusion.
Original PR description
### Problem When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create…
### Problem
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.
This PR covers versions 18 & 18.1, as reconciliation logic differs in later versions.
### How to reproduce
* Open a PoS session.
* Create an order and pay using customer account.
* Settle this customer's account (inside PoS).
* Create a Sale Order and invoice it (or just an invoice).
* The amount settled can be used as outstanding amount and can be used to pay the created invoice.
enterprise PR: https://github.com/odoo/enterprise/pull/86174
18.2 PR: https://github.com/odoo/odoo/pull/210619
opw-4794793This update refreshes Odoo's spreadsheet component with several fixes that make spreadsheet reports and calculations more reliable. It improves monthly pivot sorting, localized text, chart stability, scrolling behavior, autocomplete suggestions, and Excel export compatibility.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/838c4f799 [REL] 18.0.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/838c4f799 [REL] 18.0.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9600da59c [FIX] pivot: `month` granularity sorting [Task: 4781810](https://www.odoo.com/odoo/2328/tasks/4781810) https://github.com/odoo/o-spreadsheet/commit/75db485fa [FIX] ComposerStore: placeholder should be localized [Task: 4817738](https://www.odoo.com/odoo/2328/tasks/4817738) https://github.com/odoo/o-spreadsheet/commit/e5ac913c2 [FIX] Spreadsheet: reset scroll inertia after some time [Task: 4813296](https://www.odoo.com/odoo/2328/tasks/4813296) https://github.com/odoo/o-spreadsheet/commit/3b725faa8 [FIX] auto_complete: showing all proposal on single match [Task: 4735015](https://www.odoo.com/odoo/2328/tasks/4735015) https://github.com/odoo/o-spreadsheet/commit/1540b923d [IMP] xlsx: prevent exporting the SPLIT function [Task: 4766568](https://www.odoo.com/odoo/2328/tasks/4766568) https://github.com/odoo/o-spreadsheet/commit/c70f57360 [IMP] xlsx: prevent exporting FILTER function [Task: 4766579](https://www.odoo.com/odoo/2328/tasks/4766579) https://github.com/odoo/o-spreadsheet/commit/aebb77cc2 [FIX] chart: charts changing size on update [Task: 4794364](https://www.odoo.com/odoo/2328/tasks/4794364) https://github.com/odoo/o-spreadsheet/commit/6f0b45310 [FIX] module logical: keep functional behavior on empty ref [Task: 4775222](https://www.odoo.com/odoo/2328/tasks/4775222) https://github.com/odoo/o-spreadsheet/commit/f06d512ba [FIX] module logical: vectorize only if valid expression [Task: 4775222](https://www.odoo.com/odoo/2328/tasks/4775222) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix updates the test setup for QR code payments in Point of Sale so it can create the needed payment methods without permission-related failures. It helps keep automated checks stable and prevents false test failures that could slow down development.
Original PR description
Creating POS payment methods requires being a POS admin, which the POS user is not, and the test user may not be. Bypass issue by creating payment methods in sudo. https://runbot.odoo.com/odoo/error/222989
This fix prevents the website editor’s snippet preview dialog from failing when automated tests select a snippet faster than the preview can finish loading. It improves test stability without changing normal user behavior.
Original PR description
The adaptations from [1] and [2] added some code to the snippet preview dialog, mainly to adapt text highlights in the snippets content (starting from `18.0`) and enable the snippets preview interactions (starting from `18.3`) [A]. In a runbot test context, the snippet selection happens too fast that the code from [A] (linked to the async behaviour of `insertSnippets`) can still process the snippets dialog `iframeDocument` (lost after the dialog being closed on snippet selection). The goal of this commit is to fix this behaviour by simply taking into consideration the fact that the preview content can be lost (since in a real use case, a user will select a snippet in a reasonable time). [1]: https://github.com/odoo/odoo/commit/1aaf483c5d3b8e8816cfbea7da96ac007a42d492 [2]: https://github.com/odoo/odoo/commit/e008c92fcad2b8cc160586ba6ab94bc077b9bf3d Remark: This commit will be adapted on `18.3` to fix the code from [2]. runbot-190596
Payments will now only automatically choose or update their journal when the payment is first created or when its company changes. This prevents existing payments from unexpectedly switching journals during normal edits, reducing accounting errors and manual corrections.
Original PR description
We only want to compute a journal id for a payment if: - it's a new payment (never saved). - the company changed. Backport of #199573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Time Off calendar now shows the correct “Cancel” label for approved leave requests in month, week, and day views. This removes confusion because the action cancels the leave rather than deleting it, matching the behavior already shown in the year view.
Original PR description
**Steps to reproduce this issue:** 1) Install Time Off 2) Create an approved leave record 3) Click on the approved leave record in month mode(calendar view) 4) The Delete button appears instead of the Cancel button **Issue:-** In the Time off dashboard, in the year view, if I click on a leave and open the popup, I can click on “Cancel” to cancel my leave But this “Cancel” button appears as “Delete” in the month, week and day views. However, it does cancel the leave, not delete it. **Solution:-** This button should be renamed “Cancel” to be consistent with the system. opw-4782277
Email signatures now avoid carrying over dark mode-only table colors when messages are prepared for sending. This prevents signatures from showing unintended dark backgrounds or colors after users switch back to light mode, while preserving important layout formatting.
Original PR description
Problem: When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering. This…
Problem: When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering. This causes unwanted dark mode styles (e.g., `background-color`, `border-color`, and `color`) to persist even after switching back to light mode, especially in email signatures. Solution: Skip stylesheets that only affect `color`, `background-color`, or `border-color` on `table` elements. This avoids incorrect rendering in light mode without removing essential formatting styles. Note: Skipping all styles caused layout issues, so the fix targets only problematic styles. Fixed in `web_editor`: https://github.com/odoo/odoo/commit/d076dbcc273be5c8f337de9263effa82c9d9c0c8 Steps to reproduce: 1. Switch to dark mode. 2. Add an email signature in user preferences. 3. Switch back to light mode. 4. Open the mail composer. → The signature table shows a dark background. 5. Send the email. → The table in the mail thread still has a dark background. opw-4713718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that could occur when users sorted the Assets list by one accounting field and then another. This keeps asset management views stable and avoids interruptions for accounting users.
Original PR description
Currently, an error occurs when sorting is applied again on a different related field after sorting another related field first. Steps to reproduce: - Install `accountant` module - Navigate `Accounting > Accounting > Assets (list view)` - Apply Sorting on column `Fixed Asset Account` - Try to sort the column `Depreciation Account` - Observe the error Error: `AssertionError` The issue occurs when attempting to add a JOIN on an SQL query without verifying whether it has already been included. - [1] This commit resolves the issue by adding a conditional check before adding a join in the query, ensuring that duplicate joins are not added. [1] - https://github.com/odoo/odoo/blob/b2e564f07f6883111da4581bccfb0f45c7588063/addons/account/models/account_account.py#L150-L152 Sentry-6039417751
This fix prevents an error when a Point of Sale session is opened on multiple devices and then removed from one of them. Staff using another device will no longer hit a confusing missing-session error during opening control, improving reliability at store opening.
Original PR description
Before this commit, if a POS session was open on two devices and the session was removed from one device, attempting to proceed with the opening control on the other device would result in a missing error. Steps to reproduce: 1. Open a POS session on device 1 and 2 (both at the opening control) 2. On device 1, remove the session by clicking on backend 3. On device 2, attempt to set the opening control After this commit, the system properly handles the case where the session has been removed, preventing the missing error and improving user experience. opw-4775255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website popups with longer content now open at the beginning instead of jumping to the bottom. This makes popup messages easier for visitors to read and prevents important introductory content from being skipped.
Original PR description
Scenario: add a popup on a website page with enough text above the button so the button is not visible on the page without scrolling. Display the popup. Result: the popup is opened scrolled at the bottom (depends on if we are logged in or not), this usually works in incognito. Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the first tabbable element in the modal, but if that element is not in the view, the browser automatically scrolls to it. So there is this side effect that happen if the first tabbable element is hidden by the scroll. Fix: after we focus to the element, we reset the scrollTop to 0 to ensure we stay at the top of the popup. opw-4647172 X-original-commit: 3e8b9cb540674b12f496eb234cbb53a92233e27a
Replenishment no longer unnecessarily deletes and recreates orderpoints that users have manually adjusted. This helps keep configured minimum and maximum quantities intact while reducing wasted system work when reopening replenishment.
Original PR description
**Current behavior:** Everytime the Replenishment action is called we delete and recreate lots of (default) orderpoints. Sometimes it's annoying because manual values may have been set on them and in…
**Current behavior:**
Everytime the Replenishment action is called we delete and
recreate lots of (default) orderpoints. Sometimes it's annoying
because manual values may have been set on them and in general
it is wasteful.
**Expected behavior:**
Don't delete an orderpoint if either it's product min/max qty
fields have non-default values, don't delete/create orderpoints
if not necessary.
**Steps to reproduce:**
1. Create a delivery for (storable) product
2. Open replenishment -> edit auto-gen orderpoint to have 5
min/max qty
3. Go to dashboard, re-open replenishment -> the edited record
was deleted and there is a new one with the default `0`
min/max qty
**Cause of the issue:**
`_search_qty_to_order` does not really respect a domain leaf
like:
`('qty_to_order', '<=', 0)`
because currently it satisfied by `qty_to_order_manual==0`,
irrespective of `qty_to_order_computed`.
**Fix:**
Make `_search_qty_to_order` stricter by taking the intersection
of searching `qty_to_order_manual` and `qty_to_order_computed`
instead of the union.
opw-4547116Users can remove the “Valid Until” date from a sign request without triggering an error. This allows documents to remain available for signing indefinitely when no expiration date is needed.
Original PR description
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.
Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.
> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`
opw-4795212Settling a customer's due balance in Point of Sale now automatically matches the related accounting entries. This prevents the same settled amount from appearing as available credit for other invoices, reducing confusion and keeping customer receivables accurate.
Original PR description
- This commit ensures that when settling due amounts in the Point of Sale (POS), the account move lines (aml) are automatically reconciled. This is particularly important for customer accounts, where…
- This commit ensures that when settling due amounts in the Point of Sale (POS), the account move lines (aml) are automatically reconciled. This is particularly important for customer accounts, where due amounts need to be accurately reflected in the financial records.
- This commit also adds a test to ensure that account move lines (aml) are properly reconciled when settling due amounts in the POS.
### Problem
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.
### How to reproduce
* Open a PoS session.
* Create an order and pay using customer account.
* Settle this customer's account (inside PoS).
* Create a Sale Order and invoice it (or just an invoice).
* The amount settled can be used as outstanding amount and can be used to pay the created invoice.
Community PR: https://github.com/odoo/odoo/pull/211166
opw-4794793
Co-authored-by: Majed Alhanash (malh) <malh@odoo.com>This fix ensures the Mexican e-invoicing website sale checkout test has the required contact details before running. It prevents test failures in environments without demo data, helping keep validation reliable without changing customer-facing behavior.
Original PR description
The test relies on the admin partner having full contact in order for the "Confirm Address" step to "just work". If the test is run without demo data, this is rather not the case and the test fails on the next step, as "Confirm Address" causes a form submission failure due to required fields not being filled. https://runbot.odoo.com/odoo/error/161633
Studio exports now preserve the right order when records depend on other records of the same type, preventing import failures caused by missing referenced items. Webhook automation export data also no longer includes private, regenerated URL information, reducing unnecessary exposure and avoiding misleading imported values.
Original PR description
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data is sorted to ensure import order is correct, but for inter-record dependencies on a same model many2one_reference fields are not taken into account. This PR fixes that. Also while analyzing this issue another small issue was spotted regarding base.automation.url field. See commits.