Thursday, February 5, 2026
13 changes · saas-18.3
Resolved issues and error corrections
This update prevents users from selecting payment method lines associated with archived journals when managing contacts. Previously, users could accidentally configure outdated payment methods. Now, archiving a journal automatically removes it from the selectable options, simplifying the process and preventing configuration issues when a journal is reactivated.
Original PR description
**Description of the issue/feature this PR addresses:** When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead…
**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.
**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.
**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.
https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a
OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245947
Forward-Port-Of: odoo/odoo#240369This update enhances the clarity of expense bills by automatically displaying notes entered in the payment reference field on the payment term line. Previously, these notes were missing, but this change ensures consistent and informative accounting entries, improving traceability.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244392 Forward-Port-Of: odoo/odoo#241353
This update fixes an issue where the toolbar remained visible on mobile devices when the side menu or a popover was open. Now, the toolbar automatically hides when these elements are displayed, providing a cleaner and more user-friendly mobile experience. This ensures a better workflow for users creating and editing notes on their mobile devices.
Original PR description
In mobile, when the side menu or a popover is opened, the toolbar remains displayed above the keyboard. This commit hides the mobile toolbar while such elements are opened. Steps to reproduce: - In mobile, go to a "To do" note - Put cursor inside text to display the toolbar - Open the hamburger menu => The toolbar remained displayed on top of the side menu - Open the gear menu => The toolbar remained displayed while the menu was opened task-5222582 Forward-Port-Of: odoo/odoo#241611
This update fixes an issue where vendor bill labels on payable lines were empty when a payment reference wasn't provided. Now, the payable line automatically displays the bill reference, and updating the payment reference correctly updates the label. This ensures better clarity and accuracy in vendor billing information.
Original PR description
Before PR: - On vendor bills and refunds, if the Payment Reference is empty, a placeholder saying `Use Bill Reference` is shown. But the Bill reference is still not written on the Payable line, making the label empty. - When Payment Reference is set, updating the Payment Reference does not update the payable line label. After PR: - The payable line label is now populated with the Bill Reference when the Payment Reference is empty. - Now, when Payment Reference is set, updating the Payment Reference updates the payable line label. - Modified the test cases which were failing due to an empty label. Related PR (Enterprise) : https://github.com/odoo/enterprise/pull/91535 Task : 4982864 Forward-Port-Of: odoo/odoo#247191 Forward-Port-Of: odoo/odoo#221491
This update allows users to reset Vendor Bills issued by ANAF (the Romanian tax authority) to a draft state, even if they are currently in an ‘EDI’ status. This change is necessary due to a recent update merging the ‘efactura’ module into the broader ‘l10n_ro_edi’ module, ensuring compliance with new regulations. It improves the flexibility of e-invoice management.
Original PR description
Adjusting the visibility check for "Reset to draft" button to allow Vendor Bills received from ANAF to be reset even when they have a EDI state. Will require to be shifted to `l10n_ro_edi` in 18.0+ as the efactura module is merged into it. task-5892651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247083 Forward-Port-Of: odoo/odoo#246697
This update fixes an issue where the HTML editor would incorrectly retain selections of tables and separators after the user clicked outside the editor. Now, when you click outside the editor, all selections – including text, tables, and separators – are properly deselected, providing a more consistent and user-friendly experience.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In Todo, Type some text. - Insert a table and a separator. - Select text along with table and separator. - Click outside the editor. The text is deselected but table and separator are still selected. **Desired behavior after PR is merged:** Custom selection such as table and separator is deselected along with browser selection when clicking outside the editor. task-5479981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where the Tax ID (VAT) was not correctly displayed in document layouts like invoices and previews. The issue stemmed from a missing piece of code in the document template. Now, the Tax ID value is accurately reflected in the generated documents, ensuring accurate reporting and compliance.
Original PR description
Steps to reproduce 1. Install `account`. 2. Go to Settings → Configure Document Layout. 3. Enter a value in the Tax ID field. 4. Generate a document (invoice / preview document). Issue Unlike other fields in the document layout, the `Tax ID` value is not updated and does not appear in the document preview. Cause The VAT (Tax ID) rendering logic was missing from the document layout template XML. Solution Add proper logic to display the Tax ID using the company VAT Before: <img width="1089" height="750" alt="image" src="https://github.com/user-attachments/assets/8d27808f-d605-447c-807a-d5f3450eef36" /> After: <img width="1080" height="722" alt="image" src="https://github.com/user-attachments/assets/0af04d77-a318-4e39-9a4b-0911f2446e60" /> opw-5373374 Forward-Port-Of: odoo/odoo#240234
This update resolves an issue where the POS ID wasn't being correctly transmitted to the blackbox, impacting data reporting for Swedish point-of-sale systems. A secondary change restricts blackbox device selection within the POS configuration, enhancing security and data accuracy. This ensures reliable blackbox integration for financial reporting.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update resolves a failing test case in our Indian GST reports. A recent community fix changed how payable lines are labeled, now using bill references. The test cases have been updated to reflect this new labeling format, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106468 Forward-Port-Of: odoo/enterprise#91535
This update fixes an issue where the activity menu in web_studio was displaying all records for custom models, regardless of whether the user had an activity assigned to them. Now, the menu only shows records with activities linked to the current user, improving performance and ensuring users only see relevant data. This change was driven by a bug fix (opw-5778806).
Original PR description
After commit odoo/odoo@5c5fbc10b7024c7227f03e37897d421bba64df82 , actions spawned by the activities menu have their domain managed by dynamic <filter /> rather than a plain readonly domain. Before this commit, clicking on the activity menu to go to a custom model showed every record, not just ones with activities after this commit, only records with activities assigned to the current user are showed opw-5778806
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price products from the sync process, ensuring smoother integration with our UrbanPiper partner.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves an issue where customer display URLs weren't being properly transmitted to the IoT devices when records were updated. The change ensures that the correct URL is sent, improving the functionality of the IoT integration. This fix was triggered by a reported bug.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#106331
This update resolves a technical problem that was preventing accurate display names from being set for spreadsheet cell threads. The change ensures that only one display name is retrieved, preventing a system crash and improving spreadsheet functionality. This ensures consistent and correct data presentation.
Original PR description
**Before this change** We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets. **After this change** We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value. opw-5380947 Forward-Port-Of: odoo/enterprise#106230