Monday, December 29, 2025
14 changes · saas-18.4
Resolved issues and error corrections
This update resolves an error that occurred when users removed the end date from a planning slot. The fix ensures the system handles the absence of an end date gracefully, preventing a technical error from disrupting the planning process. This improves overall stability and usability.
Original PR description
Currently an error occurs when user tries to remove end date on slot. Steps to replicate: - Install `planning`. - Create a new planning slot and click on a slot template at the top. - Remove the end…
Currently an error occurs when user tries to remove end date on slot.
Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.
Error:
```
File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
if slot._different_than_template():
File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].
Solution:
- Returned from the function call when `end_datetime` is false.
[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426
[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438
No ID
Forward-Port-Of: odoo/enterprise#102762This update resolves an issue where UrbanPiper orders were incorrectly showing a payment difference after completion. The fix ensures that the final payment amount accurately reflects the total order cost, improving the reliability of UrbanPiper transactions within the Odoo Enterprise system. This change impacts the UrbanPiper integration.
Original PR description
In this commit, The amount difference should be 0.0 after the Urbanpiper order has been paid. task-5441252 Forward-Port-Of: odoo/enterprise#102894 Forward-Port-Of: odoo/enterprise#102872
This update fixes a pop-up error that occurred when users switched back to a previous order after using the Pine Labs payment method in Odoo. The fix ensures the system correctly retrieves payment status information, preventing disruptions in the order processing workflow. This improves the reliability of the POS system for Indian businesses using Pine Labs.
Original PR description
Steps: ---------- - Install pos_pine_labs and l10n_in module. - Create a payment method for the Pine Labs terminal in an indian company. - Configure the config with the Pine Labs payment method. - Open pos session process order till payment screen. - Go offline and try to add a Pine Labs payment method. - Go back online and create a second order using the plus (+) button in the navbar. - Switch back to the first order. Issue: ---------- - A pop-up error appears due to a missing `plutusTransactionReferenceID` key when switching back to the first order and trying to get Pinelabs' transaction status. Fix: ---------- - Ensure the payment status is fetched only when the `plutusTransactionReferenceID` key is available in the payment line. opw-5176160 Forward-Port-Of: odoo/odoo#233357
This update fixes issues with the preparation tickets used in self-order systems. It now includes essential details like table numbers and configuration names, and correctly displays order references and times. This ensures clearer and more accurate information for staff processing self-orders.
Original PR description
Before this commit: =================== - Some details were missing from the preparation tickets, such as the table number and configuration name. - The order reference and time were not displayed in the correct positions. After this commit: ================== - Added the configuration name and table number to the receipt. - Corrected the placement of the order reference and time. Task: 5268966 | Before this PR | After this PR | |--------|--------| | <img width="511" height="431" alt="before" src="https://github.com/user-attachments/assets/ac5b2c45-5210-4a4e-86c7-953e2ab89eb1" /> |<img width="514" height="448" alt="after" src="https://github.com/user-attachments/assets/f1feb317-d5fe-469a-ab70-cf1dd793dce5" />| Forward-Port-Of: odoo/odoo#236847
This update ensures that gift cards purchased through the POS system are correctly linked to the customer who made the purchase. Previously, gift cards lacked a customer association, making it difficult to track sales. This fix resolves this issue, providing better reporting and traceability for gift card transactions.
Original PR description
When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card. In…
When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card. In [`pos_loyalty/models/pos_order.py`](https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/models/pos_order.py), the `coupon_data` passed to the `confirm_coupon_programs` method does not contain the `partner_id`. This happens because the *Gift Card* program is not considered "nominative", failing the following condition from `pos_loyalty/static/src/overrides/models/pos_store.js`: https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L795-L801 In fact, the conditions for nominative programs are defined in the `loyalty` module: https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/loyalty/models/loyalty_program.py#L196-L200 This fix uses the customer's id when there's no `partner_id` in the `coupon_data` coming from the Javascript side. If there's no customer selected when buying the gift card from the POS, `self.partner_id.id` evaluates to `False`, leading to the original behavior: a gift card with no partner. ### Steps to reproduce: 1. Install Point of Sale (`point_of_sale`) 2. In Settings > Point of Sale, toggle *Promotions, Coupons, Gift Card & Loyalty Program* 3. In the POS, open a register 4. On the product screen, select the *"Gift Card"* product and click *Payment* 5. On the payment screen, set the Customer to any customer, pay, and click *Validate* 6. In the POS backend, go to Products > Gift cards & eWallet, click the *Gift Cards* program, and click the *Gift Cards (1)* smart button 7. The gift card we just sold in the POS appears in the list, but there's no Partner assigned to it. opw-5261991 Forward-Port-Of: odoo/odoo#237807
This update ensures the Odoo spreadsheet library is running the latest version, addressing potential bugs and improving performance. It’s a routine maintenance task to keep our spreadsheet functionality stable and reliable. This change was made by a team of developers to ensure continued smooth operation.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6ddac006f1 [REL] 18.4.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6ddac006f1 [REL] 18.4.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f2ed0d183a [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580) https://github.com/odoo/o-spreadsheet/commit/e3832bd5c9 [FIX] array_formula_highlight: avoid false spill outline [Task: 5403906](https://www.odoo.com/odoo/2328/tasks/5403906) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue preventing regular users from digitizing expense receipts. Previously, users needed specific administrator permissions to bypass the receipt validation process. The change now allows digitization for draft expenses, streamlining the expense reporting workflow. This improves user efficiency and reduces manual intervention.
Original PR description
When a regular user tries to digitize the receipt attached to an expense, the `UserError(_("You don't have the rights to bypass the validation process of this expense."))` is raised. It seems that currently, the user needs to be in the Expenses Administrator group (`group_hr_expense_manager`) to digitize the receipt, which doesn't seem correct.
This PR solves the issue by skipping the check of the user's group if the expense is in draft state, as suggested by @JulienAlardot: https://github.com/odoo/enterprise/pull/101011#pullrequestreview-3558220264
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241348
Forward-Port-Of: odoo/odoo#240401This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, particularly those common in countries like Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct delivery address formatting and reducing potential errors.
Original PR description
Issue ----- When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed. Examples: Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13) 7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A) Fix ----- Update part of the regex pattern from `\d+[-\/]?\d*` to `\d+(?:[-\/]?\d+)*` in order to match multiple occurences of one of '-', '\' or '/' followed by some number. ----- Ticket: opw-5366863 Forward-Port-Of: odoo/enterprise#101594
This update streamlines the loading of product images within the Point of Sale (POS) system. Previously, images were unnecessarily loaded and then converted to boolean values, causing performance slowdowns. Now, images are only loaded when needed, resulting in faster POS operations and a smoother user experience.
Original PR description
Before this commit, when loading products in POS, images were loaded and then changed to boolean values. This was causing unnecessary data to be loaded from the database, impacting performance. This commit modifies the product loading methods to avoid loading images initially. Instead, by setting the 'bin_size' context key to True when loading products, images are not fetched from the database, and the size of binary fields is returned instead. opw-5392423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241239 Forward-Port-Of: odoo/odoo#240420
This update fixes an issue where adding the same product multiple times to a Point of Sale order would create duplicate orderlines. The change ensures that prices with varying decimal places are correctly merged, resulting in accurate order totals and a better customer experience. This resolves a rounding error that previously caused inconsistencies.
Original PR description
Before this commit, when a product had a price with more decimals than the currency, adding it multiple times to the order would create multiple orderlines instead of merging them. This was due to rounding issue when comparing the prices of the orderlines. opw-5341735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241096 Forward-Port-Of: odoo/odoo#238639
This update fixes a security vulnerability where portal users could modify their country information even when an invoice or sale order was associated with their account. Previously, this restriction was only enforced through the main website portal. Now, users with existing orders cannot change their country details via the profile settings, enhancing data integrity and security.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237781
A recent update to FullCalendar, a core component of Odoo, has resolved a compatibility issue with Chrome 143 and later. This fix ensures the 'knowledge_calendar_command_tour' tour functions correctly in Chrome, addressing a previous error related to event dispatching within shadow trees. This improves overall user experience and stability.
Original PR description
Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget…
Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget clearing logic during dispatch" [^1] introduced in Chrome 143, to actually match the spec [^2]. To quote the Chromium commit message: > According to the spec, only if the top node is in a shadow tree, both > the target and relatedTarget should be cleared. > However, if the top node is not in a shadow tree and not a document, > the target and relatedTarget are always cleared. Because the current > implementation only checks whether the top node is not a document. > So, this patch fixes the bug by checking whether the top node is in a > shadow tree. In practice, this means that events are now properly dispatched when the FullCalendar container's element is not connected to the document but still to the shadow tree. As a result, the OWL reference to this container can not exist anymore when the event handler is called but FullCalendar's API still has the right reference to this element. Note: Firefox and Safari already implemented the spec properly (aka. it was already broken for them...) [^1]: https://chromium.googlesource.com/chromium/src/+/63178146cd776eae2b466983f0835e86c314d051%5E%21/ [^2]: https://dom.spec.whatwg.org/#concept-event-dispatch Forward-Port-Of: odoo/odoo#240920
This update fixes an issue where search suggestions were hidden behind product categories when using the grid layout in the website. The fix ensures that search suggestions are always visible, improving the user experience when browsing products in a grid format. This change was made to resolve a visual bug impacting product discovery.
Original PR description
Steps to reproduce: =================== - Add a product categories block with a search bar in the inner content of the block, like "s_product_list". - Drag a "Search" snippet inside of the block in…
Steps to reproduce: =================== - Add a product categories block with a search bar in the inner content of the block, like "s_product_list". - Drag a "Search" snippet inside of the block in top of products categories - Change the layout to "Grid" & Save. - Type in the search bar to trigger autocomplete suggestions. -> The suggestions appear behind the product categories and are not visible. Cause: ====== When a searchbar snippet is placed inside a section using grid mode, the autocomplete dropdown was hidden behind sibling grid items. This occurred because the grid layout applies inline z-index to each column (via `_placeColumns` `in grid_layout_utils.js` (See [1])), creating stacking contexts that trapped the dropdown. So once you change to grid mode layout `_toggleGridMode` function will be triggered which will call `_placeColumns` that will assign z-index; (See [2]) Solution: ========= Override the inline z-index on grid items containing a searchbar [1]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L225 [2]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L138 opw-5392011 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239607
This update resolves an issue where image columns appeared too small in the website editor's grid mode, particularly on mobile. The fix ensures that background images are now correctly considered when calculating grid item sizes, resulting in a more consistent and visually appealing layout.
Original PR description
Steps to reproduce: =================== - In website edit mode, drop the "Split Intro" snippet. - Toggle it to grid mode. => the image column is smaller than expected. - Switch to mobile view => the image column is really small. Cause & solution: ================= When toggling a snippet to grid mode, when computing the size of the grid items, the padding of a column is taken into account only if it has a background color (`o_cc` class), in order to look as close as possible as before. The background images are therefore not considered, so the size is computed without the padding, resulting in a grid-area smaller than expected, and the default grid item padding (which is why it is that small in mobile view). This commit fixes that by including the background image class (`oe_img_bg`) in the check used to consider the padding. opw-5374492 Forward-Port-Of: odoo/odoo#240573