Friday, August 29, 2025
19 changes · 18.0
Enhancements to existing features
This update adds shared automated checks for point-of-sale localization modules across multiple countries. It helps reduce the risk of country-specific compliance or checkout issues by making these localized POS flows easier to test consistently.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788
This update adds shared automated checks for point of sale localization modules across several countries. It helps ensure local fiscal and reporting requirements keep working consistently when point of sale features change.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788
Resolved issues and error corrections
Opening a Discuss channel now correctly clears its unread status even if that browser missed an earlier notification. This keeps unread indicators consistent across multiple browser sessions and reduces confusion for users managing conversations.
Original PR description
Before this commit, if you opened an unread channel that the server already considered “read,” the channel would remain marked as unread in your browser. This typically happens when one browser instance misses the bus notification that cleared the unread status. Steps to reproduce: 1. Open Discuss as the same user on two browsers (A and B) 2. Send a message to said user 3. Stop bus notifications on browser A 4. Read the message on browser B 5. Re-enable bus notification on browser A 6. Open the channel on browser A -> not being marked as read This happens because the method `_set_last_seen_message` skips sending the notification when the message seen is older than the current `seen_message_id` (previously set by the other browser). This commit fixes the issue by setting the `allow_order` parameter in the rpc call. task-4863058 Forward-Port-Of: odoo/odoo#218623
Code cleanup and technical improvements
This update prepares customer payment follow-up reports for easier customization. Businesses can now tailor which overdue and upcoming payment lines appear in communications without changing the core report flow.
Original PR description
The goal with these hooks is to allow customization of overdue and due lines that are going to be printed on the followup report to be communicated to the customer.
Documentation and clarification updates
This pull request records that GitHub user dimaurosalvatore has signed Odoo's Individual Contributor License Agreement. This is an administrative legal update that helps ensure future contributions from this contributor can be accepted under Odoo's contribution rules.
Original PR description
Description of the issue/feature this PR addresses: Sign the Odoo Individual Contributor License Agreement (CLA) for GitHub user dimaurosalvatore. Current behavior before PR: CLA not signed Desired behavior after PR is merged: CLA signed and recorded in doc/cla/individual/ under dimaurosalvatore.md. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale tax control button now appears only when relevant settings are enabled, including restaurant takeout or delivery scenarios. The tax selection popup also now uses a clear, accurate title, reducing cashier confusion during checkout.
Original PR description
Before this commit: =================== - When only point_of_sale is installed, the tax control button is visible only if `Flexible Tax` is enabled. But with pos_restaurant installed, the button is always visible, even if Flexible Tax is disabled. - Also, the tax selection dialog had an incorrect title: `Please register the voucher number`. After this commit: ================== - In point of sale, the tax control button will be visible if `Flexible Tax` is enabled, and in restaurant mode, the button will be visible if the `Flexible Tax` or `Takeout/Delivery` is enabled. - The tax selection dialog title has been updated to: `Choose the tax you want to apply`. Task: 4937977
The Saudi localization now shows the “THIS IS NOT A LEGAL DOCUMENT” warning only on customer invoices, credit notes, and debit notes when the required QR code is missing. Vendor bills, vendor adjustments, purchase receipts, and sales receipts no longer display this misleading warning, reducing confusion for accounting users.
Original PR description
Before this commit: - The message "THIS IS NOT A LEGAL DOCUMENT" was also displayed on Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. - The warning should only appear on Customer Invoices, Credit Notes, and Debit Notes when the QR code is missing After this commit: - The warning message is no longer displayed on all Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. Task-5044870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents required true/false values in Turkish Nilvera e-Dispatch documents from being translated. This helps ensure Nilvera receives the exact values it expects, reducing the risk of rejected or incorrect electronic dispatch submissions.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222669
This fixes an error that could occur when removing a bank account from a company contact. The change prevents empty duplicate-check results from being treated as real contacts, making contact bank account management more reliable.
Original PR description
To reproduce: ============= - go to the contact form of any company contact - add a new bank account "e.g. with account number 'DE'" (there should now only be one account) - save the contact form -…
To reproduce: ============= - go to the contact form of any company contact - add a new bank account "e.g. with account number 'DE'" (there should now only be one account) - save the contact form - remove the bank account via bin icon Problem: ========= ARRAY_AGG returns [NULL] when no duplicates found in query: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/account/models/res_partner_bank.py#L73 This causes browse([None]) to create res_partner(None,) recordset: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/account/models/res_partner_bank.py#L88 Which fails when accessing id_ field which will be None: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/web/models/models.py#L1173 Solution: ========= Add FILTER clause to ARRAY_AGG to exclude NULL partner_id values, preventing creation of null records in duplicate_bank_partner_ids. opw-4988134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now requires an update path when users configure a server action to update a record. This prevents incomplete action setups that could otherwise lead to errors when the action runs.
Original PR description
[FIX] base: make update_path required for 'Update Record' server actions If a server action was previously created without an `update path`, the resulting error already fixes with this commit [1]. This commit ensures that the `update_path` field is marked as required when the action type is set to `Update Record`. [1]: https://github.com/odoo/odoo/pull/217723/commits/9d0144f97795d71474bf84bdfd7ed7025fd8a9a2
Users can now enter an ampersand character in filter or domain search values without triggering an error. This prevents crashes when applying custom filters and keeps search behavior consistent for everyday use.
Original PR description
Example of steps: - Open any domain selector with an archive checkbox (via custom filter for example) - Try to add char `&` in value input - focus out or try to apply the filter - Traceback ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillUpdateProps: "Cannot read properties of undefined (reading 'filter')" ``` The problem comes from the fact that we expect to have multiple nodes in our domain if we have an `&` as a value. However, there is a difference between using `&` in a text search for example (type `condition`), and using `&` as an AND between two nodes (type `connector`). The solution is to restrict the condition so that it not only checks that the value is equal to `&`, but also checks that the tree type is indeed a connector and not a condition. opw-5015281 Forward-Port-Of: odoo/odoo#224567
This fix restores the ability to create and edit client-type menu actions in Studio without hitting a missing default view error. It removes obsolete special handling that conflicted with a broader default view generation fix, improving reliability for users configuring menus.
Original PR description
Steps to reproduce ================== - Install studio,contacts - Go to contacts - Open studio - Click on "Edit menu" - Click on the pencil next to a menu item - Set the action type to ir.actions.client - Type a random string next to it, for example "test123" - Click on "Create and Edit" => No default view could be found Cause of the issue ================== The following commit removes the binary fields from the default view as it caused a traceback https://github.com/odoo/odoo/commit/70d51d2103118287b1ebafdae396c7b86e6b9257 A more general fix has been made in https://github.com/odoo/odoo/commit/e1edcb06ef2619835d07717f00cbf6f04f026366 Since the binary fields are already removed in the super call, the override doesn't find them. Solution ======== There is no need for the override anymore opw-5023188 Forward-Port-Of: odoo/odoo#224634
This fixes a Point of Sale issue where applying a gift card could create an extra gift card line with a zero amount. Sales orders are now clearer for cashiers and customers, reducing confusion during checkout.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358
Purchase orders now consistently display both the vendor’s product name and the company’s internal product name across all pages. This prevents confusion when reviewing multi-page purchase orders and keeps product identification consistent.
Original PR description
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the…
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the settings. If you can't disable it, you can disable the view `purchase.order.form.inherit.matrix` to trigger the bug. - Create a product - Go to the purchase sheet - Add a vendor - Add the field "Vendor Product Name" and "Vendor Product Code" and fill them - Create a purchase order - Add your product - Add your product a second time (on a second line) - Confirm the PO - Activate debug mode - Go to the view and add a limit to have only 1 POL per page - Return to your PO - Go to the second page #### Current behavior: - Only the vendor name is displayed #### Expected behavior: - The vendor name should appear at the top, while the db name should be displayed under as in the first page. #### Cause of the issue: On the first page, POLs data are fetch through a `web_read` on the PO, while on other pages data are fetch through `web_read` on the POLs of the page. While fetching POL data with a `web_read` the client ask for several informations including: `name` and `product_id.display_name`. If both return the same, the client show only one, else it shows the `display_name` on top and the `name` below. - `name` return the vendor name - `product_id` is fetch with the context `partner_id` which transform the `display_name` from the db_name to the Vendor name Therefore it fetches twice the vendor name and don't have the name from the db. #### Solution: - remove the `partner_id` from the context. #### Consequence: - When adding a product to the PO, the name of the product displayed in the dropdown list will be the name from the db instead of the name of the vendor. PO confirmed that consequence is OK as long as it's still possible to search for product using vendor code, which is still possible. opw-4737337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The signing dialog now consistently opens with the automatic signature option selected, whether or not the user already has a saved signature. This avoids confusion and creates a more predictable signing experience for users.
Original PR description
Ensure the signature dialog consistently defaults to the "auto" option, regardless of whether a user has a pre-set signature or not. task-5012307 Forward-Port-Of: odoo/enterprise#92276
This fix removes country-based restrictions that could prevent certain localization reporting modules from installing automatically. It helps ensure that when a new localization is added, its related reporting features are enabled as expected for existing company setups.
Original PR description
Specifiying countries in the manifest will only auto-install the module if at least one company is in one of the countries. This is not wanted as, if someone already has a company with it's reports module, and we add a new localization. We want that new localization to auto-install it's reports module.
The French VAT reporting flow now uses the correct account when creating reimbursement entries. This helps ensure reimbursement accounting is posted accurately, reducing the risk of manual corrections or reporting inconsistencies.
Original PR description
This commit will change the account used for the reimbursement move. task-4932427
This update adds an individual Contributor License Agreement for a contributor. It supports the project's legal compliance process and does not affect product functionality or users.
This pull request adds a signed Contributor License Agreement record for the contributor tux-lyk. It supports Odoo's legal contribution process and does not change any product functionality or user workflows.
Original PR description
Description of the issue/feature this PR addresses: CLA Signature Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr