Daily updates from Odoo
Tuesday, January 7, 2025
25 changes · 18.0
Resolved issues and error corrections
This fixes an issue in the HTML editor where hidden collaborator avatars could still be selected and prevent users from moving content blocks. The change makes those avatars truly non-selectable when hidden, improving collaborative editing reliability.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: It was not possible to use the move node handler when the collaborator is on the same node, because the collaboration avatar is hidden using opacity 0 which still allowed the avatar to be selectable. Desired behavior after PR is merged: Hide the collaboration avatar using visibility hidden, ensuring it is not selectable. task-4348275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Tests now keep Peppol in demo mode by default, so they use mocked behavior instead of contacting real or sandbox Peppol services. This makes automated testing safer and more reliable when Peppol is installed alongside other accounting modules.
Original PR description
Context: In Peppol, we have multiple EDI mode: - `production` that will call the real Peppol infrastructure, - `test` that will call the sandbox Peppol, - `demo` that makes no call at all, everything is mocked. By default, runbots and demo data are set to `demo`. In tests, the value is therefore also `demo`, which is what we want: No call to external services. Before this commit, we were doing some weird and useless override in the handling of demo functions, which is useless: if you want to test Odoo in a particular mode, just set it (this is what we do in Peppol tests' `setUpClass`), for all other tests, keeping the default demo mode should be preferred. This was a problem because tests ran by other modules with Peppol installed were trying to make external calls. task-no
Product margin reporting no longer triggers unnecessary database updates when grouping or aggregating product margin fields. This prevents misleading modification timestamps and reduces avoidable background work, without changing the reported business values.
Original PR description
When we aggregate one of the field of "product.product" introduced by 'product_margin' module, it will generate a SQL update on all records read. It is because we call the compute method manually without protecting computed fields, which will lead to call BaseModel.write() that update write_date/write_uid. Fix it by calling `compute_value` of one of the field. ### Notes - Should we backport it in 17.0 but then we need to backport https://github.com/odoo/odoo/pull/155585 too ? Also for the 16.0 ? - For master: remove the return of `_compute_product_margin_fields_values`, people shouldn't call that manually too avoid the issue mention in the commit message.
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 update prevents the website editor from accidentally removing spaces between inline content and avoids errors when users outdent list items that contain only empty content. It helps make editing formatted text more reliable and reduces interruptions for users working with lists.
Original PR description
[FIX] html_editor: space removal by wrapInlinesInBlocks <- fix required for the following one [FIX] html_editor: outdent list item with empty nodes task-4398327
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
This fixes a point of sale issue where the product search bar disappeared after navigating back from the payment screen. Cashiers can now resume searching products immediately, reducing checkout friction.
Original PR description
Before this commit, when going back from the payment screen to the product screen, the search bar wasn't visible. opw-4318710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Importing a price list rule with only a product variant will now automatically fill in the related product template. This prevents imported rules from appearing incomplete or behaving unexpectedly, helping pricing data stay reliable.
Original PR description
Since recent changes to the pricelists rules, importing a rule with the 'Product Variant' field value specified but not the template field value led to incomplete rules not being displayed (and maybe not even behaving) as expected. This commit makes sure that if the template was forgotten in the create values, it's correctly deduced from the given product.product record. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Adding rows or columns in the HTML editor no longer forces tables to adopt fixed widths or heights when they were originally flexible. This preserves the intended layout behavior and reduces unwanted formatting changes for users editing website or document content.
Original PR description
### Steps to reproduce: - Insert a table. - Observe the HTML, noticing that the table does not have a fixed width or height. - Insert a new column or row. - Observe the HTML, noticing that the width and/or height of the table has been fixed. ### Description of the issue/feature this PR addresses: - When a new column is inserted into the table, the table's width is fixed, and the widths of the first row/column cells (TDs and THs) are also fixed. - When a new row is inserted, the height is added to the table rows (TRs), even if the table initially did not have fixed dimensions. ### Desired behavior after PR is merged: - The width and height of the table will not be fixed when a new column or row is added, as long as the table did not have fixed dimensions (width/height) to begin with. task-4402552
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.
This fixes demo mode for Peppol electronic invoicing after a previous internal change left some connection calls using an outdated path. Demo environments should no longer hit errors when testing Peppol flows, making demonstrations and trials more reliable.
Original PR description
With previous refactor, we simplified the demo mode by trying to mock the fewer methods possible. In particular, we are aligning all calls to proxy to go through the `_call_peppol_proxy(...)`. This should simplify future refactoring work to get rid of account_edi_x models. Some calls to make_request were still existing, since it's no longer mocked in demo mode, an error is raised. Replace all those calls to use the `_call_peppol_proxy` method. task-no
This fix makes automated website tours wait until popup windows are fully displayed before continuing. It reduces false test failures caused by tours trying to interact with popup content too early, improving reliability for event, forum, and newsletter website flows.
Original PR description
In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it. This fix add classes to ensure modal is shown before continuing the tour. 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
This fix ensures Danish businesses using the 0184 identifier scheme send the VAT number in the format required by PEPPOL rules. It helps prevent electronic invoices from being rejected due to non-compliant company identifiers.
Original PR description
Based on PEPPOL-COMMON-R042 (https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-COMMON-R042/) when using the 0184 scheme the VAT number should be used (CVR number prefixed by the country code) @JulienVR @smetl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when users create a new bank statement from the transaction list and enter a custom name, Odoo keeps that name instead of replacing it automatically. It prevents confusion and rework during bank reconciliation workflows.
Original PR description
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that during the initial creation of the statement, a value is given to end_date which triggers to recomputation of the name, regardless of if the statement already had a name or not. So to fix that, we simply only try to compute the name for statements that don't have one yet ticket-4424021 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
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
When users create warehouse transfers from the Project topbar, Odoo now preselects the appropriate transfer type based on their default warehouse. This prevents extra manual setup and reduces the chance of creating transfers with missing information.
Original PR description
Steps to reproduce: - Set default Warehouse in the profile. - From Project topbar open either "From WH" or "To WH". - Create a new stock picking Issue: - The stock picking type is not set by default Reason: - Non existence of supplied values. Solution: - Supply default picking type if user has a default warehouse. task-4207753
Creating an analytic account from a project now uses the project's company by default instead of the user's current company. This prevents company mismatches when projects have no company or belong to a different company, reducing accounting inconsistencies.
Original PR description
Before this commit, when creating a new analytic account in any plan from the project form, the default company of the account was set to the current company of the user. The problem that arises is when the project has no company, and the account is set to a company. Which creates inconsistency between the project and the account. After this commit, we set the company of the created account to the company of the project by default. task-4438410 version-18.0 --- 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 prevents Odoo from reloading the same view unnecessarily when users schedule activities from different contact cards. It reduces avoidable background requests, making the interface more efficient and potentially more responsive.
Original PR description
Steps to reproduce (a bit technical): 1. Navigate to the "Contacts" kanban view. 2. Open the Network tab in the browser's developer tools. 3. Click on the first contact activities and "Schedule a new…
Steps to reproduce (a bit technical): 1. Navigate to the "Contacts" kanban view. 2. Open the Network tab in the browser's developer tools. 3. Click on the first contact activities and "Schedule a new activity". 4. Notice a call to `get_views` in the Network tab. 5. Click on a different contact activities, and "Schedule a new activity". 6. Notice a new call to `get_views` in the Network tab. Expected: The view is already cached, so the webclient should not attempt to load it. Explanation: This is likely a regression since f983703d, when the embedded actions were introduced. Now, the `embeddedParentResId` is part of the views cache key, and so we get much fewer cache hits. For most views, there isn't really an `embeddedActionId` set, and yet the `embeddedParentResId` was always set. The later is only used in combination with `embeddedActionId`, so it causes a lot of avoidable cache misses. The solution is to simply set the `embeddedParentResId` only if there's an `embeddedActionId`. Closes odoo/odoo#192261 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
This 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**
The guided website helpdesk forum flow now waits until pop-up windows are fully ready before continuing. This helps prevent intermittent failures in automated checks, making releases more stable without changing the customer-facing experience.
Original PR description
In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it.
In odoo/addons/website/static/src/js/content/website_root.js the class modal_show is added in _onModalShown:
```javascript
_onModalShown: function (ev) {
$(ev.target).addClass('modal_shown');
},
```
This fix add classes in triggers to ensure modal is shown before continuing the tour.This fix prevents an error when creating a Mexican global invoice from a draft invoice that has no assigned number yet. Users now avoid a blocking crash and can receive the intended validation message instead.
Original PR description
When a customer creates a global invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_mx_edi`` module > Switch to Mexican company - Create an invoice without customer and…
When a customer creates a global invoice, a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_mx_edi`` module > Switch to Mexican company
- Create an invoice without customer and product > Save
- Go back to List view of invoices
- Select that invoice > Actions > Create Global Invoice
Traceback:
```
File "home/odoo/src/enterprise/18.0/l10n_mx_edi/wizard/l10n_mx_edi_global_invoice_create.py", line 23, in default_get
invoices = source_invoices._l10n_mx_edi_check_invoices_for_global_invoice()
File "home/odoo/src/enterprise/18.0/l10n_mx_edi/models/account_move.py", line 306, in _l10n_mx_edi_check_invoices_for_global_invoice
invoices_str = ", ".join(failed_invoices.mapped('name'))
TypeError: sequence item 0: expected str instance, bool found
```
https://github.com/odoo/enterprise/blob/01f749f40fc4b5f9708696dc42eab7125e790b28/l10n_mx_edi/models/account_move.py#L306 When a customer creates a new invoice, ``name`` will be False,
When the customer tries to create global invoice,
So it will lead to the above traceback.
sentry-6197401330