Saturday, February 3, 2024
9 changes · saas-17.1
Miscellaneous changes
**Steps to reproduce the bug:** Run the following command: `-i purchase_stock,l10n_fr -d cro_test --test-enable --test-tags purchase_stock --stop-after-init` **Problem:** An error is triggered: “odoo.exceptions.UserError: Cannot find a stock input account for the product Analytic Product. You must define one on the product category, or on the location, before processing this operation.” When installing the "l10n_fr" module, the French accounting for the default company will be set
Original PR description
**Steps to reproduce the bug:** Run the following command: `-i purchase_stock,l10n_fr -d cro_test --test-enable --test-tags purchase_stock --stop-after-init` **Problem:** An error is triggered:…
**Steps to reproduce the bug:** Run the following command: `-i purchase_stock,l10n_fr -d cro_test --test-enable --test-tags purchase_stock --stop-after-init` **Problem:** An error is triggered: “odoo.exceptions.UserError: Cannot find a stock input account for the product Analytic Product. You must define one on the product category, or on the location, before processing this operation.” When installing the "l10n_fr" module, the French accounting for the default company will be set. so the "property_stock_account_input_categ_id" will not be set when creating a product category with "property_valuation" set as real_time because the user's company has no chart of accounts: https://github.com/odoo/odoo/blob/c3b4c7d8f2c260c31f9549d480ed2db4159a8119/addons/stock_account/models/product.py#L833-L835 Therefore, when validating the picking related to the purchase order created: https://github.com/odoo/odoo/blob/31d1a2a8a0f1490dd49d86628c0f856ca82198c8/addons/purchase_stock/tests/test_purchase_order_process.py#L124 The product accounts are then retrieved, but will be False: https://github.com/odoo/odoo/blob/9215e73fa229d64167de076ef0a288dd8d89a2cc/addons/stock_account/models/stock_move.py#L336 https://github.com/odoo/odoo/blob/493502bc4ad3ac35b1c0cb2eeb73ac6b6d0fe5b5/addons/stock_account/models/product.py#L29 **Solution:** skip the test if the user's company has no chart of accounts. opw-3698341 Forward-Port-Of: odoo/odoo#152128 Forward-Port-Of: odoo/odoo#151712
**Steps to reproduce the bug:** 1. Create a storable product "P1." 2. Create a quant for P1 with a package and apply. 3. Navigate to the package. 4. Attempt to unpack. **Problem:** A user error is triggered: "Quant's editing is restricted; you can't perform this operation." This occurs because when accessing the package from the quant, we are in inventory mode. And as the "package_id" field is on the forbidden list, the error is raised. **Solution:** During the unpacking process,
Original PR description
**Steps to reproduce the bug:** 1. Create a storable product "P1." 2. Create a quant for P1 with a package and apply. 3. Navigate to the package. 4. Attempt to unpack. **Problem:** A user error is triggered: "Quant's editing is restricted; you can't perform this operation." This occurs because when accessing the package from the quant, we are in inventory mode. And as the "package_id" field is on the forbidden list, the error is raised. **Solution:** During the unpacking process, ensure that we are not in inventory mode. opw-3687164 Forward-Port-Of: odoo/odoo#151826 Forward-Port-Of: odoo/odoo#151508
Before: When a user receive a mass_mailing and click on the unsubscribe button, he arrives on the unsubscribe webpage where the first sentence stay in english whatever the website language Step to reproduce: - Create a db with the email marketing and web module - Create a mailing list with at least one recipient - Send the mailing (catch the email with an email catcher, ex: mailhog) - Click on the unsubscribe button Now: The first sentence is in the website (or portal) language opw-
Original PR description
Before: When a user receive a mass_mailing and click on the unsubscribe button, he arrives on the unsubscribe webpage where the first sentence stay in english whatever the website language Step to reproduce: - Create a db with the email marketing and web module - Create a mailing list with at least one recipient - Send the mailing (catch the email with an email catcher, ex: mailhog) - Click on the unsubscribe button Now: The first sentence is in the website (or portal) language opw-3538873 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#142714
Slot params are dynamic content, similar to props, and are not translated. There is no point in adding untranslated content to the .pot files; so this commit prevents the content of slot params from being exported for translation. Task-3718993 Forward-Port-Of: odoo/odoo#152499
Original PR description
Slot params are dynamic content, similar to props, and are not translated. There is no point in adding untranslated content to the .pot files; so this commit prevents the content of slot params from being exported for translation. Task-3718993 Forward-Port-Of: odoo/odoo#152499
To reproduce ============= - Go to shop page - Edit the page - select a product - add a ribbon - modify the ribbon (background or text color) the ribbon is not updated Problem ======= the default ribbon are using the bootstrap class "text-bg-*" to set the background color and the text color. But the editor expects the ribbon to have a class "bg-*" and color css style. That's why when editing, the class "text-bg-*" is never removed so each time it's taken instead of the added style.
Original PR description
To reproduce ============= - Go to shop page - Edit the page - select a product - add a ribbon - modify the ribbon (background or text color) the ribbon is not updated Problem ======= the default ribbon are using the bootstrap class "text-bg-*" to set the background color and the text color. But the editor expects the ribbon to have a class "bg-*" and color css style. That's why when editing, the class "text-bg-*" is never removed so each time it's taken instead of the added style. Solution ======== remove the class "text-bg-*" from default ribbons and use the fields "bg_color" and "text_color" to set the background and text color opw-3674520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150185
Problem --------- Currently, when importing a UBL/CII xml, the bank account details remain empty while we usually have the bank account number and the BIC code provided in the XML. Objective --------- Autofill the partner_bank_id field on the invoice using the values provided in the UBL/CII XML. Solution --------- Currently, UBL XML are organized as such: PaymentMeans(0..n) |-PayeeFinancialAccount |-ID |-FinancialInstitutionBranch |-ID And CII as such: SpecifiedT
Original PR description
Problem --------- Currently, when importing a UBL/CII xml, the bank account details remain empty while we usually have the bank account number and the BIC code provided in the XML. Objective…
Problem
---------
Currently, when importing a UBL/CII xml, the bank account details remain empty while we usually have the bank account number and the BIC code provided in the XML.
Objective
---------
Autofill the partner_bank_id field on the invoice using the values provided in the UBL/CII XML.
Solution
---------
Currently, UBL XML are organized as such:
PaymentMeans(0..n)
|-PayeeFinancialAccount
|-ID
|-FinancialInstitutionBranch
|-ID
And CII as such:
SpecifiedTradeSettlementPaymentMeans(0..n)
|-PayeePartyCreditorFinancialAccount
| |-IBANID (for SEPA)
| |-ProprietaryID (for national payment)
|
|-PayeeSpecifiedCreditorFinancialInstitution
|-BICID
We first fetch the account numbers from the XML (several may be present) and store them as a list.
This list is sent to the edi_common which will attempt to find one account that match the given values. If none are found, we create one bank account for each piece of bank data found in the xml.
task-3636150
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#152448
Forward-Port-Of: odoo/odoo#147153…ts of goods 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#152125
Original PR description
…ts of goods 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#152125
Like props, slot params are not translated. This commit moves the content to be translated to a text node, allowing it to be translated. opw-3702748 part of task-3718993 Forward-Port-Of: odoo/enterprise#55772
Original PR description
Like props, slot params are not translated. This commit moves the content to be translated to a text node, allowing it to be translated. opw-3702748 part of task-3718993 Forward-Port-Of: odoo/enterprise#55772
In databases with multiple companies, currencies and lots of `account_move_lines`, generating consolidations journals can take a lot of time. There are two bottlenecks for that. The first one comes from `_apply_historical_rates`. The second one is the creation of the `consolidation_journal_lines` records. Nothing can be done about the latter as there are just a lot of records to create. This commit focuses on the former. To speed up `_apply_historical_rates`, a rate_cache is passed through th
Original PR description
In databases with multiple companies, currencies and lots of `account_move_lines`, generating consolidations journals can take a lot of time. There are two bottlenecks for that. The first one comes…
In databases with multiple companies, currencies and lots of `account_move_lines`, generating consolidations journals can take a lot of time. There are two bottlenecks for that. The first one comes from `_apply_historical_rates`. The second one is the creation of the `consolidation_journal_lines` records. Nothing can be done about the latter as there are just a lot of records to create. This commit focuses on the former. To speed up `_apply_historical_rates`, a rate_cache is passed through the context to the `get_rate_for` method of consolidation rates. This method is called a lot of times (once by move_line) with mostly the same values (company_id and chart_id are fixed, only the date changes). Adding a small cache vastly reduces the number of queries on `consolidation.rate`. Also, instead of calling `res_currency_rate._convert` to convert an amount from a given currency to another one, a currency_rate cache is introduced. This cache contains a mapping between `(from_currency, to_currency, company_id, date)` and the conversion rate. That way, `res_currency_rate._get_conversion_rate` is only called for new key-value, which greatly speeds up the generation of consolidations journals. #### speedup Customer database with 2.5M account.move.lines, 2M account.moves, 202 consolidation_periods, 243 consolidation accounts, 0 consolidation_rate, 17 companies, 8512 accounts. Timing to generate consolidation journals. | #account_move_lines, #res_currencies | Before PR | After PR | |:----------------------------------------------------:|:--------------:|:-----------:| | 1036 amls, 2 currencies | 7s | 1.89s | | 4329 amls, 7 currencies | 2.2min | 19.3s | | 15301 amls, 7 currencies | 1.4min | 1.4min| | 43749 amls, 6 currencies | 22.1min | 2min| | 134055 amls, 7 currencies |21.6min | 3.3min| The third entry only contains non-historical consolidation accounts so no visible speedup is expected. Forward-Port-Of: odoo/enterprise#55692 Forward-Port-Of: odoo/enterprise#54030