Daily updates from Odoo
Wednesday, February 19, 2025
17 changes
1 change
Resolved issues and error corrections
This update fixes an issue in Point of Sale where users could not scroll through the customer list on mobile devices. It also ensures customer search and loading more customers work reliably on mobile, making checkout and customer selection smoother for staff using phones or tablets.
Original PR description
Fix: - This commit fix an issue where we were not able to scroll on mobile in the partner list. - Also it now trigger correclty the `onScroll` event on mobile. Since the scrollable DOM element is different on desktop and mobile devices, we need to define correctly the `scrollTarget` depending on `isSmall` or not. Test: - Introduce a frontend test to ensure customer search and infinite scroll work as expected. enterprise PR: https://github.com/odoo/enterprise/pull/79089 task-id: 4550203 Description of the issue/feature this PR addresses: 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
3 changes
Resolved issues and error corrections
This fix prevents WhatsApp message button links from being accidentally altered in a way that could create incorrect destinations. It also improves validation so buttons load in the right order and generate the correct link details.
Original PR description
Incorrect dynamic button behaviour is fixed. Dynamic web buttons have fixed base, only last part can be modified, therefore making base part readonly is essential, otherwise meta appends any modified base url to originally submitted base url. Additionally, test is added to make sure that buttons are loaded correctly, according to their sequence number and also base and short_url calculation is correct. task-3908799
The Spanish Modelo 390 BOE export has been updated for the 2024 requirements and now correctly generates files from the report wizard. It also adjusts required identity fields so self-employed individuals and companies can complete the export using the appropriate information.
Original PR description
This commit updates the BOE mod390 export for 2024 and set some fields as not mandatory that should not be as you are either a self-employed (and then you use the natural person fields), or you are a company and the other fields are needed. Task: 4453629 Fwd port of https://github.com/odoo/enterprise/commit/fd14c05bcf238d2da7de825d1a6c751381c153b7 Odoo PR: https://github.com/odoo/odoo/pull/196578
This update corrects how VoIP stores and reads landline and mobile phone numbers after recent field name changes. It helps ensure the softphone shows the right contact numbers and avoids errors when viewing correspondence details.
Original PR description
This commit fixes the naming of the `landlineNumber` field. Previously, this field was referred to as the `phone` field. This commit changes its name to `phoneNumber`. Also, we had a `mobile` field that was removed in this PR: https://github.com/odoo/odoo/pull/189739 and it resulted in a bug in the `mobileNumber` getter in `correspondence_details.js` as it was retrieving a `phoneNumber` attribute from the `partner` model. In contrast, it doesn't have this attribute. Community: https://github.com/odoo/odoo/pull/197205
13 changes
Resolved issues and error corrections
When multiple guests scan the same table for self-ordering with pay-after-meal, they now work from the same active order instead of creating separate ones. This helps avoid duplicate or conflicting orders and makes the dining experience smoother for both guests and staff.
Original PR description
When self ordering is setup with pay after meal, and two users scans the same table. The order is now shared between the two users. taskId: 4489980
This fix prevents Odoo from raising a server error when a linked record field is empty. Users and custom modules can now handle missing values more safely, improving stability without changing normal behavior.
Original PR description
In OCA we develop a module that assigns dynamic attributes to a product. In odoo 16.0 and prevous 14.0 the module is running smoothly with odoo. In this version convert_to_read method is introduced…
In OCA we develop a module that assigns dynamic attributes to a product.
In odoo 16.0 and prevous 14.0 the module is running smoothly with odoo.
In this version convert_to_read method is introduced and it deals with use_display_name and value, it assumes value record is always has a value
Aluthough use_display_name can be False or value record can be empty.
In that case I retun False instead of causing the server to raise error because it assumes value has id and it is just an empty recordset.
Current behavior before PR:
2025-02-19 20:15:58,724 46176 ERROR pim_17_1 odoo.http: Exception during request handling.
Traceback (most recent call last):
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 2206, in __call__
response = request._serve_db()
^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 1782, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/service/model.py", line 133, in retrying
result = func()
^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 1809, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 2013, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/addons/web/models/models.py", line 86, in web_read
values_list: List[Dict] = self.read(fields_to_read, load=None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/models.py", line 3557, in read
return self._read_format(fnames=fields, load=load)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/models.py", line 3770, in _read_format
vals[name] = convert(record[name], record, use_display_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/fields.py", line 3110, in convert_to_read
return value.id
^^^^^^^^
Attri
buteError: 'mail.thread' object has no attribute 'id'
Desired behavior after PR is merged:
The method can just retun False if no condition is met.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue that blocked users from creating manufacturing orders with work orders on small mobile screens. Required manufacturing details are now included in the mobile view, preventing save errors and supporting mobile production workflows.
Original PR description
**Current behavior:** Trying to create an MO on mobile which has work orders is not possible. **Expected behavior:** Can create. **Steps to reproduce:** 1. Install `mrp` with demo data 2. Login, in dev tools change viewport size to iPhone SE (a small screen) 3. Open Inventory -> Manufacturings 4. Click `New`, change product to stool (any variant) 5. Try to save -> `ValidationError` **Cause of the issue:** `workcenter_id` and `product_uom_id` have been removed from the kanban view in commit: b1ceec4c which is used on mobile, meaning that these required fields are not in the save vals returned to the server in the CREATE tuple. **Fix:** Add them back to the kanban view. opw-4440060
Point of Sale category navigation now shows parent categories even when products are only assigned to child categories. This restores the expected category hierarchy so staff can browse products through the correct parent and child structure.
Original PR description
This commit reverts: https://github.com/odoo/odoo/commit/d7d3ed847f147dac23264e91b5d802cd67be6860 After discussing with POS PO the behavior introduced in the commit is not desirable and cannot be introduced in stable. # How to reproduce the issue: - In Pos Product Categories, create a category "Parent", - Create another category "Child" with its parent being "Parent" - Create a new product with the POS category "Parent/Child" - In the pos product displayed, the category display is "Child" and not "Parent" https://github.com/odoo/odoo/commit/d7d3ed847f147dac23264e91b5d802cd67be6860, made the POS category visible only if there is a product in it. However, if the parent category has no products, it won't be displayed. opw-4561712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The kiosk payment screen now only shows the Stripe payment methods assigned to that specific kiosk. This prevents customers from seeing or selecting payment options that were not intended for that kiosk setup.
Original PR description
When you have multiple payment methods that can work on the kiosk, they would all be shown on the kiosk screen. Steps to reproduce: ------------------- * Setup 2 Stripe payment methods * Create a PoS kiosk * Assign one of the methods to the kiosk * Open the kiosk * Create an order and go to the payment screen > Observation: Both payment methods are shown Why the fix: ------------ The payment methods are now filtered based on the payment methods assigned to the kiosk. opw-4574644
This fixes an issue where website Add to Cart buttons could show an error when linked to products with variants outside the normal product page. Customers can now add those products from custom website pages, reducing checkout friction and broken shopping experiences.
Original PR description
## Versions: 18.0+ ## Issue: Clicking on the `Add to Cart` button displays an error message if configured on a product having variants. The issue seems to come from the following PR: https://github.com/odoo/odoo/pull/187556 ## Steps to reproduce: Go to the `Website` app on home page in edit mode; From the `BLOCKS`'s `Inner content` widgets add a `Add to Cart` button anywhere on the page; Select the button to configure it; Select a product with variants as `Product` (e.g. `Acoustic Bloc Screens`); *Optional: choose a variant too;* Save; Click the added `Add to Cart` button. ## Cause: The code tries to access an inexistant form. opw-4573435 opw-4577757 opw-4561122 opw-4548344 opw-4567354
This fixes an issue where banner content could lose editing settings after being cleaned up in the HTML editor. Users can now place the cursor inside banners as expected, making banner editing smoother and more reliable.
Original PR description
**Current behavior before PR:** - The html_sanitize method sanitized certain banner attributes, such as contenteditable, role, and aria-label. This caused an issue where, when a blur event was triggered, the innerHTML of the current banner would be replaced with sanitized HTML. As a result, these attributes were removed, and the absence of the contenteditable attribute made it impossible to place the cursor inside the banner. **Desired behavior after PR is merged:** - Now, when the normalize method is called, the `contenteditable="true"` attribute will be applied to all elements with the `o_editable` class, and the `contenteditable="false"` attribute will be applied to all elements with the `o_not_editable` class. task-4297729
This fixes an issue where updating taxes and accounts on an invoice after changing the fiscal position could incorrectly delete a line and show a “record does not exist” error. The change keeps invoice updates stable when account mappings are recalculated, reducing disruption during billing adjustments.
Original PR description
When calling `account_move_line._compute_account_id` (via `action_update_fpos_values` for example), we wrongly delete a line after after assigning a new account here…
When calling `account_move_line._compute_account_id` (via
`action_update_fpos_values` for example), we wrongly delete a line after
after assigning a new account here https://github.com/odoo/odoo/blob/22bdaf64ff3f2ee37cd51f0938d1bdd80f9e5ee8/addons/account/models/account_move_line.py#L599-L602
This is because we set a default value for `analytic_distribution` in
`_prepare_base_line_tax_repartition_grouping_key`, therefore we enter
in the wrong condition here https://github.com/odoo/odoo/blob/6ff943b30561f2d7415fdbdfc2246716428779be/addons/account/models/account_tax.py#L2407
because in `grouping_key`, we have `{'analytic_distribution': {}}` and in `tax_lines_mapping` we have`{'analytic_distribution': False}`
Steps:
- Have a fiscal position that map the default revenue account to another
- Create an invoice with the fiscal position created previously, add a
product line
- Unset fiscal position, and click on 'Update Taxes and Accounts' button
-> Error: "Record does not exist or has been deleted."
opw-4512877This fix ensures stock moves created during procurement adjustment keep the expected make-to-order behavior instead of being treated as regular stock moves. It prevents unwanted sharing of reserved inventory, especially for manufacturing components, helping orders keep the stock allocation intended for them.
Original PR description
Since a72382063ee662, the mtso mechanism always create mts move in `_adjust_procure_method()`. So new move gathering manufacturing component for instance are always created in mts. Which lead to reservation sharing which is not desired in mto flows. Task: 4374225 Description of the issue/feature this PR addresses: 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
Kitchen preparation receipts now keep combo meal items grouped together instead of splitting them by product category. This makes orders clearer for restaurant staff and reduces the risk of preparing combo items incorrectly.
Original PR description
When sending combo products that contains different products with different pos categories, the receipt was not showing the products grouped by combo. Steps to reproduce: ------------------- * Create a combo product with different products with different pos categories * Setup a preparation printer that will print all categories * Open PoS and add at least 2 combo products with different selection * Send the order to the kitchen > Observation: The product on the receipt are grouped by product category instead of being grouped by combo. Why the fix: ------------ Instead of sorting all product based on their category, we filter out the combo products first and sort the other products based on their category. opw-4459211
The Barcode app now correctly shows the detailed lines needed when tracked products are grouped in batch operations. It also assigns scanned lots to the right receipt line, helping warehouse teams process grouped receipts accurately and avoid quantity mistakes.
Original PR description
Description of the issue ======================== The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config),…
Description of the issue
========================
The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config), the sublines weren't displayed.
This issue was caused by the way we choose to display or not sublines. For a tracked product, we don't display them if reserved lot/serial is hidden (picking type config) and if there is no qty done.
That said, that didn't take in consideration the grouping by product where lines for different pickings are grouped together.
In this case, it's better to show the qty demand anyway to know how many quantity needs to be processed for each picking.
Once this issue is fixed, a second issue appears.
Imagine you have this following case:
- 1 line for lot product (0/4 qty) for receipt 1;
- 1 line for lot product (0/4 qty) for receipt 2.
- In batch, these lines are grouped because they share the same product.
Now, let's say we do the following process:
1. Scan the lot product -> The grouped line is selected;
2. Scan lot01 two times -> receipt 1 line is now 2/4 qty with lot01;
3. Scan lot02 -> receipt 2 line is now 1/4 with lot02.
The point 3. where is the issue happens. Usually, when we scan a lot, we check if the line is completed or not by checking its parent line's quantity. Here, the parent line is the batch grouped line and should not work exactly like that, because by checking this line as the parent of every sublines means we can't know if a particular picking need is fulfilled or not.
How to reproduce
================
- Inventory > Configuration > Operations Types > Barcode App:
- Uncheck "Show reserved lot/SN";
- Check "Group batch lines".
- Create two receipts for the same tracked by lot product;
- Create a batch for this receipt;
- Open the batch in the Barcode app -> You can see there is a line for this product with the total quantity but when clicking on the button to display sublines, the sublines are not shown.
Fix
===
For the first issue, we simply added a condition for `stock.picking.batch` to adapt to this case.
For the second issue, the group by tracked product inside a single picking and the group by product inside a batch are not the same and use a different key.
The first kind of group uses the key `parentLine` and the second one use the key `batchParentLine`. When we want the parent line of a subline, we will always refer to the `parentLine`. But in the interface, if this parent line is itself inside a `batchParentLine`, the `parentLine` won't be displayed, only the batch parent line.
That way, the user still has all lines for a same product grouped together under a single parent line, but to know if a need if fulfilled,
we still check on the parent line limited to a single picking.
[opw-4291149](https://www.odoo.com/odoo/project/49/tasks/4291149)Inventory Count now uses clearer wording and a corrected product selection rule. Users can include the right storable and inventory-tracked products during counts, reducing confusion and missed items.
Original PR description
With this commit ================ - Renamed the return value of the getName method to `Inventory Count` for consistency with the Inventory Count button on the main page. - Rephrased toaster message for Inventory Adjustment Validation. - Updated the domain in the product form of Inventory Count to include `storable/inventory tracked` products. Task: [4458119](https://www.odoo.com/odoo/my-tasks/4458119)
Loans using the Skip Until Date setting now move to the correct status when confirmed, even if earlier scheduled entries are skipped. This prevents loans from remaining in draft and avoids an error when users try to confirm them again.
Original PR description
Users managing loans can set the flag Skip Until Date to skip the first entries. However skipped loan lines won't create any move and this create issues with assignment of the correct state when load should be closed Steps to reproduce - Create a loans as follows: - Name: any - Amount Borrowed: 20,000.00 - Interests: 107.87 - 01/01/2024 - Duration: 12 months - [Loan Settings] Skip Until: 10/31/2024 - Save, compute sheet and confirm Issues: - Once confirmed it doesn't change state from "draft" - If we click once again "Confirm" we will get a traceback error opw-4476981