Friday, May 30, 2025
13 changes · saas-18.3
Enhancements to existing features
Odoo can now learn from recent bank statement activity and automatically create reconciliation rules when users assign accounts. This reduces repeated manual work and helps matching adapt when accounting patterns change.
Original PR description
…t patterns When assigning an account to a bank statement line, the system will now automatically create a reconciliation rule based on recent patterns. If no existing rule is found for the selected account and journal, the system will check the last five bank statement lines using the same account. If there is sufficient consistency in their payment references (e.g. a common pattern), partner, or amount, a new system-generated rule will be created using a regex label match. System-generated rules are deleted if a user later chooses a different account for the same label, allowing the system to adapt over time. The new rule is created using `SUPERUSER_ID` to distinguish it from rules created by users. task-4783623
Resolved issues and error corrections
Corrected a display issue where AI-related dropdown items could appear on top of pop-up dialogs, such as custom filter windows. This makes the interface clearer and prevents menus from blocking important dialog content while keeping the AI chat window visible when needed.
Original PR description
Steps to reproduce: - Install any module with exposed views (say sale_management) and the ai module. - Open any list view (say the Quotations) and type something in the search bar. - Dropdown menu…
Steps to reproduce: - Install any module with exposed views (say sale_management) and the ai module. - Open any list view (say the Quotations) and type something in the search bar. - Dropdown menu items will appear and click "Custom Filter" button from the items. - [ISSUE] The items are shown over the custom filter dialog. The issue is caused by the custom rules introduced in the ai module. In this commit, we're removing all the custom rules that overrides the overlay items. We shouldn't be controlling the `z-index` of those items. To ensure that the AI ChatWindow is still above the dialog that opens it, we reduce the `z-index` of the dialog to `$zindex-sticky=1020` (from `zindex-modal=1055`) and change the `z-index` of the ChatWindows to `$zindex-sticky + 1`. This works because the `.o-mail-ChatWindow` elements lives in the same "stacking context" as the `.o-overlay-item` that contains the dialog. In the dom (and in terms of stacking context) it roughly looks like the following: - html (root stacking context) - .o-overlay-item:has(.o_dialog) (z-index=1020) (under .o-overlay-container) - .o-mail-ChatWindow (z-index=1021) (under .o-mail-ChatHub) - .o-mail-ChatHub-bubbles (z-index=1020) With the above `z-index` values, the stacking will be: - .o-overlay-item:has(.o_dialog) - .o-mail-ChatHub-bubbles - .o-mail-ChatWindow (top most) The bubbles are not visible when the chat window is open, and when the chatwindow is minimized, the bubbles is still visible because it's above the dialog.
Miscellaneous changes
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86678 Forward-Port-Of: odoo/enterprise#86499
Original PR description
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86678 Forward-Port-Of: odoo/enterprise#86499
Closing the AI agent chat window no longer triggers an error. This improves the user experience by preventing a disruptive message when users dismiss the chat.
Original PR description
**Current behavior before PR:** Closing the AI agent chat window would throw an error because the code attempted to access the associated chatwindow after it had been deleted. **After this commit:** The issue is resolved by ensuring the chatwindow is not accessed after deletion, preventing the error.
This update corrects an automated test for UrbanPiper point-of-sale order handling so it selects the intended order during validation. It prevents test confusion caused by similar-looking order and session numbers, helping maintain confidence in the order flow.
Original PR description
In this fix, I updated the parameters passed to the `selectOrder` and `orderHasText` functions. Instead of using 3-digit sequence numbers (e.g., "001", "002"), I switched to 4-digit formatting (e.g., "0001", "0002") to avoid conflicts with the `session_id`, which was causing the wrong `order-row` to be selected. runbot-163111
Web Studio now handles button action setup correctly when users work in non-English languages. This prevents an error that blocked adding a method to a button and keeps the experience consistent with English.
Original PR description
Error occurs when adding method for a button via web studio for non-english translations. **Steps to reproduce:** * Install `web_studio` and change language to any `non-english` language * via Settings>Translations>Languages (we will use french) * Go to Apps>Any App>DropDown>`Info sur le module`>Studio>`Ajouter un bouton` * Select button>`Que doit faire le bouton?`>`Appeler une methode` * Mode> `button_immediate_install` `ValueError: not enough values to unpack (expected 2, got 1)` **Solution:** * This error does not occur in English translation instead it raises a `ValidationError` so we apply its logic to translated version as well. * We do this by removing `_t` from value in JS this would prevent translation of function name as function names are in English. **Sentry-6608410350**
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R
Original PR description
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice…
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section. **Issue:** The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill. According to the documentation: https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 For purchase-type documents, this field should have the bill reference as value. It should identify the original reference coming from the vendor. If there is no bill reference, the field should be empty. opw-4737630 Forward-Port-Of: odoo/enterprise#85005
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#86426 Forward-Port-Of: odoo/enterprise#73908
Original PR description
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#86426 Forward-Port-Of: odoo/enterprise#73908
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
Original PR description
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
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(
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-4795212
Forward-Port-Of: odoo/enterprise#86532
Forward-Port-Of: odoo/enterprise#85891*: account_sepa_direct_debit, l10n_ec, l10n_nl_reports --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to
Original PR description
*: account_sepa_direct_debit, l10n_ec, l10n_nl_reports --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86513 Forward-Port-Of: odoo/enterprise#86397
When clicking on the `Request Signature` button after creating a new application a traceback would occur due to missing record data. Steps to reproduce: --- - Install `hr_recruitment_sign` module - Recruitment > Applications > All Applications - Create New and in action button `Request Signature` Traceback: --- ``ValueError: Invalid field 'mobile' on model 'res.partner'`` The `mobile` field was removed from `res.partner` (see related commit), but it was not removed from this modul
Original PR description
When clicking on the `Request Signature` button after creating a new application a traceback would occur due to missing record data. Steps to reproduce: --- - Install `hr_recruitment_sign` module - Recruitment > Applications > All Applications - Create New and in action button `Request Signature` Traceback: --- ``ValueError: Invalid field 'mobile' on model 'res.partner'`` The `mobile` field was removed from `res.partner` (see related commit), but it was not removed from this module. This commit cleans it up to avoid referencing a non-existent field. commit- https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be sentry-6588612861 Forward-Port-Of: odoo/enterprise#84784
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86624 Forward-Port-Of: odoo/enterprise#86275
Original PR description
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86624 Forward-Port-Of: odoo/enterprise#86275