Friday, April 19, 2024
54 changes · saas-17.2
Resolved issues and error corrections
This fixes cases where the browser tab could show the page URL instead of a clear product name when a screen had no display name. Users will now see a consistent "Odoo" title, such as in the home menu, improving polish and reducing confusion.
Original PR description
Commit [1] removed the "Odoo -" prefix in the title of the backend. However, it may happen that an action doesn't have a display name. In that case, we should fallback on "Odoo", because if we don't, the url is displayed as title. This could be reproduced before this fix in the home menu. [1] f3e809a6b7076065e46e466019be4b6b0325371c 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
Sales orders no longer crash when a user temporarily clears the company field before selecting a customer. The system now uses a fallback currency so editing can continue smoothly, even though the company remains required before saving.
Original PR description
Issue ----- When emptying the company field on a SO, a traceback happens if there's no customer set as there's no currency provided to _prepare_tax_totals (changed in 17.2 by https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f). Even if the company is a required field on a SO, the onchange will still be triggered if it is set to False, which causes the issue here. Fix ----- Provide a fallback currency in case the user deletes the company from the SO. opw-3859440
The home menu now shows a clear “Home” title in the browser instead of falling back to the page URL. This avoids confusion for users and restores a cleaner navigation experience after a previous title format change.
Original PR description
Commit [1] removed the "Odoo -" prefix in the title of the backend. As a consequence, there was no title left in the home menu, and the url was displayed instead. This commit defines "Home" as title of the HomeMenuAction. [1] odoo/odoo@f3e809a6b7076065e46e466019be4b6b0325371c
The Knowledge command palette no longer raises an error in developer mode when showing Knowledge-related commands. This keeps the Knowledge experience stable and makes the command setup more resilient to future updates.
Original PR description
When using the command palette of Knowledge in dev mode, the system raises the following exception: `Invalid props for component 'Knowledge404Command': unknown key 'name', unknown key 'searchValue', unknown key 'executeCommand', unknown key 'slots'.` To fix the issue, `Knowledge404Command` and `KnowledgeCommand` will extend `DefaultCommandItem` and its props, ensuring that the required props will be maintained in future updates. task-3862285
Miscellaneous changes
Current behavior: When entering a lot name that doesn't exist in the PoS, the lot is being created. But the lot is not being assigned to the stock move line. Steps to reproduce: - Create a product with tracking by lot - Open PoS and make an order for this product - Enter a lot name that doesn't exist - Validate the order - Close the session - Go to the order picking in the inventory app - The lot is not assigned to the stock move line opw-3710125 --- I confirm I have signed the C
Original PR description
Current behavior: When entering a lot name that doesn't exist in the PoS, the lot is being created. But the lot is not being assigned to the stock move line. Steps to reproduce: - Create a product with tracking by lot - Open PoS and make an order for this product - Enter a lot name that doesn't exist - Validate the order - Close the session - Go to the order picking in the inventory app - The lot is not assigned to the stock move line opw-3710125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160533
Every string we use in HTML that holds user or external system input has to be escaped for compliance. Forward-Port-Of: odoo/odoo#162463
Original PR description
Every string we use in HTML that holds user or external system input has to be escaped for compliance. Forward-Port-Of: odoo/odoo#162463
Fix errors in some of the spanish invoice_labels for withholding taxes. Thanks to @AlmustafaNET #147867 Forward-Port-Of: odoo/odoo#162447
Original PR description
Fix errors in some of the spanish invoice_labels for withholding taxes. Thanks to @AlmustafaNET #147867 Forward-Port-Of: odoo/odoo#162447
Steps to reproduce: - Install Contacts, Sales, Accounting and l10n_de - Configure DIN5008 as document layout in the settings - Install German language - Create a contact with German as language (e.g. German Contact) - Create a SO with German Contact as customer - Create an invoice from the SO - Add a Customer Reference ("Other Info" tab) on the invoice - Confirm and print the invoice Issue: On the printed invoice, both "Source" (i.e. the SO) and "Reference" (i.e. Customer Reference)
Original PR description
Steps to reproduce:
- Install Contacts, Sales, Accounting and l10n_de
- Configure DIN5008 as document layout in the settings
- Install German language
- Create a contact with German as language (e.g. German Contact)
- Create a SO with German Contact as customer
- Create an invoice from the SO
- Add a Customer Reference ("Other Info" tab) on the invoice
- Confirm and print the invoice
Issue:
On the printed invoice, both "Source" (i.e. the SO) and "Reference" (i.e. Customer Reference) labels are translated with the same German term: "Referenz".
Solution:
Translation team suggested to use "Verweis" to translate "Source" in German.
opw-3821069
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#162559
Forward-Port-Of: odoo/odoo#162381When changing `groupby` we want to also update `user_groupby` to avoid raising `_validate_groupby_no_child` or `_validate_formula`. It can always be set independently after. Detected while upgrading `account_financial_report_it_sp` because `<field name="groupby" eval="False"/>` was set in the data but `user_groupby` was never updated. (but the constraint was triggered because of the write) Note that the constraint was not fired when needed either. Forward-Port-Of: odoo/odoo#162584 Forward
Original PR description
When changing `groupby` we want to also update `user_groupby` to avoid raising `_validate_groupby_no_child` or `_validate_formula`. It can always be set independently after. Detected while upgrading `account_financial_report_it_sp` because `<field name="groupby" eval="False"/>` was set in the data but `user_groupby` was never updated. (but the constraint was triggered because of the write) Note that the constraint was not fired when needed either. Forward-Port-Of: odoo/odoo#162584 Forward-Port-Of: odoo/odoo#160301
### Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the Product and with any quantity and click on Confirm (not Validate) 5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm 6. Validate the Transfer 7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button 8. The reserved quant
Original PR description
### Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the…
### Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the Product and with any quantity and click on Confirm (not Validate) 5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm 6. Validate the Transfer 7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button 8. The reserved quantity is not null ### Explanation: When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes: - In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards. https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61 When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`. https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422 (e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`) - There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`. (e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`) ### Suggested fix: The fix is made to be as simple as possible, the two conditions will be reduced to simple assignations: - The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called. - The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute. To make everything uniform, there will be no exception where `stock.move.line.quantity_product_uom` is used. opw-3798046 Forward-Port-Of: odoo/odoo#162380 Forward-Port-Of: odoo/odoo#160656
Steps to reproduce ================== - Create two new storable products tracked by USN - Create a new RFQ with one of the created product - Confirm the order - Open the receipt - Add a new line with the other product - Click on the open move button in the new line - Add a new SN - Save & close => Cannot read properties of undefined (reading 'resId') Cause of the issue ================== When calling openRecord, if the record is dirty, it is saved before proceeding. After
Original PR description
Steps to reproduce ================== - Create two new storable products tracked by USN - Create a new RFQ with one of the created product - Confirm the order - Open the receipt - Add a new line with the other product - Click on the open move button in the new line - Add a new SN - Save & close => Cannot read properties of undefined (reading 'resId') Cause of the issue ================== When calling openRecord, if the record is dirty, it is saved before proceeding. After saving, we call super.openRecord with the old record. Since that record is no longer linked to the root record (the stock.picking), when we try to save it, it won't match an existing id. Solution ======== If the record is new, we don't save as there would be no way of knowing which of the returned line would come from this one. If we are opening an existing record, we find the new datapoint by matching it's ID. opw-3777615 Forward-Port-Of: odoo/odoo#162425
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#159860
Original PR description
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#159860
When a portal user is created (e.g. through the `auth_signup` module), an unnecessary write is done on the `write_date` of the default digest. This `write` is unnecessary since a portal user is never subscribed to the default digest. In case of a high signup frequency, it can cause concurrent transaction errors. We avoid writing if no internal user is being created. Forward-Port-Of: odoo/odoo#162230
Original PR description
When a portal user is created (e.g. through the `auth_signup` module), an unnecessary write is done on the `write_date` of the default digest. This `write` is unnecessary since a portal user is never subscribed to the default digest. In case of a high signup frequency, it can cause concurrent transaction errors. We avoid writing if no internal user is being created. Forward-Port-Of: odoo/odoo#162230
Issue ----- The activities summaries displayed by the misc. operations view in the accounting app take up the entire screen and span across the card if the activity summary is too long. Steps ----- - Open the Accounting App. - Create a new entry from 'Miscellaneous Operations'. - Add an activity with a long summary. - Go back the dashboard. The summary will try to span the entire width. Cause ----- The activities are displayed with a field tag in the kanban view. The
Original PR description
Issue ----- The activities summaries displayed by the misc. operations view in the accounting app take up the entire screen and span across the card if the activity summary is too long. Steps ----- - Open the Accounting App. - Create a new entry from 'Miscellaneous Operations'. - Add an activity with a long summary. - Go back the dashboard. The summary will try to span the entire width. Cause ----- The activities are displayed with a field tag in the kanban view. The field tag refers to the activities js component as a widget. Due the use of a widget attribute, the template generates a div with class: "o_field_widget". This class is defined to have a css "display" attribe with a default value of "inline-block". Using "inline-block" causes the activity row to take up the whole width. opw-3839992 Forward-Port-Of: odoo/odoo#160167
Actually if a server is not configured we can click on it and we are redirect to not reachable page With this commit it is not possible to click if server is not configured 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#162372
Original PR description
Actually if a server is not configured we can click on it and we are redirect to not reachable page With this commit it is not possible to click if server is not configured 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#162372
When the iot run without server we display an certificate error. This error is useless because we can't get a certificate without server. Some customer a worry about this error With this commit we hide this comment if we not connected to a Odoo server 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-
Original PR description
When the iot run without server we display an certificate error. This error is useless because we can't get a certificate without server. Some customer a worry about this error With this commit we hide this comment if we not connected to a Odoo server 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#162371
Currently restarts of the odoo server do not happen at the end of the installation of all components. The devices are therefore not detected. With this commit we restart the server when all the components have been installed 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#162362
Original PR description
Currently restarts of the odoo server do not happen at the end of the installation of all components. The devices are therefore not detected. With this commit we restart the server when all the components have been installed 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#162362
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#162022
Original PR description
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#162022
Steps to reproduce: - Set warehouse to two-steps reception - Create a BoM using a MTO (buy) component - Create a MO for 2 units of that BoM - Produce 1 and create a backorder - Open the Overview Issue: When there is a backorder (or if the MO is splitted), then when browsing the dests through `_rollup_move_dests()`, at some point it will branch into two differents path, related to each backorders. This will raise a traceback, as we only expected a single MO at that point. To avoid thi
Original PR description
Steps to reproduce: - Set warehouse to two-steps reception - Create a BoM using a MTO (buy) component - Create a MO for 2 units of that BoM - Produce 1 and create a backorder - Open the Overview Issue: When there is a backorder (or if the MO is splitted), then when browsing the dests through `_rollup_move_dests()`, at some point it will branch into two differents path, related to each backorders. This will raise a traceback, as we only expected a single MO at that point. To avoid this, we made the `_rollup_move_dests()` method batchable, so we can fetch all moves linked to a manufacturing order in a single call, avoiding this issue. Note: For consistency sake, updated the `_rollup_move_origs()` method to be batchable as well, to avoid confusion when using one or the other. opw-3849252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161790 Forward-Port-Of: odoo/odoo#161537
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#161279 Forward-Port-Of: odoo/odoo#160968
Original PR description
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#161279 Forward-Port-Of: odoo/odoo#160968
Steps: - Install sale apps. - Upload a header file from settings with xyz.pdf for example. Issue: - Header/Footer file is not updated according to uploaded file name. Cause: - Header/Footer file name in setting is related and readonly is should not be readonly in order to update header file name. Fix: - Make settings header/footer file not readonly to set proper updated file names. task-3620555 Forward-Port-Of: odoo/odoo#152007
Original PR description
Steps: - Install sale apps. - Upload a header file from settings with xyz.pdf for example. Issue: - Header/Footer file is not updated according to uploaded file name. Cause: - Header/Footer file name in setting is related and readonly is should not be readonly in order to update header file name. Fix: - Make settings header/footer file not readonly to set proper updated file names. task-3620555 Forward-Port-Of: odoo/odoo#152007
Current behavior: When generating a sale report for multiple pos sessions, the payment name is not clear which session it belongs to. Steps to reproduce: - Open PoS and make some sales - Close the session, and do the first step again. - Go in reporting and generate the report for a period that includes the two sessions. - In the payments table you will see the payment name, but you won't know which session it belongs to. opw-3684937 --- I confirm I have signed the CLA and read the P
Original PR description
Current behavior: When generating a sale report for multiple pos sessions, the payment name is not clear which session it belongs to. Steps to reproduce: - Open PoS and make some sales - Close the session, and do the first step again. - Go in reporting and generate the report for a period that includes the two sessions. - In the payments table you will see the payment name, but you won't know which session it belongs to. opw-3684937 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160369
Problem: When we are in the form view of a product variant, the smart button "Extra Price" shows the number of pricelists for this variant including the archived ones Steps to reproduce: - Install "Sales" app and activate the pricelists - Create a product and some variants - Create at least one pricelist for a variant - Archive at least one of these pricelist - Go on the form view of the variant and take a look at the smart button which shows the number of pricelists including the archi
Original PR description
Problem: When we are in the form view of a product variant, the smart button "Extra Price" shows the number of pricelists for this variant including the archived ones Steps to reproduce: - Install "Sales" app and activate the pricelists - Create a product and some variants - Create at least one pricelist for a variant - Archive at least one of these pricelist - Go on the form view of the variant and take a look at the smart button which shows the number of pricelists including the archived ones Cause: The domain that filters the pricelists doesn't take in consideration whether the pricelist is active opw-3836973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160876
Some parts of the translation were missing and Romanian isn't available as a language in Transifex for this version. Therefore we add it in now. English grammar mistakes of original string are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162418
Original PR description
Some parts of the translation were missing and Romanian isn't available as a language in Transifex for this version. Therefore we add it in now. English grammar mistakes of original string are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162418
**Steps to reproduce:** 1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024) and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024) 2- Go to Time off module and select a date in the second allocation's period 3- Click on the Time off type dropdown menu 4- You will see the first allocation displayed not the second one **Current behavior before PR:** The display name of some leaves gets computed in a wrong way. This is happening because aft
Original PR description
**Steps to reproduce:** 1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024) and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024) 2- Go to Time off module…
**Steps to reproduce:** 1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024) and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024) 2- Go to Time off module and select a date in the second allocation's period 3- Click on the Time off type dropdown menu 4- You will see the first allocation displayed not the second one **Current behavior before PR:** The display name of some leaves gets computed in a wrong way. This is happening because after fetching the right allocation we compute the display name but this time we don't have the 'default_date_from' in context so since it became one of the fields that triggers '_compute_leaves' https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219 we compute the leaves once again but the target_date will be none and it will get assigned with today's date in 'get_allocation_data' https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381 **Desired behavior after PR is merged:** This has been solved by saving the date attribute in the context with another name as when computing the display_name we call sudo so clean_context() removes the 'default_' context keys. Now when it gets removed we are going to have the same value but with another name. opw-3797696 Forward-Port-Of: odoo/odoo#159917
Steps to reproduice: -go to myprofile with hr installed -go to resume page -> skills title is duplicated Reason: The no_label attribute is set to True but the widget will still display a label. Expected behavior: The label should only be displayed once Fix: Remove the effectless no_label attribute and remove the separator task: 3815381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158051
Original PR description
Steps to reproduice: -go to myprofile with hr installed -go to resume page -> skills title is duplicated Reason: The no_label attribute is set to True but the widget will still display a label. Expected behavior: The label should only be displayed once Fix: Remove the effectless no_label attribute and remove the separator task: 3815381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158051
**Current behavior:** Adding an attachment to a mail template record associated with the survey invite wizard will not cause the attachment to populate the relevant field when actually sending a new survey invite email. **Expected behavior:** The attachments linked in the email template which is used by the survey invite wizard will appear in the form when sending a survey invite. **Steps to reproduce:** 1. In settings, go to the email templates management page 2. Select the Sur
Original PR description
**Current behavior:** Adding an attachment to a mail template record associated with the survey invite wizard will not cause the attachment to populate the relevant field when actually sending a new…
**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.
**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.
**Steps to reproduce:**
1. In settings, go to the email templates management page
2. Select the Survey: Invite template and upload some
attachment
3. Go to the Survey application and click on one of the surveys
listed, observe the lack of attachments despite having the
email template with the attachment selected
**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.
**Fix:**
Make the attachment_ids field a stored computed field.
opw-3709830
Forward-Port-Of: odoo/odoo#162273
Forward-Port-Of: odoo/odoo#152728When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound". Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time." Task id: 3638740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162224 Forward-Port-Of: odoo/odoo#16210
Original PR description
When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound". Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time." Task id: 3638740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162224 Forward-Port-Of: odoo/odoo#162101
When consuming more tracked by lots (therefore manually-consumed) components than expected, you can easily close the production by clicking 'Set Quantities and Validate' on the consumption wizard. But consuming less than expected gives an 'Invalid Operation: lot/serial number needs to be specified for a tracked product' error. This because _recompute_state consider less consumed components as 'partially_available' rather then 'assigned'. --- I confirm I have signed the CLA and read the PR gu
Original PR description
When consuming more tracked by lots (therefore manually-consumed) components than expected, you can easily close the production by clicking 'Set Quantities and Validate' on the consumption wizard. But consuming less than expected gives an 'Invalid Operation: lot/serial number needs to be specified for a tracked product' error. This because _recompute_state consider less consumed components as 'partially_available' rather then 'assigned'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144718
Description of the issue/feature this PR addresses: Improved error handling for EMV QR generation for invoices Current behavior before PR: Currently, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised. Desired behavior after PR is merged: However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raised `No EMV QR Code is available for the country of the account False.` This commit adds
Original PR description
Description of the issue/feature this PR addresses: Improved error handling for EMV QR generation for invoices Current behavior before PR: Currently, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised. Desired behavior after PR is merged: However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raised `No EMV QR Code is available for the country of the account False.` This commit adds a check to ensure the bank account is set and it raises a better error message. Task# 3868467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162319
Forward-Port-Of: odoo/enterprise#61138 Forward-Port-Of: odoo/enterprise#60420
Original PR description
Forward-Port-Of: odoo/enterprise#61138 Forward-Port-Of: odoo/enterprise#60420
Package is wrongly set on product line in barcode scan Steps: - Have a product P tracked by lot - Set 2 stock quant in 2 locations: 1st in loc1 with lot L and package P 2nd in loc2 with lot1 and no package - Create a picking (Customer delivery) for P with source loc2 - With barcode make the delivery, scan the lot number -> The pack P is set on the product line, even if the package P is in loc1 We pass the location id through the context in order to adapt the domain in `pref
Original PR description
Package is wrongly set on product line in barcode scan Steps: - Have a product P tracked by lot - Set 2 stock quant in 2 locations: 1st in loc1 with lot L and package P 2nd in loc2 with lot1 and no package - Create a picking (Customer delivery) for P with source loc2 - With barcode make the delivery, scan the lot number -> The pack P is set on the product line, even if the package P is in loc1 We pass the location id through the context in order to adapt the domain in `prefilled_owner_package_stock_barcode()`, doing that we ensure we also cover the case where we have 2 stock quant with one with no package and the other with package. opw-3746608 Forward-Port-Of: odoo/enterprise#61110 Forward-Port-Of: odoo/enterprise#59342
Steps to reproduce: - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery Addr
Original PR description
Steps to reproduce: - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US…
Steps to reproduce: - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery Address: [different than customer] (e.g. Deco Addict) * Journal in: USD * Usage: Without fiscal effects * Product: Office Chair * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Try to generate CFDI via "Send & Print" button (it will probably fail) (*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade Issue: Check the generated CFDI in CFDI tab. The data for element `<cce20:Destinatario><cce20:Domicilio /></cce20:Destinatario>` are incorrect. "Calle", "NumeroExterior", "NumeroInterior", "Pais" and "CodigoPostal" are coming from the current company instead of the delivery address. opw-3715960 Forward-Port-Of: odoo/enterprise#61088 Forward-Port-Of: odoo/enterprise#60829
The Belastingdienst for the Dutch government has a service to check the status of the processing of the submitted report. This adds this functionality through a new module (which will be merged in master). Forward-Port-Of: odoo/enterprise#61017 Forward-Port-Of: odoo/enterprise#60777
Original PR description
The Belastingdienst for the Dutch government has a service to check the status of the processing of the submitted report. This adds this functionality through a new module (which will be merged in master). Forward-Port-Of: odoo/enterprise#61017 Forward-Port-Of: odoo/enterprise#60777
# Introduction: `JSON.stringify` was used to serialize the properties for the `/article` command instead of the classical `encodeDataBehaviorProps` which also uses `encodeURIComponent` above the `JSON.stringify`, to avoid having some special characters as an attribute value. # The issue: `html_field.js:getEditingValue` is recovering the current value in the DOM using `innerHTML` which converts some characters from tag attributes to HTML entities, i.e.: `"` for `"`. `mail.py
Original PR description
# Introduction: `JSON.stringify` was used to serialize the properties for the `/article` command instead of the classical `encodeDataBehaviorProps` which also uses `encodeURIComponent` above the…
# Introduction: `JSON.stringify` was used to serialize the properties for the `/article` command instead of the classical `encodeDataBehaviorProps` which also uses `encodeURIComponent` above the `JSON.stringify`, to avoid having some special characters as an attribute value. # The issue: `html_field.js:getEditingValue` is recovering the current value in the DOM using `innerHTML` which converts some characters from tag attributes to HTML entities, i.e.: `"` for `"`. `mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a string with HTML entities, and is returning a string without HTML entities. The database value (without HTML entities) is later given to the `html_field` as a prop and is used as a comparison reference (`updateValue`) with the current value in edition (that is still being converted to have HTML entities). Since both values are different, the field is considered as dirty and in need of being saved, which will trigger a write, even though the normalized value is the same. # Fix: Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor attribute (like for any other Behavior) will prevent the use of characters that are being converted to HTML entities. In order to update existing `/article` blocks, the behavior will overwrite its `data-behavior-props` attribute when it is mounted in edit mode. task-3853291 Forward-Port-Of: odoo/enterprise#60985 Forward-Port-Of: odoo/enterprise#60177
# FIX] knowledge: remove useless popover This commit fixes an issue where the popover would open inside the comments panel when replying to a comment with a small enough window, even though in this situation it's not useful at all. Now when the panel is open and we have a small window, the popover will not open when replying to a comment. # [FIX] knowledge: show panel's comments in small windows This commit fixes an issue with the comments panel when using it with a small window.
Original PR description
# FIX] knowledge: remove useless popover This commit fixes an issue where the popover would open inside the comments panel when replying to a comment with a small enough window, even though in this…
# FIX] knowledge: remove useless popover This commit fixes an issue where the popover would open inside the comments panel when replying to a comment with a small enough window, even though in this situation it's not useful at all. Now when the panel is open and we have a small window, the popover will not open when replying to a comment. # [FIX] knowledge: show panel's comments in small windows This commit fixes an issue with the comments panel when using it with a small window. Before, when you opened the panel when in a small enough window, the comments aren't properly displayed meaning that you only have empty boxes inside the panel. This was caused by a styling issue inside of the template that applied a wrong style to the comment boxes inside panel, which is not necessary inside it. Now, we modified the inline style in the template so that it is not applied inside the panel, showing back those comments in all circumstances. task-3786282 Forward-Port-Of: odoo/enterprise#58045
Before this commit, when a confirmed order was canceled, a draft quote subscription_state was set. It would trigger the constraint `sale_subscription_state_coherence` or _constraint_canceled_subscription depnding the version. THis commits ensure to clean the subscription_state of canceled subscription and it set it back to the correct value if the canceled order is set back to quotation. Forward-Port-Of: odoo/enterprise#61005 Forward-Port-Of: odoo/enterprise#60908
Original PR description
Before this commit, when a confirmed order was canceled, a draft quote subscription_state was set. It would trigger the constraint `sale_subscription_state_coherence` or _constraint_canceled_subscription depnding the version. THis commits ensure to clean the subscription_state of canceled subscription and it set it back to the correct value if the canceled order is set back to quotation. Forward-Port-Of: odoo/enterprise#61005 Forward-Port-Of: odoo/enterprise#60908
Current behavior: When trying to sell a product with a tax, you get an error saying the tax is not allowed. Also some other things were not working properly after this refactor, https://github.com/odoo/odoo/pull/142566. Like `res_company` should be `this.company` Steps to reproduce: - Setup fiskaly - Create a product with a tax - Try to sell it in PoS opw-3845699 Forward-Port-Of: odoo/enterprise#60074
Original PR description
Current behavior: When trying to sell a product with a tax, you get an error saying the tax is not allowed. Also some other things were not working properly after this refactor, https://github.com/odoo/odoo/pull/142566. Like `res_company` should be `this.company` Steps to reproduce: - Setup fiskaly - Create a product with a tax - Try to sell it in PoS opw-3845699 Forward-Port-Of: odoo/enterprise#60074
Forward-Port-Of: odoo/enterprise#60844
Original PR description
Forward-Port-Of: odoo/enterprise#60844
…tprint With this [commit](https://github.com/odoo/enterprise/commit/8638ccc9cc26b997caee852e266b7ecc6f7c632a), we introduced a performance issue for databases with partners having lots (several thousands) bank account numbers. Due to the GROUP BY clause, the query was duplicating each move line for each partner's bank account number, which quickly saturated the server's memory. We eliminated the problem by selecting from `res_partner` instead of `account_move_line`. Forward-Port-Of: o
Original PR description
…tprint With this [commit](https://github.com/odoo/enterprise/commit/8638ccc9cc26b997caee852e266b7ecc6f7c632a), we introduced a performance issue for databases with partners having lots (several thousands) bank account numbers. Due to the GROUP BY clause, the query was duplicating each move line for each partner's bank account number, which quickly saturated the server's memory. We eliminated the problem by selecting from `res_partner` instead of `account_move_line`. Forward-Port-Of: odoo/enterprise#60875 Forward-Port-Of: odoo/enterprise#60851
[FIX] account_reports: skip the 'draft entries' warning for tax closings properly for all tax report Some specific code was added by https://github.com/odoo/enterprise/commit/649960d66eaf0c1cdf0c81b86a6226d77d244b98 in order to ignore the tax closing entries in the warning stating there are draft entries in the period, if on the tax report. However, this was badly forward-ported, and only worked for the generic tax report. With this fix, every tax report will benefit from it, as originally in
Original PR description
[FIX] account_reports: skip the 'draft entries' warning for tax closings properly for all tax report Some specific code was added by https://github.com/odoo/enterprise/commit/649960d66eaf0c1cdf0c81b86a6226d77d244b98 in order to ignore the tax closing entries in the warning stating there are draft entries in the period, if on the tax report. However, this was badly forward-ported, and only worked for the generic tax report. With this fix, every tax report will benefit from it, as originally intended. [FIX] account_reports: re-enable the warning about inactive tags in period for tax reports This warning was dropped by mistake when introducing the new warning mechanism for accounting reports. Forward-Port-Of: odoo/enterprise#60774
Steps to reproduce: - Install helpdesk - Add an alias domain to send ticket - Send a mail to add a ticket, with the mail of the demo user Error: No mail is sent to the user confirming the reception of the ticket. This is due to condition here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L789-L790 This was done to prevent mail being sent if we created the ticket through the frontend. Desired behaviour as checked with
Original PR description
Steps to reproduce: - Install helpdesk - Add an alias domain to send ticket - Send a mail to add a ticket, with the mail of the demo user Error: No mail is sent to the user confirming the reception of the ticket. This is due to condition here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L789-L790 This was done to prevent mail being sent if we created the ticket through the frontend. Desired behaviour as checked with PO is to keep this behaviour in frontend but to send a mail back if we submitted ticket through mail. By looking at the context we can the origin of the ticket (frontend or mail) and send a mail if it came from an email. Context key we used is set here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L742 opw-3786152 Forward-Port-Of: odoo/enterprise#59776
This commit fixes the note handling in the UBL tags for the l10n_pe_edi module by ensuring notes contain only alphanumeric characters and spaces, conforming to UBL specifications. This change: - Removes all non-alphanumeric characters except spaces. - Ensures notes are truncated to a maximum of 200 characters. Legal Reference: https://cpe.sunat.gob.pe/sites/default/files/inline-files/AjustesValidacionesCPEv20240205_.xlsx  Forward-Port-Of: odoo/enterprise#60888
- Ensure that only managers can see the "Add a Leave" button to prevent crashes caused by unauthorized user groups attempting to access it. - Replace the "Share Availability" and dropdown button with "Share Appointment Link" which will work the same as the dropdown was working but will not contain the "Select Dates" and "Any time" options for user groups without permission to access the "appointment.type" record. - "Share Appointment Link" button will only appear if we have some custom lin
Original PR description
- Ensure that only managers can see the "Add a Leave" button to prevent crashes caused by unauthorized user groups attempting to access it. - Replace the "Share Availability" and dropdown button with "Share Appointment Link" which will work the same as the dropdown was working but will not contain the "Select Dates" and "Any time" options for user groups without permission to access the "appointment.type" record. - "Share Appointment Link" button will only appear if we have some custom link means current user is assigned in some appointment. - Now the buttons creating the custom appointment and the any-time appointment are hidden for the user who lacks access so we can clean some sudo from the controller as "group_appointment_user" already have rights to create the appointment types. Task-3697864 Forward-Port-Of: odoo/enterprise#61009
New car on the contract, which is now a simple technical field has currently an effect on the employer cost, leading to an employer cost increase after signing with a wishlist car. We fix that by neutralizing the field. Forward-Port-Of: odoo/enterprise#60947
Original PR description
New car on the contract, which is now a simple technical field has currently an effect on the employer cost, leading to an employer cost increase after signing with a wishlist car. We fix that by neutralizing the field. Forward-Port-Of: odoo/enterprise#60947
**Coverage for community fix** https://github.com/odoo/odoo/pull/157515 opw-3754297 Forward-Port-Of: odoo/enterprise#59301 Forward-Port-Of: odoo/enterprise#58264
Original PR description
**Coverage for community fix** https://github.com/odoo/odoo/pull/157515 opw-3754297 Forward-Port-Of: odoo/enterprise#59301 Forward-Port-Of: odoo/enterprise#58264
Currently, the xsd validation tries to fetch a part of the xsd from internet. There is no need for it, we should just have it (as the others). It causes issues when running the tests if you can't make the request. (reproducible if you have no internet). Linked to runbot error 30521 Forward-Port-Of: odoo/enterprise#60964
Original PR description
Currently, the xsd validation tries to fetch a part of the xsd from internet. There is no need for it, we should just have it (as the others). It causes issues when running the tests if you can't make the request. (reproducible if you have no internet). Linked to runbot error 30521 Forward-Port-Of: odoo/enterprise#60964
Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2). ### Setup * install `l10n_es_reports` * switch to a Spanish company ### Steps to reproduce issue 1 * with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report) * open the model 347 tax report We would expect the new partner to be listed in the report, but they ar
Original PR description
Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2). ### Setup * install `l10n_es_reports` *…
Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2). ### Setup * install `l10n_es_reports` * switch to a Spanish company ### Steps to reproduce issue 1 * with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report) * open the model 347 tax report We would expect the new partner to be listed in the report, but they aren't. ### Steps to reproduce issue 2 * with a new partner, create and confirm an invoice for more than €3005.06 * if you open the model 347 report, you will see the new partner listed there * go back to that invoice and register a payment for it. * open the model 347 report again We expect the new partner to still be listed, but they are not. ### Cause issue 1: receipts are missing in the corresponding domains. issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation. opw-3816370 Forward-Port-Of: odoo/enterprise#60432 Forward-Port-Of: odoo/enterprise#59343
This PR adds the same description for Worldline as we already do for Ingenico to clearly state that our Worldline intergration is only available in Benelux. task-3866802 Forward-Port-Of: odoo/enterprise#60676 Forward-Port-Of: odoo/enterprise#60649
Original PR description
This PR adds the same description for Worldline as we already do for Ingenico to clearly state that our Worldline intergration is only available in Benelux. task-3866802 Forward-Port-Of: odoo/enterprise#60676 Forward-Port-Of: odoo/enterprise#60649
The post-init hook of this module runs `ChartTemplate._load_data` and that might reference the xmlid of a general journal from the company. If that xmlid is missing, it will fail with the error: ``` KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7f9ff24b1240>, 'account.1_general') ``` Steps to reproduce on a fresh 17.0 database: - Install a localization module, eg `l10n_be`. - This will create the necessary xmlids. Delete the `X_general` xmlids from the dabase. - I
Original PR description
The post-init hook of this module runs `ChartTemplate._load_data` and that might reference the xmlid of a general journal from the company. If that xmlid is missing, it will fail with the error:
```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7f9ff24b1240>, 'account.1_general')
```
Steps to reproduce on a fresh 17.0 database:
- Install a localization module, eg `l10n_be`.
- This will create the necessary xmlids. Delete the `X_general` xmlids from the dabase.
- Install `account_accountant`. Installation will fail with the aforementioned error.
This also happens during upgrades:
- On a fresh 16.0 database, install module `l10n_uk`.
- The `X_general` xmlids are not created as they don't exist in this version.
- Upgrade to 17.0
- `l10n_uk` doesn't load data from its template, so the xmlids still don't exist.
- Module `account_accountant` is automatically installed, triggering the error.
Forward-Port-Of: odoo/enterprise#59512**Steps to reproduce:** - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery Address: [different than customer] (e.g. Deco Addict) * Product: Office Chair * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Generate CFDI via "Send & Print" button (*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade **Issue:** A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called. **Cause:** The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one. **Solution:** "_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values. These data were used to populate the external trade data of the CFDI. "_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI. It is used with a copy of the cfdi values to compute the values for the delivery address. opw-3849153 Forward-Port-Of: odoo/enterprise#60758
1>To activate the complete form view, allowing additional details beyond the fields in the 'calendar_event_view_form_gantt_booking' view to be included without requiring users to open a new tab and search for the event separately, which is highly inefficient. 2>The logged user was being set as an organizer by default even though a particular attendee's slot had been clicked on the gantt view. so the attendee will be set as an organizer by default when clicking on the slot. A test case has
Original PR description
1>To activate the complete form view, allowing additional details beyond the fields in the 'calendar_event_view_form_gantt_booking' view to be included without requiring users to open a new tab and search for the event separately, which is highly inefficient. 2>The logged user was being set as an organizer by default even though a particular attendee's slot had been clicked on the gantt view. so the attendee will be set as an organizer by default when clicking on the slot. A test case has been added to ensure the above functionality for the gantt view does not break. Task-3679307 Forward-Port-Of: odoo/enterprise#60967 Forward-Port-Of: odoo/enterprise#56123
The readonly flag on `res_partner`.`search` was not respected because of `CREATE TEMP TABLE followup_data_cache`. It was used to create a transactional cache. Instead of putting this cache on the database side, put it on the Python side. On the Python side, the memory spike should be the same (we've retrieved all the data at some point), but the memory won't be free until the end of the transaction/cursor. If the memory problem still occurs, we can easily reduce the memory usage by 3 by
Original PR description
The readonly flag on `res_partner`.`search` was not respected because of `CREATE TEMP TABLE followup_data_cache`. It was used to create a transactional cache. Instead of putting this cache on the database side, put it on the Python side. On the Python side, the memory spike should be the same (we've retrieved all the data at some point), but the memory won't be free until the end of the transaction/cursor. If the memory problem still occurs, we can easily reduce the memory usage by 3 by avoiding the use of dict and dictfetchall usages. https://github.com/odoo/odoo/pull/162390 Forward-Port-Of: odoo/enterprise#60951
**Current behavior:** If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs. **Expected behavior:** The recurring plan can be changed as it ordinarily would. **Steps to reproduce:** 1. Add a recurring product to a sale order 2. Add an optional recurring product to the order 3. Try to change the recurring plan of the order to encounter the trace back **Cause of the issue:** This flow causes some 'phanto
Original PR description
**Current behavior:** If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs. **Expected behavior:** The recurring plan can…
**Current behavior:** If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs. **Expected behavior:** The recurring plan can be changed as it ordinarily would. **Steps to reproduce:** 1. Add a recurring product to a sale order 2. Add an optional recurring product to the order 3. Try to change the recurring plan of the order to encounter the trace back **Cause of the issue:** This flow causes some 'phantom' sale order lines to have their price recalculated (phantom because they have no price, qty, currency, nor order_id field values). During this recalculation a currency_id is expected either in the line itself or in the sale order it is a part of. Because there is no value for either of these, it fails the ensure_one() method in the sequence (0 vals, expects 1). The phantom lines are created in the `sale.order.option` model in the `sale_management` module, in `_compute_price_unit()` and `_compute_discount()`. **Fix:** Call `invalidate_recorset(flush=False)` on these cached records at the end of the methods in which they are created. Test added in https://github.com/odoo/enterprise/pull/58264 opw-3754297 Forward-Port-Of: odoo/odoo#158950 Forward-Port-Of: odoo/odoo#157515