Friday, June 27, 2025
41 changes · saas-18.3
Resolved issues and error corrections
Printed documents no longer show extra blank lines when a customer address is missing one of the street fields. This keeps quotations, sales orders, invoices, and related PDFs looking cleaner and more professional.
Original PR description
**Issue**: Empty lines appeared in PDF reports (e.g. quotation, sales order, invoice...) when either the `street` or `street2` was empty. **Steps to reproduce**: - Open the Sales app - Create a new quotation - Set a customer with an incomplete address (either street or street2 left empty) - Click the "Print" button to generate the PDF **Cause**: The commit [29f7475](https://github.com/odoo/odoo/commit/29f7475437586363e473955315d74aef7d80028c) unintentionally removed a line of code that cleaned up whitespace before line breaks. This caused unwanted empty lines in the output: `name = re.sub(r'\s+\n', '\n', name)` **Solution**: -Rather than reintroducing a regex as a workaround to clean up formatting after the fact, the issue is now addressed directly in the `_display_address` method, preventing it at the source. -The test `test_import_partner_postal_address` has been adapted since the behaviour of `_display_address` changes. opw-4795300
The Kanban view now focuses the search bar only when the page first loads, rather than every time records are deselected. This prevents unexpected cursor jumps and makes bulk selection workflows smoother for users.
Original PR description
Before this commit, when deselecting multiple records in kanban view the focus is set on the searchbar. Like the list view it should take focus on first load but not each time it's displayed. Task-4813624
Addresses now skip the second street line when it has no content. This removes unnecessary blank space and makes customer or company addresses look cleaner wherever they are displayed.
Original PR description
When the address is shown, if the street 2 is empty, there is a empty line. Now, this line is removed. TASK-ID: 4900293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could appear when a customer paid through self-order while the related Point of Sale configuration was open. The system now avoids processing empty session data, preventing the checkout and ticket-printing flow from showing a traceback.
Original PR description
Step to reproduce: - Make an order in self order mode - Pay it, while the linked pos config is open - A traceback will be shown in the pos config Issue: When printing the ticket on the pos config, notify_synchronisation function is called with no records in the session model. _post_read_pos_data will be called with empty data array. Fix: Prevent calling _post_read_pos_data with empty records. 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 fixes a small setup issue in the Austrian point-of-sale module by correcting a database script typo. It helps ensure automated checks and module installation work reliably without syntax-related failures.
Original PR description
Steps to reproduce: 1. install `l10n_at_pos` module 2. run `test_10_neutralize` test adding missing commas in the `neutralize.sql` file to ensure proper SQL syntax. Error [link](https://runbot.odoo.com/odoo/error/181676) build_error-181676
The update fixes a return review workflow issue so only newly created returns can be automatically marked as reviewed. This prevents already submitted returns from being moved backward in the process, helping preserve the correct approval status.
Original PR description
When we are trying to auto review returns, we are not checking if the return is a new return and it was possible for checks in the submitted state to be set back to the reviewed state. task-4900867
Bank statement matching now requires a longer reference before treating it as an exact match. This helps reduce incorrect automatic matches during reconciliation and improves accounting accuracy.
Original PR description
Before, aml.ref had to be at least 5char length to be a full match candidate. But it seems 5 is not enough and leads to unwanted matches, so let's increase the limit to 7. no-task
Selecting all documents now correctly focuses the first document when none was previously focused. This keeps the document details panel aligned with the current selection and avoids confusion for users working in list or kanban views.
Original PR description
Before this commit, when selecting all (ctrl-a) in kanban or list views the first document is shown in the detail panel but the focus is not set on it. This commit fix this issue, when no document is focused and we select all the focus is set on the first document, if a document is already selected when selecting all the focus will still be that document. Task-4813624
This fixes an issue where the tax returns page could fail for European companies when an optional VAT validation component was not installed. Users in affected localizations, such as Estonia, can now open returns without encountering a missing setting error.
Original PR description
the field vat_check_vies on res.company is added in the base_vat module, which is not a required dependency for account_reports. the function _generic_vies_vat_check might therefore result in an error with a missing field. runbot issue: 227603
Closing an AI agent chat no longer triggers an error when the chat session reference is missing. The fix also makes chat cleanup work consistently whether users close the chat from the window or the chat bubble.
Original PR description
Before when closing agent chat an exception occurred because the `channel_id` was undefined. This happens because when doing an await in the thread is set to `undefined`. This commit introduces a few…
Before when closing agent chat an exception occurred because the `channel_id` was undefined. This happens because when doing an await in the thread is set to `undefined`. This commit introduces a few modifications to the behaviour of the chat with the agent: Firstly, this commit moves the code calling the ORM to delete the chat history when closing the chat window to the `chat_window_model_patch.js`. This allows for the behaviour to also be applied when closing the chat from the chat bubble. Additionally, the function has been modified to ensure that the thread is defined when the ORM call is made. The ORM call to close the agent chat was simplified to use the already existing `close_ai_chat` from the `discuss.channel` override. The method now uses a new `channel_type` "ai_chat", to identify channels which contain an `ai.agent`. Along with the new `channel_type`, a new function `_get_or_create_ai_chat` was introduced to properly create the "ai_chat" channels. task-4796898
The spreadsheet filter side panel now uses less space for field labels, leaving more room for matching fields. This makes the panel easier to read and use when configuring spreadsheet filters.
Original PR description
reduce the size of the label that took nearly half the width of the sidepanel.
Miscellaneous changes
Problems: The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to automatically balance entries, but this auto-balancing was intended only for lines with taxes. Furthermore, the method _get_automatic_balancing_account in account.move was ignoring any default account set on the journal itself when auto-balancing because of taxes. It was instead always taking th
Original PR description
Problems: The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to…
Problems: The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to automatically balance entries, but this auto-balancing was intended only for lines with taxes. Furthermore, the method _get_automatic_balancing_account in account.move was ignoring any default account set on the journal itself when auto-balancing because of taxes. It was instead always taking the company suspense account. How to reproduce the issue: - Add a default account to the miscellaneous journal. - Create a journal entry manually, and add a line with any account of 100 debit. - Attempt to save. Finally, this commit also set the account_id of new account move lines to the default account id of the journal if it exists when creating a journal entry. enterprise pr: https://github.com/odoo/enterprise/pull/86987 opw-4751270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215393 Forward-Port-Of: odoo/odoo#211443
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happe
Original PR description
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was…
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happened because `s_progress_bar_text` was forgotten during the initial implementation of `s_numbers_charts` [1]. This commit addresses these problems by: - Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template. - Including `s_progress_bar_text` in `_computeSnippetTemplates` to ensure that existing databases also receive this fix, as snippets are stored in the database. - Adding a check in the `progress` option to prevent the aforementioned crash. Steps to reproduce the crash: - Drop the `s_numbers_charts` snippet. - Click on a progress bar within the snippet. - Select the option `Label`. - Hover over "Hide" without any other prior interactions. - A crash will occur. [1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd Forward-Port-Of: odoo/odoo#215946 Forward-Port-Of: odoo/odoo#214318
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior be
Original PR description
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to…
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior before PR: - When selling to other EU countries, a 19% sales tax is added to goods and services. - When buying with other EU countries, a 0% VAT tax is added to goods and a 19% VAT tax is added to services. Desired behavior after PR is merged: - When selling to other EU countries, a 0% sales tax is added to goods and services. - When buying with other EU countries, a 19% VAT tax is added to goods and services, and a second tax repartition line is added at -100% of the tax effectively making it 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215832 Forward-Port-Of: odoo/odoo#211746
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added style="max-width: 100vw;" to table-responsive wrapper to enable horizontal scrolling on smaller screens. Steps to Reproduce: 1. Install the Expenses and Accounting modules. 2. Go to Settings → Search for Analytic Accounting → Enable it. 3. Add multiple analytic plans with sufficient data to cause horizontal
Original PR description
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added…
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added style="max-width: 100vw;" to table-responsive wrapper to enable horizontal scrolling on smaller screens. Steps to Reproduce: 1. Install the Expenses and Accounting modules. 2. Go to Settings → Search for Analytic Accounting → Enable it. 3. Add multiple analytic plans with sufficient data to cause horizontal overflow. 4. Navigate to Expenses → Open any record. 5. Open Inspect in your browser → Switch to mobile view. 6. Click on Analytic Distribution. <details><summary>Images</summary> <p> before FIX:  after FIX:  </p> </details> Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4805590) opw-4805590 Forward-Port-Of: odoo/odoo#212731
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single
Original PR description
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single record uses `message_post` which calls `_message_set_main_attachment_id`. While in the case of a batch, it is not. Solution -------- Explicitly link `mail.message` attachments to the original `account.payment` record. Similar to what is done for `account.move` attachments that are linked to the `account.move.send` records. OPW-4500389 Forward-Port-Of: odoo/odoo#215899 Forward-Port-Of: odoo/odoo#202345
**Problem:** When settling an order that has been paid with a customer account or that has an amount due for that customer, the loyalty points will be awarded again depending on the amount paid. This means that the customer will receive the points in full when making the order, and one more time when settling said order. **Steps to reproduce:** - Make a purchase with Customer Account as payment method - The points are awarded in full - Go to the customer tab and click settle due accounts
Original PR description
**Problem:** When settling an order that has been paid with a customer account or that has an amount due for that customer, the loyalty points will be awarded again depending on the amount paid. This means that the customer will receive the points in full when making the order, and one more time when settling said order. **Steps to reproduce:** - Make a purchase with Customer Account as payment method - The points are awarded in full - Go to the customer tab and click settle due accounts - Select your order and pay for it - The points are awarded once again depending on how much was left to pay **Why the fix:** The points should just be awarded once when the order is confirmed, even if it has not been paid for yet. We now ignore the line if it's about a settled order, as those points have already been awarded. opw-4770142 Forward-Port-Of: odoo/odoo#214137
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number. Current behavior before PR: Duplicated sequence numbers are generated Desired behavior after PR is merged: Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number
Original PR description
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and…
Description of the issue/feature this PR addresses:
if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number.
Current behavior before PR:
Duplicated sequence numbers are generated
Desired behavior after PR is merged:
Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number duplication
Script I used to reproduce the issue:
```python
import threading
import xmlrpc.client
url = 'http://localhost:8069'
db = 'db_name'
username = 'admin'
password = 'admin'
common = xmlrpc.client.ServerProxy('{}/xmlrpc/2/common'.format(url))
uid = common.authenticate(db, username, password, {})
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(url))
models.execute_kw(db, uid, password, 'ir.sequence', 'unlink', [models.execute_kw(db, uid, password, 'ir.sequence', 'search', [[('code', '=', 'test.sequence')]])])
models.execute_kw(db, uid, password, 'ir.sequence', 'create', [{
'name': 'Test Sequence',
'code': 'test.sequence',
'prefix': 'TEST-',
'suffix': '/%(month)s/%(range_year)s/10001',
'padding': 1,
'number_increment': 1,
'use_date_range': True,
}])
def get_sequence_number():
return models.execute_kw(db, uid, password, 'ir.sequence', 'next_by_code', ['test.sequence'])
for i in range(5):
threading.Thread(target=get_sequence_number).start()
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#215666
Forward-Port-Of: odoo/odoo#210277The Ticket Validation screen in POS has recently been updated. However, this change may break the override defined in the Ticket Validation screen view when installing any of the `l10n_{ar/pe/ec_edi}_pos` modules. This issue occurs if the `point_of_sale` module was installed before the update and you install one of these localization modules after pulling the latest code. To ensure compatibility and prevent the override from failing, we have updated the XPath expression in the `l10n_{ar/pe/ec
Original PR description
The Ticket Validation screen in POS has recently been updated. However, this change may break the override defined in the Ticket Validation screen view when installing any of the `l10n_{ar/pe/ec_edi}_pos` modules. This issue occurs if the `point_of_sale` module was installed before the update and you install one of these localization modules after pulling the latest code.
To ensure compatibility and prevent the override from failing, we have updated the XPath expression in the `l10n_{ar/pe/ec_edi}_pos` modules to make it more resilient to view changes.
Followup of: https://github.com/odoo/odoo/pull/201995/commits/d6f75fc61c54ba8d6726508c78ed91c11ea6b1bd
sentry-6673777020
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#214339[FIX] point_of_sale: avoid 500 internal error pos When requesting an invoice from the portal, if an additional required field is left empty, the user gets a 500 Internal server error. (e.g. fields l10n_mx_edi_fiscal_regime, l10n_mx_edi_usage) Steps to reproduce: - Install POS & l10n_mx_reports - Open a POS session and sell a product without invoicing (and print the ticket) - Close the session - Open a new private window and go to \<url\>/pos/ticket - Enter ticket number, date and uniq
Original PR description
[FIX] point_of_sale: avoid 500 internal error pos When requesting an invoice from the portal, if an additional required field is left empty, the user gets a 500 Internal server error. (e.g. fields l10n_mx_edi_fiscal_regime, l10n_mx_edi_usage) Steps to reproduce: - Install POS & l10n_mx_reports - Open a POS session and sell a product without invoicing (and print the ticket) - Close the session - Open a new private window and go to \<url\>/pos/ticket - Enter ticket number, date and unique code and press "Request invoice" - Fill the form in but leave l10n_mx_edi_fiscal_regime & l10n_mx_edi_usage empty - Press "Get my invoice" Runbot: https://runbot.odoo.com/runbot/bundle/saas-18-2-dump-pos-extra-fields-roto-380043 Forward-Port-Of: odoo/odoo#215828
*: portal, portal_rating, test_mail_full. Before this commit, the chat bot could stop when redirecting to a page where the portal is enabled. Both the portal and live chat modules rely on the discuss store’s `self` field which identifies the authenticated user. However, the portal also supports authentication via a token in the URL, which temporarily identifies the user on a specific thread. Previously, the portal would overwrite the global `self` value, causing inconsistencies for
Original PR description
*: portal, portal_rating, test_mail_full. Before this commit, the chat bot could stop when redirecting to a page where the portal is enabled. Both the portal and live chat modules rely on the discuss store’s `self` field which identifies the authenticated user. However, the portal also supports authentication via a token in the URL, which temporarily identifies the user on a specific thread. Previously, the portal would overwrite the global `self` value, causing inconsistencies for other users of the store such as messages appearing as if sent by another user. Since token authentication is specific to portal threads, it should only affect actions on the granted thread without altering the global user identity. This fix prevents the portal from overwriting the global `self` value and instead returns the thread-specific `portal_partner` field. opw-4722466 Forward-Port-Of: odoo/odoo#212720 Forward-Port-Of: odoo/odoo#211204
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 Description of the issue/feature this PR addresses: Current behavior bef
Original PR description
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 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 Forward-Port-Of: odoo/odoo#214885 Forward-Port-Of: odoo/odoo#214729
<b>Steps to reproduce:</b> 1. Go to Sales > Configuration > Product Categories 2. Select All / Saleable, and set Costing Method to FIFO 3. Go to Products > New 4. Fill in Name , set Track Inventory True and add Cost, then save the product 5. Change the Category to All / Saleable 6. Navigate to Attributes & Variants, add attribute Leg, and add values Steel and Aluminium <b>Issue :</b> - When modifying a product template with FIFO costing by adding multiple attributes, the system may d
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Configuration > Product Categories 2. Select All / Saleable, and set Costing Method to FIFO 3. Go to Products > New 4. Fill in Name , set Track Inventory True and add Cost, then save the product 5. Change the Category to All / Saleable 6. Navigate to Attributes & Variants, add attribute Leg, and add values Steel and Aluminium <b>Issue :</b> - When modifying a product template with FIFO costing by adding multiple attributes, the system may delete and recreate product variants. This causes "missing record" error during stock valuation replenishment, as the code tries to access deleted product variants. <b>Solution :</b> - After calling super().write(vals), the original products recordset may contain deleted records due to variant regeneration. A check was added to verify if the variants still exist, If not, then continues. <b>opw-4741530</b> Forward-Port-Of: odoo/odoo#215394 Forward-Port-Of: odoo/odoo#209513
Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated. This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection. This would lead to a traceback but no functional issue. Forward-Port-Of: odoo/odoo#215995
Original PR description
Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated. This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection. This would lead to a traceback but no functional issue. Forward-Port-Of: odoo/odoo#215995
This commit fixes the non-deterministic `connection considered as lost after failed reconnect attempt` test. The monitoring service does not show the connection as lost when the navigator online property is false which makes this test fail when network is not available. This check makes no sense, it doesn't matter if we lost the connection because of a server/client error or because the network is down. This commit removes this check on the "online" navigator property and fixes this test. fix
Original PR description
This commit fixes the non-deterministic `connection considered as lost after failed reconnect attempt` test. The monitoring service does not show the connection as lost when the navigator online property is false which makes this test fail when network is not available. This check makes no sense, it doesn't matter if we lost the connection because of a server/client error or because the network is down. This commit removes this check on the "online" navigator property and fixes this test. fixes runbot-226892 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 Forward-Port-Of: odoo/odoo#216085
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute function](https://github.com/odoo/enterprise/blob/18.0/l10n_ke_edi_oscu_stock/models/account_move.py#L166) to the `product_id` field on invoice lines. The ORM triggers computes for all items in the chain - irrespective of whether the value was changed or not. Therefore, when the Kenya modules are installed, the `_compute_product_uom_id` function is triggered - which changes
Original PR description
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute…
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute function](https://github.com/odoo/enterprise/blob/18.0/l10n_ke_edi_oscu_stock/models/account_move.py#L166) to the `product_id` field on invoice lines. The ORM triggers computes for all items in the chain - irrespective of whether the value was changed or not. Therefore, when the Kenya modules are installed, the `_compute_product_uom_id` function is triggered - which changes the unit of measure. Solution: Improve the account.move.line's `_compute_product_uom_id` to only change the UoM when necessary. Considered Alternatives: - Whilst the l10n_ke_edi compute functions are not ideal - it was done because there was no PO/Bill matching feature at the time. Ideally these computes should be removed - but that would impact the stable policy and may have knock on effects. - changing the tests would simply hide issues arising from uom's and discounts. runbot-75230 Forward-Port-Of: odoo/odoo#215891
Before this commit, the computation of the exclusion of some attributes based on other selected was going through every attribute to determine if it was excluded or not. This is now done once at the loading of the pos. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213789
Original PR description
Before this commit, the computation of the exclusion of some attributes based on other selected was going through every attribute to determine if it was excluded or not. This is now done once at the loading of the pos. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213789
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting pla
Original PR description
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting plain text inside code blocks preserves indentation using normal spaces, avoiding insertion of `nbsp`. task-4815939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211386
Prior to this commit, when a sale order was created with some service products configured to generate projects at SO confirmation, we would generate an analytic account per project instead of just one for all the generated projects. As a result, we would get redundant analytic accounts, which is not desirable. This is because we were creating the new projects without specifying the analytic account that would be set to it (because we would assume that the project would be first created withou
Original PR description
Prior to this commit, when a sale order was created with some service products configured to generate projects at SO confirmation, we would generate an analytic account per project instead of just one for all the generated projects. As a result, we would get redundant analytic accounts, which is not desirable. This is because we were creating the new projects without specifying the analytic account that would be set to it (because we would assume that the project would be first created without AA, then we would populate it later). The issue is that if `hr_timesheet` is installed, every new project is by default timesheetable, so that it generates an AA automatically at creation of the project (see `create()` method of `hr_timesheet`) To mitigate that, we now specify the analytic account to be used when creating the projects that have to be generated from `_timesheet_create_project()`. version-18.0 task-4854817 Forward-Port-Of: odoo/odoo#215616
Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted. Steps to reproduce: ------------------- * Create a loyatly program and make it sot that is has already expired * Open pos and make an order selecting any customer * Go to the backend and check the loyalty program > Observation: 1 card has been created with 0 points Why the fix: ------------ Not loading the expired programs prevent the creation of loyalty cards.
Original PR description
Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted. Steps to reproduce: ------------------- * Create a loyatly program and make it sot that is has already expired * Open pos and make an order selecting any customer * Go to the backend and check the loyalty program > Observation: 1 card has been created with 0 points Why the fix: ------------ Not loading the expired programs prevent the creation of loyalty cards. Using the same logic as module `sale_loyalty` https://github.com/odoo-dev/odoo/blob/5acb89b8ba9be0e18bca65e26c03f47199fcfb4b/addons/sale_loyalty/models/sale_order.py#L461-L465 opw-4671522 Forward-Port-Of: odoo/odoo#208701 Forward-Port-Of: odoo/odoo#208134
To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load. Task: 4860513 Forward-Port-Of: odoo/odoo#215725 Forward-Port-Of: odoo/odoo#215536
Original PR description
To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load. Task: 4860513 Forward-Port-Of: odoo/odoo#215725 Forward-Port-Of: odoo/odoo#215536
This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one. community pr: https://github.com/odoo/odoo/pull/211443 opw-4751270 Forward-Port-Of: odoo/enterprise#86987
Original PR description
This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one. community pr: https://github.com/odoo/odoo/pull/211443 opw-4751270 Forward-Port-Of: odoo/enterprise#86987
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to 0 > Remove the line - Scan XXX #### > The line appear with multiple sublines #### > If you repeat the two last steps even more sublines will appear ### Cause of the issue: Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache: https://github.com
Original PR description
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to…
### Steps to reproduce:
- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear
### Cause of the issue:
Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.
To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471
opw-4787229
Forward-Port-Of: odoo/enterprise#87654
Forward-Port-Of: odoo/enterprise#87073The tour in `test_worksheet_quality_check` expects the "Select Work Centers" dialog to open automatically on load. This only happens if: - `localStorage` has no previous selection, and - the user has `group_mrp_routings` As seen [Here](https://github.com/odoo-dev/enterprise/blob/df3c6642cae9b40700b0b17e0335cec00ce23d3e/mrp_workorder/static/src/mrp_display/mrp_display.js#L124) in `MrpDisplay.onWillStart()`: `if (localStorage === null && this.group_mrp_routings) { this.to
Original PR description
The tour in `test_worksheet_quality_check` expects the "Select Work Centers" dialog to open automatically on load.
This only happens if:
- `localStorage` has no previous selection, and
- the user has `group_mrp_routings`
As seen [Here](https://github.com/odoo-dev/enterprise/blob/df3c6642cae9b40700b0b17e0335cec00ce23d3e/mrp_workorder/static/src/mrp_display/mrp_display.js#L124) in `MrpDisplay.onWillStart()`:
`if (localStorage === null && this.group_mrp_routings) {
this.toggleWorkcenterDialog(false);
}`
When running with `--without-demo=all`, the admin user does not have this group, so the dialog does not show and the test fails.
We fix this by explicitly assigning the group:
`self.env.ref("base.user_admin").groups_id += self.env.ref('mrp.group_mrp_routings')`
[runbot-161194](https://runbot.odoo.com/odoo/error/161194)
Forward-Port-Of: odoo/enterprise#87891
Forward-Port-Of: odoo/enterprise#87218The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined in `l10n_co_dian` module, and the workflow in the module also depends[[1]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_invoice.py#L9)[[2]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co
Original PR description
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined…
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined in `l10n_co_dian` module, and the workflow in the module also depends[[1]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_invoice.py#L9)[[2]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/product_template.py#L8) on DIAN being installed. Both modules have the same dependency `l10n_co_edi` and are autoinstalled. This can easily break if the user chooses to uninstall the dian module. The module will fail to install if dian is not installed. The uninstall of the dian module will also cause an error if this module is installed. The upgrade will fail if the user has dian uninstalled (edi_mandate is a new module and will try to autoinstall) This fix makes the dependency explicit. Forward-Port-Of: odoo/enterprise#88607
The Ticket Validation screen in POS has recently been updated. However, this change may break the override defined in the Ticket Validation screen view when installing any of the `l10n_{ar/pe/ec_edi}_pos` modules. This issue occurs if the `point_of_sale` module was installed before the update and you install one of these localization modules after pulling the latest code. To ensure compatibility and prevent the override from failing, we have updated the XPath expression in the `l10n_{ar/pe/ec
Original PR description
The Ticket Validation screen in POS has recently been updated. However, this change may break the override defined in the Ticket Validation screen view when installing any of the `l10n_{ar/pe/ec_edi}_pos` modules. This issue occurs if the `point_of_sale` module was installed before the update and you install one of these localization modules after pulling the latest code.
To ensure compatibility and prevent the override from failing, we have updated the XPath expression in the `l10n_{ar/pe/ec_edi}_pos` modules to make it more resilient to view changes.
Followup of: https://github.com/odoo/odoo/pull/201995/commits/d6f75fc61c54ba8d6726508c78ed91c11ea6b1bd
sentry-6673777020
Forward-Port-Of: odoo/enterprise#87729Steps to reproduce - install `industry_fsm_sale_subscription` - go to settings -> enable `recurring task` - create product with following configs : * enable `subscription` * product type : `service` * create on order `task` * project `Field service`  - create a SO with this product - go to `Tasks` smart button - select the task and mark it done - ope
Original PR description
Steps to reproduce
- install `industry_fsm_sale_subscription`
- go to settings -> enable `recurring task`
- create product with following configs :
* enable `subscription`
* product type : `service`
* create on order `task`
* project `Field service`
- create a SO with this product
- go to `Tasks` smart button
- select the task and mark it done
- open the second task, from "recurring tasks" smart button
Obervation: in newly created task `Sales Order Item` is not linked
Issue:
- after this commit odoo/enterprise@be201cd ,sale fields are not copied for fsm task. while this is true for simple tasks, we would require such fields to be copied for recurrence tasks
Fix:
- allow sale fields to be copied for recurring tasks
opw-4875830
Forward-Port-Of: odoo/enterprise#88108When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88566 Forward-Port-Of: odoo/enterprise#88493
Original PR description
When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88566 Forward-Port-Of: odoo/enterprise#88493
- Before this commit we had a traceback appearing when doing the following steps (`pos_blackbox_be` should be installed): 1. Open a POS session 2. Create a new order 3. Add a product to the order 4. Go to "payments" 5. Close the register -> Traceback occurs This was due becasue just before closing the session when using a blackbox, we create a `Clock out` order and unselected the current order see `removeClockOrder()`, then call `showScreen()`. Now inside `showScreen(
Original PR description
- Before this commit we had a traceback appearing when doing the following steps (`pos_blackbox_be` should be installed):
1. Open a POS session
2. Create a new order
3. Add a product to the order
4. Go to "payments"
5. Close the register -> Traceback occurs
This was due becasue just before closing the session when using a blackbox, we create a `Clock out` order and unselected the current order see `removeClockOrder()`, then call `showScreen()`. Now inside `showScreen()` we make sure the current order exists before accessing its payments.
task-id: 4881969
Forward-Port-Of: odoo/enterprise#88047## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch the `datas` field (binary file content). This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch t
Original PR description
## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch…
## Issue
When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`.
### Analysis
The `write` override could unnecessarily fetch the `datas` field (binary file content).
This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch the binary content even when it was not needed.
## Solution
We leverage Python's boolean short-circuiting to ensure that this behavior is avoided.
### Benchmarks
Profiling peak memory consumption when moving 8 documents (66 Mb each) to the trash:
| Before | After | % |
|------------|------------| --- |
| 1.3 GiB | 96 Mb | - ~93% |
Query count when unlinking account.move (using Runbot data):
| Before | After |
|------------|------------|
| 66 | 72 |
(we may avoid these additional queries by prefetching the fields beforehand, let me know your thoughts)
```
[0.564 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3398)
[0.713 ms] query: UPDATE "ir_attachment"
SET "res_id" = "__tmp"."res_id"::int4, "res_model" = "__tmp"."res_model"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (3398, 117, 'documents.document', '2025-06-17T15:24:12.867699'::timestamp, 22)) AS "__tmp"("id", "res_id", "res_model", "write_date", "write_uid")
WHERE "ir_attachment"."id" = "__tmp"."id"
[0.305 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."res_model", "ir_attachment"."res_id", "ir_attachment"."res_field", "ir_attachment"."public", "ir_attachment"."create_uid" FROM "ir_attachment" WHERE ("ir_attachment"."id" IN (3397))
[0.666 ms] query: SELECT "account_move"."id" FROM "account_move" WHERE ("account_move"."id" IN (255)) AND ("account_move"."company_id" IN (10)) ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
[0.436 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3397)
[0.436 ms] query: SELECT "documents_document"."id", "documents_document"."attachment_id", "documents_document"."active" FROM "documents_document" WHERE ("documents_document"."attachment_id" IN (3397)) ORDER BY "documents_document"."id" DESC
```
### References
opw-4552436
Memory flamegraphs available on the ticket
Forward-Port-Of: odoo/enterprise#88180
Forward-Port-Of: odoo/enterprise#85020When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
Original PR description
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978