Daily updates from Odoo
Monday, December 29, 2025
12 changes · saas-18.3
Resolved issues and error corrections
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 pull request updates the core spreadsheet library used within Odoo. The changes address several technical issues related to data validation and highlighting, ensuring the spreadsheet functionality remains stable and reliable. These updates contribute to a smoother user experience when working with spreadsheets in Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1e143e1470 [REL] 18.3.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1e143e1470 [REL] 18.3.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b718b6079d [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580) https://github.com/odoo/o-spreadsheet/commit/b2f4e15ffd [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 receipts attached to expenses. Previously, users needed specific administrator permissions. The change now allows digitization when the expense is in draft status, streamlining the expense reporting process.
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, such as those common in Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct address data is transmitted to Sendcloud. This improves delivery accuracy and reliability.
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 loading times 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 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 and maintaining smooth slot management. This improves the user experience and prevents disruptions to planning workflows.
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 fixes a pop-up error that occurred when users switched back to a previous order after processing a Pine Labs payment. The fix ensures the system only attempts to retrieve payment status when the necessary transaction ID is available, improving order processing reliability for our Indian retail customers.
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 resolves an issue where reward lines weren't consistently displayed in Restaurant POS orders after switching between the front-end and back-end. The fix ensures reward lines are correctly created and maintained, preventing data loss and improving the order management experience. This impacts users managing orders in the Restaurant UI.
Original PR description
pos*: point_of_sale, pos_restaurant_loyalty Steps to reproduce: - Open a table in the Restaurant UI. - Click the Course button. - Add products that trigger a reward line creation. Issues: - The reward line is not visible in the order. - After switching to the backend and returning to the POS, no order lines are visible for that order. Fixes: - Ensure the reward line is created within the proper course. - Prevent deletion of the reward line when switching between backend and POS. Task: 5215920 Forward-Port-Of: odoo/odoo#233919
This update addresses a bug in the 'knowledge_calendar_command_tour' that prevented it from working correctly in Chrome 143 and later. The fix, stemming from a Chromium update, ensures FullCalendar events are dispatched properly when attached to shadow trees, resolving a compatibility issue that affected Firefox and Safari.
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 searching for products within grid-based sections. This change was made to address a visual bug and enhance usability.
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 fixes an issue where image columns appeared too small in the website editor's grid mode, particularly on mobile. The fix ensures background images are correctly accounted for when calculating column 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
This update fixes an issue where employees with past accrual allocations weren't correctly reflecting available vacation days on their Time Off Dashboard. Now, future leaves are only excluded from available days if an employee can still accrue more vacation time before the leave date, ensuring accurate tracking of time off.
Original PR description
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb.…
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb. 2023 to May 2024. Since then, all his allocations have been regular allocations, so he is no longer accruing vacation days. But, Norbert’s future leaves do not get counted against the “Days Available” displayed on his Time Off Dashboard. Current behavior before PR: If an employee had an accrual allocation (of the relevant type, e.g. past vacation allocations won’t affect sick leave) at any point in time, their future leaves do not get counted against the “Days Available” on their Time Off Dashboard. Desired behavior after PR is merged: If an employee has an accrual allocation between today’s date and the date of a future leave, that future leave does not get counted against the “Days Available” on their Time Off Dashboard. That way, we will count a leave against “Days Available” unless there is a possibility of accruing more days off before the leave. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238977