Daily updates from Odoo
Thursday, February 20, 2025
22 changes · 18.0
Resolved issues and error corrections
This fix prevents Odoo from failing when reading document data that is not encoded in UTF-8. It improves reliability for users accessing certain stored documents through document searches or integrations.
Original PR description
Since [this first commit], reading bytes not encoded in UTF-8 raises an error. The problematic code was moved from odoo/tools/date_utils.py to odoo/tools/json.py by [this other commit] after the bug was introduced. Steps to reproduce: - Install the documents app. - Call search_read on documents.document to read the raw field. => A UnicodeDecodeError is raised on some documents. The `ustr()` function is deprecated, so the fix is just about using the same logic. As it is impossible to guess the encoding of the bytes, we try to decode them with common encodings. [this first commit]: https://github.com/odoo/odoo/commit/6a68e93f924cc78ba15bc78d981b1bf115e57a0d [this other commit]: https://github.com/odoo/odoo/commit/5ef4c07ada1b47cd08a0fc7a2dd626f92d79b715 opw-4457853
The restaurant point-of-sale tests now use a more precise way to confirm the printed receipt header. This helps reduce false test failures and supports more reliable validation of receipt printing behavior.
Original PR description
Before this commit: ============== - Receipt header time check relied on a trigger. After this commit: ============ - A custom selector is used to verify the printed receipt header. runbot Error: 134719
This fixes demo data for the India localization so sample company and accounting setup work as expected. It helps users and testers see accurate example data when evaluating or setting up the India-specific Odoo configuration.
Original PR description
related - https://github.com/odoo/enterprise/pull/79690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Order change receipts in Point of Sale now correctly show the table name or number. This helps restaurant staff identify which table an order update belongs to, reducing confusion during service.
Original PR description
Before this commit, the table name (number) would not be shown on an order change reciept, as table_id?.name was always undefined. We now use the getName() funtion to retrieve the correct table name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory route rules now show the correct helper information when users change the supply method. This helps warehouse and inventory users choose the right routing behavior with clearer, context-specific guidance.
Original PR description
Problem: The complementary information were not displayed on the form view of a rule in a route. These informations are supposed to change depending on the Supply Method that has been selected, but since version 18, they always displayed the same information. The suffix, which is used to give information depending on the Supply Method, is not being used anymore and needs to be displayed again. Steps to reproduce: - Go to a route in Inventory and pick a rule - With Pull From set as Action, change the Supply Method - The helper on the right won't change but it should Fix: The suffix was added to the message that has to be displayed. opw-4511907
Portal users can now open invoices that include early payment discounts without seeing an access error. This keeps customer self-service invoice access working when discounted payment terms are used.
Original PR description
Steps to reproduce: ------------------- - Create an invoice and set the partner to a portal user. - Set the payment term to any payment term with an early discount option and confirm the invoice. - Log in as the portal user and view my invoices, you will get an error message that you aren't allowed to access "Partial Reconcile" records Cause: ----- Since #182656, access to the payment_terms was added to the _is_eligible_for_early_payment_discount method, to allow applying the early discount for in_payment invoices. Fix: --- Add sudo qualifier to the payment_terms access to allow this function to be called by portal users. opw-4535621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant point of sale users can now split and pay an order from one device even when the same table was updated from another device. The fix prevents the app from crashing when the same order line deletion is received more than once during device synchronization.
Original PR description
Steps to reproduce: =================== - Open the restaurant registry from 2 devices A and B - From device A, open a table, add a product, go back to floor plan - From device B, choose the same…
Steps to reproduce: =================== - Open the restaurant registry from 2 devices A and B - From device A, open a table, add a product, go back to floor plan - From device B, choose the same table, click split, choose the product added from device A, and click on pay. Reason: ======= We are trying to delete the same record 'pos.order.line' twice, i.e. we're calling `processDeletedRecords` twice with the same record id [1], so it succeds the first time, and it removes the record from the frontend cache, but when trying to process the deletion the second time, it fails since the record doesn't exist in the cache anymore [2], and hence, the `record` object is `undefined` in the second call to `delete_` with the same record id, causing the traceback [3]. The reason we're calling `processDeletedRecords` twice with the same record id is because `sync_from_ui` is issuing 2 sync events at the same time [4], since it's been passed 2 orders when splitting [5]. Fix: ==== Since it's an urgent bug, this fix just skips deleting the record if it doesn't exist, without "fixing" the root cause of syncing event being issued twice. [1]: https://github.com/odoo/odoo/blob/2d0ed96675541a88d9132bd01d33730f72c79d1d/addons/point_of_sale/static/src/app/store/devices_synchronisation.js#L116 [2]: https://github.com/odoo/odoo/blob/eca835a10d027b936890ff6ccc9e02660edfdfd5/addons/point_of_sale/static/src/app/models/related_models.js#L691 [3]: https://github.com/odoo/odoo/blob/eca835a10d027b936890ff6ccc9e02660edfdfd5/addons/point_of_sale/static/src/app/models/related_models.js#L664-L665 [4]: https://github.com/odoo/odoo/blob/eca835a10d027b936890ff6ccc9e02660edfdfd5/addons/point_of_sale/models/pos_order.py#L1043-L1046 [5]: https://github.com/odoo/odoo/blob/0faf168bbcbc66daeb58999a6222cd2c6d41134c/addons/pos_restaurant/static/src/app/split_bill_screen/split_bill_screen.js#L167 opw-4562134
This update fixes a Point of Sale test issue where customer searches could match the wrong contact due to overlapping phone numbers. It helps keep automated checks reliable so future Point of Sale changes can be validated with fewer false failures.
Original PR description
In this commit: ========== - Updated the test case for test_customer_all_fields_displayed. The test previously found multiple partners with the same phone number because the ID Company's phone was `+62 812-345-678`, while the test phone was `1234567890`. To resolve this, we have updated the test phone number to `9898989899`. Runbot Error- 116844, 116845
Point of Sale order validation now stops if payment processing fails or the order is not fully paid. This helps prevent orders from being incorrectly marked as paid, reducing the risk of financial discrepancies.
Original PR description
Before this commit, _process_saved_order caught errors from action_pos_order_paid and logged them. This meant that even when payment processing failed, the order state could be set to "paid", leading to financial discrepancies. Removing the try-catch block now stops order validation when payment is incomplete, ensuring orders are only marked as paid when fully confirmed. opw-4487123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now create a discussion thread from a file shared without accompanying text. This prevents an error in Discuss and keeps collaboration flows working smoothly when files are shared on their own.
Original PR description
This error occurs when a user sends a file without a message, and `Create Thread`. Step to Reproduce : - Install and open module `Discuss`. - Open Channel and send any file from `Attach files` without a message. - Hover over the sent file, click on `Expand`, and then click `Create Thread` AttributeError: 'str' object has no attribute 'striptags' This issue occurs when data is `str` instead of an HTML object. This commit fixes the error by ensuring .striptags() is only used when the data is in the correct format. sentry - 6304779383 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where adding a banner at the top of editable content could create an unwanted blank line and allow typing in the wrong place. The editor now uses an empty paragraph instead, keeping banner placement cleaner while preserving mouse selection behavior in Chromium-based browsers.
Original PR description
Before this commit and since [1], when inserting a banner at the top of the editable, a zero-width space (ZWS) was inserted before the banner to circuvent a Chromium bug that prevents fully selecting the banner with the mouse [2]. This led to the undesirable behavior of having a text node (with a ZWS) as the first child of the editable, creating a line above the banner and allowing for text insertion at the editable's root. This commit replaces the ZWS insertion with an empty paragraph, which can be later be moved around by the user. [1]: https://github.com/odoo/odoo/commit/a0fcba694a8a23a947ba28d188d6806272627447 [2]: https://issues.chromium.org/issues/40822311 task-4512959
The website tour test no longer depends on demo company information being present. This makes validation more reliable for databases created without demo data, reducing false build failures.
Original PR description
The tour requires the commercial_company_name to be 'yourcompany' which is not the case when demo data is not installed. https://runbot.odoo.com/odoo/runbot.build.error/116103
This fix removes an unintended extra border line from rating images. It improves the visual presentation of ratings without changing how the rating feature works.
Original PR description
Description of the issue/feature this PR addresses: The o_rating_label css is not properly configured, which caused an unintended extra border line to appear on the rating image This commit removes the border explicitly in the CSS file to correct the visual issue. opw-4482430 Related Commit: https://github.com/odoo/odoo/commit/9e8a709f80e3e4620bfa92decb383781b04d64c8#diff-b7f943d7f11d281f92f78810d7da31d5ab33d4e5952d66ce973d0bc24278ebcd Current behavior before PR:  Desired behavior after PR is merged: The border will be invisible and everything else still functional without any influence --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale search results now display long product names from the beginning instead of cutting off the first words. This makes products easier for cashiers to identify when using the search bar, reducing confusion during checkout.
Original PR description
… search results **Issue:** When performing a search in the PoS search bar, products with long names are displayed in a way that hides the beginning of the name, making it difficult to identify them.…
… search results **Issue:** When performing a search in the PoS search bar, products with long names are displayed in a way that hides the beginning of the name, making it difficult to identify them. **Steps to Reproduce:** 1. Install the Point of Sales app 2. Navigate to Point of Sales > Products 3. Create a product with a name longer than six lines 4. Open the register 5. Search for the product on the search bar 6. Observe that the product name is truncated at the beginning. Expected Behavior: The product name should always be displayed from the beginning, even when searched in the PoS search bar Actual Behavior: When searched, the product name is cut off at the beginning, making it difficult to read **Root Cause** The issue occurs because align-items: center !important; is applied to a higher-level class. While this alignment works well for buttons with short names, it causes unintended truncation for product cards with long names. **Fix** The align-items property is explicitly overridden in the product name’s \<div\> to ensure that only the product name is affected, preventing unwanted truncation. Opw-4561019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Chat windows now appear in front of document action buttons when they overlap. This prevents buttons from visually floating over conversations, making the interface clearer and easier to use.
Original PR description
When the chat windows overlap the document action buttons, the buttons are floating on top of the chatwindow. This happens because chat window was lower than document actions, which uses `$zindex-dropdown` (`z-index: 1000`). This commit fixes the issue by putting chat window above `$zindex-dropdown`. before/after:   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product fiscal details for Brazilian companies now remain in the expected Extra Info section instead of being mixed into the eCommerce Shop section. This keeps product forms clearer and helps users find tax-related information in the correct place.
Original PR description
**Issue** BR fiscal product fields are displayed inside Ecommerce Shop group instead of Extra Info group Steps to Reproduce: 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2.…
**Issue** BR fiscal product fields are displayed inside Ecommerce Shop group instead of Extra Info group Steps to Reproduce: 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Observe that the fiscal information fields appear under the Ecommerce Shop group instead of Extra Info. Expected Behavior: BR fiscal product fields should be displayed inside the Extra Info group. Actual Behavior: BR fiscal product fields are incorrectly placed in the Ecommerce Shop group. **Root Cause** The issue occurs because the code mistakenly modifies the Extra Info group, adds eCommerce-related fields inside it, and then renames it to Ecommerce Shop. This causes the Extra Info group to disappear, leading to fiscal information being displayed incorrectly. **Fix** Instead of modifying the existing Extra Info group, a new separate group is created specifically for eCommerce-related fields. This ensures that fiscal information remains inside the Extra Info group and that eCommerce fields are properly placed next to Ecommerce Media, maintaining UI consistency. opw-4533760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents helpdesk teams from using working calendars that cannot produce reliable SLA deadlines, such as flexible calendars or calendars without working hours. It avoids ticket creation errors and helps ensure SLA deadlines are only based on valid schedules.
Original PR description
Steps to reproduce: - Let's consider an helpdesk team HT - Let's consider a working calendar WC with flexible hours and no working hours - Set an SLA policy on HT and set WC as SLA schedule - Create a ticket in HT Bug: A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline Expected behavior: With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no deadline is computed (bad configuration) opw:4563223
This fixes sample payroll data for the Indian payroll module so demonstrations and testing use accurate setup information. It helps teams evaluate or showcase the payroll workflow without running into avoidable demo-data issues.
Original PR description
related - https://github.com/odoo/odoo/pull/198328
Intrastat reporting has been updated to include service transactions alongside goods where required. This helps businesses produce more complete compliance reports, especially for Belgian Intrastat declarations involving services.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/379ddbe4a0a479bd7547877175476230f92b4683 Task: 3926963 Upgrade: https://github.com/odoo/upgrade/pull/7201
This fixes several usability issues in the Documents list view. Users can now edit records without keyboard shortcuts interrupting their work, avoid seeing duplicate Folder information, and update Website and Folder fields when allowed.
Original PR description
This commit fix the following issues: - When editing a record in list view, it wasn't possible to use the space key nor the enter key. The first one was (un)selecting the current line while the second one entered the folder or preview mode when validating the changes. - Folder was present twice in the list view. - Website and Folder are now editable. Task-4558286
Clicking the activity to send a tax report now opens the tax closing move for the relevant date instead of defaulting to the current date. This helps accounting users review and send the correct tax report without confusion or manual date correction.
Original PR description
Before this commit, when we clicked on the activity send tax report. It would result by opening the report at the current date instead of the date of the move. After this commit, the expected behaviour was to open the move of the tax closing. task-4583606
This change lets account chart updates avoid creating extra accounts, taxes, or fiscal positions when they are not wanted. It helps keep localization updates, especially for the Netherlands, more predictable and reduces unintended accounting setup changes.
Original PR description
add force_create in _load function