Daily updates from Odoo
Tuesday, January 7, 2025
10 changes
1 change
Resolved issues and error corrections
This update prevents website live chat from crashing on mobile or small screens when an operator has a custom chat display name. Customers can now start and continue live chat conversations reliably in that scenario.
Original PR description
On small displays, starting a new website livechat with an operator that has an `user_livechat_username` crashes when rendering the username.
Steps to reproduce
-----
1. Select User Menu Icon > My Profile / Preferences > enter an Online Chat Name
2. On a mobile device or small window, open the livechat on the website
3. Send any new message
4. The following traceback occurs
```
Caused by: TypeError: Cannot read properties of undefined (reading 'channel_type')
at get authorName
```
Cause
-----
On small displays, `thread` for the default operator message becomes undefined when it is reassigned to the new thread. This causes an error in `get authorName()` when the undefined `thread` is accessed directly to detemine the displayed username.
Solution
-----
Add an optional chain (?) when accessing `this.message.thread` to handle the possible nullish value.
opw-4446208
Backport of odoo/odoo#1926059 changes
Resolved issues and error corrections
This change separates invoice-specific processing from shared EDI import logic so purchase orders no longer receive invoice-only fields. It prevents errors when importing orders from EDI data while keeping invoice imports unaffected.
Original PR description
Steps: - Install sale app. - Upload PO field which contain EDI data. Issue: - Order is not imported properly and giving error. Cause: - When `_retrieve_line_vals` call from order edi it should not contain invoice related values but when `account.move.line` has `deferred_start_date` and `deferred_end_date` it return those field even it called from order edi and SOL does not contain those fields Fix: - Move invoice related specific code in other method and only keep generic code which can be used in both invoice and order in generic method to ensure there is no invoice flow impacted by order edi and vice versa. Issued PR: https://github.com/odoo/odoo/pull/191487
This fix ensures sales order lines still calculate the correct price when the unit price field is made read-only through customization. It prevents affected orders from accidentally showing zero-priced amounts, reducing billing and quotation errors.
Original PR description
The new `technical_price_unit` logic was introduced to reduce/prevent unexpected price recomputations when the price is manually updated on sale order lines. Nevertheless, if the price_unit field is made readonly (through studio or any custom view ...), the price would stop being sent to the server by the client, resulting in zero-priced amounts because the presence of the technical price discarded the price recomputation, leading to the default 0 value. This commit makes sure that in this situation, the technical price sent by the client is dropped, ensuring that the price is correctly computed. opw-4319211
Users downloading a PDF from the bank statement list will now receive the selected bank statement instead of an unrelated accounting document or an error. This removes a confusing duplicate download option and helps accounting teams access the right statement reliably.
Original PR description
In Bank Statement list view users may select a statement and download a pdf report. However, currently, users have 2 download action, one of which is downloading a seemingly random account move Steps to reproduce: - In Accounting Dashboard, from a bank journal card, 3 dots > Statements - Select a line - Download > PDF Issue: PDF target is loaded via the `loadExtraPrintItems` method However, the request is done to the `account.move` model using the id of the bank statement, so it may retrieve an invoice, or fail Note: Download > Statement is working properly A solution is to avoid loading extra print item with loadExtraPrintItems if we are not in the `account.move` model opw-4388554
Hungarian electronic invoice reports now display the invoice number correctly when using newer document layouts. This prevents missing invoice identifiers on printed or PDF invoices, reducing confusion and compliance risk for Hungarian customers.
Original PR description
Since the introduction of new layouts (e.g. folder), the invoice number is not displayed in Hungary. This is because the xpath is incorrect because the new layouts now have two children instead of…
Since the introduction of new layouts (e.g. folder), the invoice number is not displayed in Hungary. This is because the xpath is incorrect because the new layouts now have two children instead of one. The old ones only had one child node: https://github.com/odoo/odoo/blob/4dad76c045f94861632929189baa96d69f662275/addons/web/views/report_templates.xml#L478-L506 Whereas the new ones have two: https://github.com/odoo/odoo/blob/4dad76c045f94861632929189baa96d69f662275/addons/web/views/report_templates.xml#L535-L550 https://github.com/odoo/odoo/blob/4dad76c045f94861632929189baa96d69f662275/addons/web/views/report_templates.xml#L551-L579 So the problem with the current xpath is that it's replacing both children, even though only the second one should be. By 'replacing' the first one (by iffing it), `layout_document_title` is not displayed anymore and therefore no invoice number appears on the invoice. To fix this, we use a different xpath on the `img` parent. For consistency and maintainability reasons, we apply this new xpath on all the layouts and not just the new ones. opw-4397438
This fixes how Point of Sale reports changes when a note is added or edited on an existing order line. Preparation screens and kitchen tools will no longer mistake a note update for an entirely new item, reducing confusion and duplicate preparation work.
Original PR description
The return value of [`changesToOrder`](https://github.com/abichinger/odoo/blob/74273fea6a9c7f57da95aa120fd2767443822c46/addons/point_of_sale/static/src/app/models/utils/order_change.js#L1) is missing…
The return value of [`changesToOrder`](https://github.com/abichinger/odoo/blob/74273fea6a9c7f57da95aa120fd2767443822c46/addons/point_of_sale/static/src/app/models/utils/order_change.js#L1) is missing a line inside the `cancelled` array, while updating the note of an existing order line. From the POV of a preperation tool, this makes it look like a new item has been added to the order.
https://github.com/user-attachments/assets/618263ac-0a61-42f2-b662-10e1ae63e39f
While recording the video I captured the following values from `changesToOrder`
```jsonc
// 1st output after the orderline was created
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": []
}
// 2nd output after the note was added
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "Zero",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": []
}
```
I would expect the second output to look like this
```jsonc
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "Zero",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
]
}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prRestaurant staff using an open point-of-sale screen will now see new unpaid self-orders appear automatically, without needing to manually open the orders list. This helps teams respond faster to mobile orders and keeps multiple restaurant stations better synchronized.
Uploading or generating Factur-X invoices without currency information no longer causes an error. The system now uses the company's default currency when no currency is provided, helping invoice processing continue smoothly.
Original PR description
This error occurs when uploading a ``factur-x.xml`` file that lacks currency information or when the ``factur-x.xml`` file we generate does not include any currency. Steps to reproduce: --- - Install…
This error occurs when uploading a ``factur-x.xml`` file that lacks currency information or when the ``factur-x.xml`` file we generate does not include any currency. Steps to reproduce: --- - Install ``account_edi_ubl_cii`` module - Invoicing > Customers > Invoices - Click ``Upload`` button and upload [file](https://drive.google.com/drive/u/0/folders/1TrG7xBUdwdq04KueZi0WdxHxm_g0vfW_) Traceback: --- NotNullViolation: null value in column "currency_id" of relation "account_move_line" violates not-null constraint DETAIL: Failing row contains (50, 50, 9, 1, 125, 100, 205, null, 56, null, null, null, null, null, null, null, null, null, null, null, 2, 2, null, null, null, NEWS9141525, null, product, null, null, null, null, null, 0.00, 0.00, 0.00, 0.0, null, null, null, 1.00, 109.72, null, null, 0.00000000000000000000000000000000000000000000000000000000000000..., null, null, null, null, null, 2025-01-02 01:03:08.880424, 2025-01-02 01:03:08.880424, null, null, null, null, null, null, null, null, null). This commit resolves the issue by adding the default company currency when no currency is found in the file. sentry-6056586239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents website livechat from crashing on mobile or narrow screens when an operator has a custom chat name. Visitors can start and continue chats reliably, improving the customer support experience.
Original PR description
On small displays, starting a new website livechat with an operator that has an `user_livechat_username` crashes when rendering the username.
Steps to reproduce
-----
1. Select User Menu Icon > My Profile / Preferences > enter an Online Chat Name
2. On a mobile device or small window, open the livechat on the website
3. Send any new message
4. The following traceback occurs
```
Caused by: TypeError: Cannot read properties of undefined (reading 'channel_type')
at get authorName
```
Cause
-----
On small displays, `thread` for the default operator message becomes undefined when it is reassigned to the new thread. This causes an error in `get authorName()` when the undefined `thread` is accessed directly to detemine the displayed username.
Solution
-----
Add an optional chain (?) when accessing `this.message.thread` to handle the possible nullish value.
opw-4446208This fix ensures that when a receipt is partially validated and a backorder is created, the original quality check stays linked to the correct receipt. This prevents quality records from being incorrectly attached to the backorder, improving traceability and reducing confusion in warehouse quality control.
Original PR description
Steps to Reproduce the Bug: - Create a storable product “P1”. - Create a Quality Point with the following settings: - Product: P1 - Operation Type: Receipt - Control Per: Product - Type: Pass-Fail - Create a receipt for 10 units of P1. - Mark it as "To Do". - Set the field "Quantity" to 5 units. - Validate. - A wizard to create a backorder is triggered -> Validate the creation. - A wizard for the quality check is triggered. - Pass the quality check. Problem: A backorder is created, but the first quality check is incorrectly linked to this new picking instead of creating new one, because the `default_quality_check` was set in the context and not cleared. Before this commit, the picking was not validated after confirming the quality check wizard: https://github.com/odoo/enterprise/commit/936e8f84a3a70a26692cc4620f146539bde81a17#diff-56e04e66113804374104e1d1ccf225cb88ab2040c65743e0eb01a970351cdb7fR106-R107 **Opw-4428051**