Friday, May 23, 2025
40 changes · saas-18.3
Enhancements to existing features
Printer names now clearly show when a device is connected by USB. This helps users configuring Point of Sale choose the right printer more quickly and avoid selecting the wrong device.
Original PR description
This PR adds "[USB]" to the printer name to help the user who configures his PoS easily choose the usb printer if needed 
Partner display names will no longer include VAT numbers in formatted views. This makes customer and vendor names cleaner and easier to read in everyday business workflows.
Original PR description
TASK-ID: 4794215 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
Resolved issues and error corrections
This fix restores Spanish Canary Islands withholding tax entries that were accidentally left out during a previous tax file reorganization. It ensures companies using the Canary Islands localization keep the expected tax mappings for correct accounting and reporting.
Original PR description
In commit https://github.com/odoo/odoo/commit/8b539c1f303f1b49916c29190c11dcf2cab57d2c, the withholding taxes were moved from the common tax file to the mainland tax file, but the canary islands was skipped. This brings back the Withholding taxes that were referenced in the old tax mapping. Task-4752335
Miscellaneous changes
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display…
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 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#211099
This update adds test coverage for link editing behavior when the URL field is empty. It helps ensure users do not accidentally create links, existing links are removed correctly when cleared, and the editor keeps the popover open when more input is needed.
Original PR description
Added missing test cases not included in commit [1]. - Clicking outside the link popover should close the link popover without creating a link when URL is empty. - After clearing the link URL, clicking outside the popover should remove the existing link. - Pressing Enter inside the popover with an empty URL should not close the link popover. [1]: https://github.com/odoo/odoo/commit/8c49168b0a19853b88078462f8d61863ddb8c979
A missing test customer named Azure is now created before the sales product configurator test runs. This prevents an automated test from failing because expected customer data was unavailable, improving reliability of the test suite.
Original PR description
The test test_product_attribute_multi_type was failing due to the UI tour expecting a partner named "Azure" to appear in an autocomplete dropdown. However, this customer was not created as part of the test setup, causing the selector ul.ui-autocomplete > li > a:contains("Azure") to timeout.
This change introduces the creation of the "Azure" partner in the test environment before running the tour, ensuring the step that selects the customer can succeed.
build_error-161723Users can now archive or restore partner grades directly from the form view, instead of needing to switch to the list view. This makes managing partner grade records more consistent and convenient.
Original PR description
Before this commit, it was not possible to archive a partner grade from the form view, only from the list view. This commit adds this possibility.
**Steps to reproduce:** 1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` . 2. install website module. **Issue:** Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload. **Reason:** The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.ac
Original PR description
**Steps to reproduce:** 1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` . 2. install website module. **Issue:** Users are incorrectly redirected to the…
**Steps to reproduce:** 1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` . 2. install website module. **Issue:** Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload. **Reason:** The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.act_url, which triggered a full page reload, ensuring the server route executed. From Odoo 16 onwards, this action is removed, and a direct client action is attached. Within `configurator.js`, navigation is now handled using the `history.pushState` method which replace the current url and does not trigger a reload. As a result, even when navigating to the configurator route, the server route is not executed, leading to incorrect redirection. **Fix:** Added a check in configurator.js to verify the configurator status. If it is true, the user is redirected to the website page instead of the configurator. Otherwise, the normal configurator flow continues. **Key Changes:** 1. In configurator_init, added a check: if configurator_done is True, set the default theme using button_choose_theme and store its result (a dict containing the next action to execute) as redirect_url. 2. In the Configurator component, added redirect_url to the store, and inside the onWillStart method, checked if redirect_url exists. If it does, redirect to the home screen using doAction. This PR ensures the correct redirection behavior when users follow the Industries installation flow. task-4555467 Forward-Port-Of: odoo/odoo#197593
The rename in the chat window as well as in discuss is not working for livechat, this commit is fixing the issue. The name should now be visible by all operators but not to visitors task-4431259 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#210634 Forward-Port-Of: odoo/odoo#202306
Original PR description
The rename in the chat window as well as in discuss is not working for livechat, this commit is fixing the issue. The name should now be visible by all operators but not to visitors task-4431259 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#210634 Forward-Port-Of: odoo/odoo#202306
**Problem:** When changing the price type of a Discount pricelist rule to "formula" and going back to the original price type "discount" the rule does not take into account the base pricelist anymore and uses the list price of the product to compute the discount **Steps to reproduce:** - Navigate to Sales/Products/Pricelists - Create a new pricelist, click on Add a line - In "Price Type" select Fixed Price and set a Fixed Price of 10 - Save and Close > create a second new price list
Original PR description
**Problem:** When changing the price type of a Discount pricelist rule to "formula" and going back to the original price type "discount" the rule does not take into account the base pricelist anymore…
**Problem:** When changing the price type of a Discount pricelist rule to "formula" and going back to the original price type "discount" the rule does not take into account the base pricelist anymore and uses the list price of the product to compute the discount **Steps to reproduce:** - Navigate to Sales/Products/Pricelists - Create a new pricelist, click on Add a line - In "Price Type" select Fixed Price and set a Fixed Price of 10 - Save and Close > create a second new price list - Click on "Add a line" and select a Price Type Discount - Set a 50% discount percent and select your first pricelist as the base price (next to "on") - Save and Close > save the form - Open the rule again and change the Price Type to formula - Change the Price Type back to Discount and set a discount percentage of 50% again - Save and Close - Create a new quotation with a product and select the second pricelist you created > click on Update Prices **Current behavior:** Amount is 50% of the price of the product **Expected behavior:** It should be 50% of 10 because our second pricelist is based on the first one which has a fixed price of 10 **Cause of the issue:** when _onchange_compute_price is triggeredwhen going back to discount value, base will be set to list_price https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/product/models/product_pricelist_item.py#L334-L342 because of this, the base price will not be computed based on the base pricelist https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/product/models/product_pricelist_item.py#L580-L583 **fix:** By resetting the base_pricelist_id, it's now visible to the user on the form that the computation is no more based on a pricelist. If the user enters a pricelist, the correct value will be computerd for base and base_pricelist_id at that time. opw-4757951 Forward-Port-Of: odoo/odoo#208899
Before this PR: In A4 statement format reports, the folder layout was overwriting header information, causing important header details to be obscured in the printed output. After this PR: Fixed folder layout rendering to preserve header information in A4 statement format reports, ensuring all header details are properly displayed. Solution: Adapted the A4 statement format implementation to work with the new report margin approach that replaces paperformat spacing with $o-default-report-
Original PR description
Before this PR: In A4 statement format reports, the folder layout was overwriting header information, causing important header details to be obscured in the printed output. After this PR: Fixed folder layout rendering to preserve header information in A4 statement format reports, ensuring all header details are properly displayed. Solution: Adapted the A4 statement format implementation to work with the new report margin approach that replaces paperformat spacing with $o-default-report-margins CSS variable, preventing layout conflicts that were causing header overwrites. OPW-4741128 Forward-Port-Of: odoo/odoo#211168
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains f
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains formatted using English conventions (e.g. "20.5%" instead of "20,5 %" in French or German). <b>Cause:</b> - This happens because the amount is inserted as a raw float without localization. <b>Solution:</b> - This fix uses `formatLang()` with the correct context to format the percentage amount according to the partner's language (i.e., proper decimal separator). <b>opw-4743326</b> Forward-Port-Of: odoo/odoo#211047 Forward-Port-Of: odoo/odoo#210570
**Issue:** when defining the form for kanban view, required attribute is not added making it true by default **steps to reproduce:** 1. install timesheets app 2. from projects app, open a task with timesheet in mobile view 3. click on `Add` button present in timesheet page 4. try to save the timesheet without 'Description' observation: Form not saved with notification "invalid field: Description" **solution:** Add relevant `required` and `readonly` property to the field this ma
Original PR description
**Issue:** when defining the form for kanban view, required attribute is not added making it true by default **steps to reproduce:** 1. install timesheets app 2. from projects app, open a task with timesheet in mobile view 3. click on `Add` button present in timesheet page 4. try to save the timesheet without 'Description' observation: Form not saved with notification "invalid field: Description" **solution:** Add relevant `required` and `readonly` property to the field this makes the behavior same across each view [see list view](https://github.com/odoo/odoo/blob/17.0/addons/hr_timesheet/views/project_task_views.xml#L41-L54) note: 1. techincal name of Description field is 'name' 2. `readonly` attribute is added to make the behavior same across each view opw-4725348 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr ; Forward-Port-Of: odoo/odoo#210957 Forward-Port-Of: odoo/odoo#209630
Currently, an error produced on creating a new server action if the user selects a field in the **Action Details** without specifying a model. **Steps to Reproduce:** 1) Navigate to `Settings>Technical>Actions>Server Action`. 2) Click on `New Server Action`. 3) Select the field in Action Details without selecting the Model. 4) Observe the Error. **Error:** KeyError: False **Root Cause:** - The error occurs because the system attempts to access `self.model_id.model` at [1] without
Original PR description
Currently, an error produced on creating a new server action if the user selects a field in the **Action Details** without specifying a model. **Steps to Reproduce:** 1) Navigate to `Settings>Technical>Actions>Server Action`. 2) Click on `New Server Action`. 3) Select the field in Action Details without selecting the Model. 4) Observe the Error. **Error:** KeyError: False **Root Cause:** - The error occurs because the system attempts to access `self.model_id.model` at [1] without verifying it exists or not, which leads to a `KeyError`. [1]-https://github.com/odoo/odoo/blob/4fa26954bbb5f6a9c9679b7d44ec2261057da29e/odoo/addons/base/models/ir_actions.py#L820 **Solution:** - This commit prevents errors by adding checks to ensure model_id and model_id.model are present before accessing them. Sentry-6591474450 Forward-Port-Of: odoo/odoo#209208
Speed up queries like in _check_uom_not_in_invoice Before: https://explain.dalibo.com/plan/dh442bag02518830 After: https://explain.dalibo.com/plan/db2ef078c8dd4ac0 From 12 seconds to .3ms 10 Millions account_ move_ line in the database 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#2
Original PR description
Speed up queries like in _check_uom_not_in_invoice Before: https://explain.dalibo.com/plan/dh442bag02518830 After: https://explain.dalibo.com/plan/db2ef078c8dd4ac0 From 12 seconds to .3ms 10 Millions account_ move_ line in the database 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#210981 Forward-Port-Of: odoo/odoo#208992
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211013 For
Original PR description
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211013 Forward-Port-Of: odoo/odoo#210768
Before this patch, it was impossible to resequence vendor bills if already sent to SII/tbai. However, it is required to be able to resequence them, and the move name isn't sent anymore since https://github.com/odoo/odoo/pull/195113 was merged. Thus, here I'm lifting that constraint to allow accountants do the resequencing. @moduon MT-8728 OPW-4567144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209305 Forward-
Original PR description
Before this patch, it was impossible to resequence vendor bills if already sent to SII/tbai. However, it is required to be able to resequence them, and the move name isn't sent anymore since https://github.com/odoo/odoo/pull/195113 was merged. Thus, here I'm lifting that constraint to allow accountants do the resequencing. @moduon MT-8728 OPW-4567144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209305 Forward-Port-Of: odoo/odoo#197284
Abandoned cart emails would send twice because the email values for the abandoned cart template would include the partner on the record already, but we were also including the partner email in the email values. Adjusted the email values to be empty when there is already a recipient found on the template. opw-4684534 Forward-Port-Of: odoo/odoo#210586 Forward-Port-Of: odoo/odoo#206158
Original PR description
Abandoned cart emails would send twice because the email values for the abandoned cart template would include the partner on the record already, but we were also including the partner email in the email values. Adjusted the email values to be empty when there is already a recipient found on the template. opw-4684534 Forward-Port-Of: odoo/odoo#210586 Forward-Port-Of: odoo/odoo#206158
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually receiv
Original PR description
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually received in May 2025 results in non-compliance. References Official: https://www.agenziaentrate.gov.it/portale/documents/20143/451259/Guida_compilazione-FE-Esterometro-V_1.9_2024-03-05.pdf/67fe4c2d-1174-e8de-f1ee-cea77b7f5203 , page 14 Extra: https://www.fiscoetasse.com/approfondimenti/16247-reverse-charge-interno-e-reverse-charge-esterno.html , entry 5  Forward-Port-Of: odoo/odoo#210342
Current behavior before PR: When selecting an even row by clicking on it (if it's not opening a record) or by selecting the checkbox and then unchecking it, it will highlight this row. This is only working on even rows but not on odd rows. Desired behavior after PR is merged: This fix aims to make even and odd rows work correctly by being highlighted. task-4809597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#
Original PR description
Current behavior before PR: When selecting an even row by clicking on it (if it's not opening a record) or by selecting the checkbox and then unchecking it, it will highlight this row. This is only working on even rows but not on odd rows. Desired behavior after PR is merged: This fix aims to make even and odd rows work correctly by being highlighted. task-4809597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210987
Before this commit, draft orders were incorrectly synced to the server in non-restaurant PoS, causing several issues. This commit ensures that draft orders are only synced when the POS is in restaurant mode, preventing unintended behavior. opw-4624604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208238 Forward-Port-Of: odoo/odoo#200211
Original PR description
Before this commit, draft orders were incorrectly synced to the server in non-restaurant PoS, causing several issues. This commit ensures that draft orders are only synced when the POS is in restaurant mode, preventing unintended behavior. opw-4624604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208238 Forward-Port-Of: odoo/odoo#200211
- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. - Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account. - Make a purchase using the `"demo"` payment method with the new partner. The ge
Original PR description
- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. -…
- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. - Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account. - Make a purchase using the `"demo"` payment method with the new partner. The generated invoice and its corresponding journal entry do not share the same `account_id` (Account Receivable). The invoice uses the `account_id` computed in `_compute_account_id` of `account.move.line`, which is not necessarily the same as the `account_id` set on the partner. After this commit, the payment uses the same `account_id` as the related invoice, (same as _create_payment_vals_from_wizard) avoiding any discrepancy. opw-4669927 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#209318 Forward-Port-Of: odoo/odoo#204489
Forward-Port-Of: odoo/odoo#210625
Original PR description
Forward-Port-Of: odoo/odoo#210625
Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user
Original PR description
Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user action is needed. Task Id: 4797098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210071
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#211068 Forward-Port-Of: odoo/odoo#210279
Original PR description
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#211068 Forward-Port-Of: odoo/odoo#210279
**Issue:** When sharing a project, the project manager was accidentally removed from the project's followers **Steps to reproduce:** - create a new project. - in the project settings, click “Share Project”. - add a collaborator and share. The project manager disappears from the follower list, leaving only the new collaborator. opw-4764035 Forward-Port-Of: odoo/odoo#208753
Original PR description
**Issue:** When sharing a project, the project manager was accidentally removed from the project's followers **Steps to reproduce:** - create a new project. - in the project settings, click “Share Project”. - add a collaborator and share. The project manager disappears from the follower list, leaving only the new collaborator. opw-4764035 Forward-Port-Of: odoo/odoo#208753
Alays use a freeze_time when adding time-based tests. Runbot-223332 Forward-Port-Of: odoo/odoo#210979
Original PR description
Alays use a freeze_time when adding time-based tests. Runbot-223332 Forward-Port-Of: odoo/odoo#210979
Steps to reproduce: ------------------- 1. Install `whatsapp_pos` 2. In a PoS shop, select a partner with a valid phone, select a product, and invoice it. Observation: ------------ on the receipt screen, we can't send the receipt via whatsapp, since the phone input is empty, and hence, the send via whatsapp button is disabled. Reason: ------- Commit a4b8a589c4007cd0385b253a58b1b87baf3905b8 removed the `mobile` field from `res.partner` for simplicity, however, we have forgot to updat
Original PR description
Steps to reproduce: ------------------- 1. Install `whatsapp_pos` 2. In a PoS shop, select a partner with a valid phone, select a product, and invoice it. Observation: ------------ on the receipt screen, we can't send the receipt via whatsapp, since the phone input is empty, and hence, the send via whatsapp button is disabled. Reason: ------- Commit a4b8a589c4007cd0385b253a58b1b87baf3905b8 removed the `mobile` field from `res.partner` for simplicity, however, we have forgot to update the usage of the `moblie` field in `point_of_sale`. Fix: ---- Swap `mobile` for `phone`. opw-4792841 Forward-Port-Of: odoo/odoo#210939
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is
Original PR description
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is possible to delete a section or note line on a confirmed purchase order. --- opw-4744367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210760
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Original PR description
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 Forward-Port-Of: odoo/enterprise#86119
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB. In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting ind
Original PR description
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the…
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.
In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.
Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count |
|----------|
| 60669759 |
+----------+
```
The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.
Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
-> Subquery Scan on "*SELECT*" (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
-> Result (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
-> ProjectSet (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
-> Merge Left Join (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
-> Index Scan using account_analytic_line__move_line_id_index on account_analytic_line (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
Filter: (general_account_id IS NOT NULL)
Rows Removed by Filter: 136994
-> Materialize (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
Functions: 78
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```
Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
-> Subquery Scan on account_move_line (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
Rows Removed by Filter: 2617642
-> Gather (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Result (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
-> ProjectSet (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
-> Parallel Hash Join (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
-> Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1 (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
-> Parallel Hash (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
Buckets: 1048576 Batches: 1 Memory Usage: 54880kB
-> Parallel Index Scan using account_analytic_line__date_index on account_analytic_line (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
Rows Removed by Filter: 57954
-> Hash (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Index Scan using account_account__account_type_index on account_account account_move_line__account_id (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
Functions: 51
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```
OPW-4782916
Forward-Port-Of: odoo/enterprise#85942Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817 Forward-Port-Of: odoo/enterprise#81253
Original PR description
Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817 Forward-Port-Of: odoo/enterprise#81253
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86139 Forward-Port-Of: odoo/enterprise#85898
Original PR description
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86139 Forward-Port-Of: odoo/enterprise#85898
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Original PR description
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Before this commit, the code checks if `this.connectorDragState.draging` if truly before using the split tool because we don't want to execute that if the user is currently dragging a planning slot. The problem is `draging` attribute does not exist in `connectorDragState`, it should be `dragging` instead. This commit fixes the typo to correctly check if the slot is dragging before doing the split tool or not. Forward-Port-Of: odoo/enterprise#85946
Original PR description
Before this commit, the code checks if `this.connectorDragState.draging` if truly before using the split tool because we don't want to execute that if the user is currently dragging a planning slot. The problem is `draging` attribute does not exist in `connectorDragState`, it should be `dragging` instead. This commit fixes the typo to correctly check if the slot is dragging before doing the split tool or not. Forward-Port-Of: odoo/enterprise#85946
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do), Expected behaviour
Original PR description
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the…
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do), Expected behaviour: the quote calculator spreadsheet is duplicated for the new quote with the same values. Implementation note: Why not just `copy=True` on field `spreadsheet_ids`? Because the spreadsheet should be copied, but not only! The `spreadsheet.revision` linked to the spreadsheet also need to be copied. If they are not copied, revisions which are not part of the last snapshot will be lost on the new spreadsheet record and it won't lead to the same spreadsheet data. Task: 4801418 Forward-Port-Of: odoo/enterprise#86017 Forward-Port-Of: odoo/enterprise#85746
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required. Forward-Port-Of: odoo/enterprise#85980
Original PR description
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required. Forward-Port-Of: odoo/enterprise#85980
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference ------
Original PR description
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference --------- opw-4743742 Forward-Port-Of: odoo/enterprise#86099 Forward-Port-Of: odoo/enterprise#85974
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checke
Original PR description
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checked in the _generate_lot() which is called on adding product tracked by lot. opw-4648542 opw-4646960 Forward-Port-Of: odoo/enterprise#85867 Forward-Port-Of: odoo/enterprise#82341