Friday, November 8, 2024
19 changes · saas-17.2
Resolved issues and error corrections
Shop floor quality worksheets now keep the quality check window usable after a worksheet is opened and completed. Worksheets are no longer validated too early on save, so users only see validation results when they press the intended Validate button.
Original PR description
2 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details.
Miscellaneous changes
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when trying to create the corresponding purchase order. Purpose of this PR: If there are no subscription dates on the invoice lines then we do not calculate the length of the subscription in months and instead create the purchase order line description just as the commission for the corres
Original PR description
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when…
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when trying to create the corresponding purchase order. Purpose of this PR: If there are no subscription dates on the invoice lines then we do not calculate the length of the subscription in months and instead create the purchase order line description just as the commission for the corresponding subscription. Steps to reproduce on runbot: install partner_commission set up a subscription with a referrer and a commission plan create invoice for the subscription try to register the payment for the invoice error raised regarding a max function with no args Notes: looking to investigate further why the subscription dates are not passed from the subscription to the order lines to the invoice lines in 17.0+ field name is changed from `subscription_end_date` to `deferred_end_date` (same for `start` date), will have to adjust in fw ports opw-4240937 Forward-Port-Of: odoo/enterprise#73465 Forward-Port-Of: odoo/enterprise#73428
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de66
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de661fba7a9fc7 opw-4156249 --- Forward-Port-Of: odoo/enterprise#72626
We wait for the next tick to leave the dialog enough time to load properly before changing the mode to draw, this way we avoid to have the canva with the auto result after changing to draw mode. Forward-Port-Of: odoo/enterprise#69785
Original PR description
We wait for the next tick to leave the dialog enough time to load properly before changing the mode to draw, this way we avoid to have the canva with the auto result after changing to draw mode. Forward-Port-Of: odoo/enterprise#69785
When the value to store into a generic id was zero (which can typically happen when doing a non-relational groupby), None was stored into the generic id instead. On groupby lines, this lead the unfold of that line to behave weirdly and not show the proper results. The reason was that, in Python, doing 0 == False gives True. So, when doing 0 in (False, None), we ended up with a True result. Forward-Port-Of: odoo/enterprise#72808
Original PR description
When the value to store into a generic id was zero (which can typically happen when doing a non-relational groupby), None was stored into the generic id instead. On groupby lines, this lead the unfold of that line to behave weirdly and not show the proper results. The reason was that, in Python, doing 0 == False gives True. So, when doing 0 in (False, None), we ended up with a True result. Forward-Port-Of: odoo/enterprise#72808
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware. We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation. Validation is done based on the Avalara documentation [2]. [1] As outlined in "Nota Técnica 2021.003 Validação GTIN" https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8OD
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168
Forward-Port-Of: odoo/enterprise#73517This issue is coming from importing a CSV File in the 'account.bank.statement.line' model was caught by a sentry. Because if the CSV file does not have two columns, which are 'debit' and 'credit', that time getting error is 'amount' is not in the list. step to reproduce- - Install the Accounting. - Go to Dashboard > click on import statement button of Bank card - Upload the statement ([bank statement](https://drive.google.com/file/d/1s_a3Ym27QKRDh63BwPb-3P4g4kjmbH2l/view?usp=drive_link))
Original PR description
This issue is coming from importing a CSV File in the 'account.bank.statement.line' model was caught by a sentry. Because if the CSV file does not have two columns, which are 'debit' and 'credit', that time getting error is 'amount' is not in the list. step to reproduce- - Install the Accounting. - Go to Dashboard > click on import statement button of Bank card - Upload the statement ([bank statement](https://drive.google.com/file/d/1s_a3Ym27QKRDh63BwPb-3P4g4kjmbH2l/view?usp=drive_link)) - After, click on Test button - Error will be generated.  Sentry: -3931578971 Forward-Port-Of: odoo/enterprise#37315
Description of the issue/feature this PR addresses: Link to task: [#4218972](https://www.odoo.com/web#model=project.task&id=4218972) This change fixes english and arabic labels & translations in the l10n_sa_invoice module Current behavior before PR: Some labels are inaccurate or do not match the saudi arabia ZATCA invoice template. Desired behavior after PR is merged: Labels are more accurate and match the saudi arabia ZATCA invoice template. --- I confirm I have signed the CL
Original PR description
Description of the issue/feature this PR addresses: Link to task: [#4218972](https://www.odoo.com/web#model=project.task&id=4218972) This change fixes english and arabic labels & translations in the l10n_sa_invoice module Current behavior before PR: Some labels are inaccurate or do not match the saudi arabia ZATCA invoice template. Desired behavior after PR is merged: Labels are more accurate and match the saudi arabia ZATCA invoice template. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186096 Forward-Port-Of: odoo/odoo#184060
Steps to reproduce: 1. Take any snippet and select any custom gradient color. 2. Reopen the background color - The selected custom gradient color is not retained as expected. Before version 16, we used wysiwyg, which called the start function to set selected colors easily. In version 17, we switched to OwlJS. Now, color picker always setting the default color as selected color. Therefore, it displays the default color instead of the selected color.  After this PR, the selected color will be set in the start function by replacing the default color, and updating RGBA values accordingly.  Task-3631963 Forward-Port-Of: odoo/odoo#166961
Issue: When multiple companies are set up, if you are working in a company with a different l10n_sa configuration and attempt to send an EDI document for another company, the retrieved API URL may be incorrect depending on the other company's configuration. Steps to reproduce: 1. Create Company A and set `l10n_sa_api_mode` to production. 2. Create Company B and set `l10n_sa_api_mode` to sandbox. 3. Navigate to Company B (keeping Company A selected). 4. Create an invoice for Company A or
Original PR description
Issue: When multiple companies are set up, if you are working in a company with a different l10n_sa configuration and attempt to send an EDI document for another company, the retrieved API URL may be incorrect depending on the other company's configuration. Steps to reproduce: 1. Create Company A and set `l10n_sa_api_mode` to production. 2. Create Company B and set `l10n_sa_api_mode` to sandbox. 3. Navigate to Company B (keeping Company A selected). 4. Create an invoice for Company A or attempt to send the EDI. The API URL retrieved will be for Company B, while it should be for Company A. New behavior: The API URL is now correctly retrieved using the company linked to the journal. Additionally, we now follow the same access as in lines 440 and 539 to fetch the SA environment. opw-4253449 Forward-Port-Of: odoo/odoo#186266
The problem can be reproduced in two ways - by finding a view that integrates a many2one on `ir.model.fields` used without no_create - manually add the field via studio on any view. I found a view with the problem: `marketing_campaign_view_form` which uses the field `unique_field_id` which is defined as such: ```py unique_field_id = fields.Many2one( ir.model.fields', string='Unique Field', compute='_compute_unique_field_id', readonly=False, store=True) ``` To ge
Original PR description
The problem can be reproduced in two ways - by finding a view that integrates a many2one on `ir.model.fields` used without no_create - manually add the field via studio on any view. I found a view…
The problem can be reproduced in two ways
- by finding a view that integrates a many2one on `ir.model.fields` used without no_create
- manually add the field via studio on any view.
I found a view with the problem: `marketing_campaign_view_form` which uses the field `unique_field_id` which is defined as such:
```py
unique_field_id = fields.Many2one(
ir.model.fields', string='Unique Field',
compute='_compute_unique_field_id', readonly=False, store=True)
```
To get there:
- Install `marketing_automation`.
- Open the app
- You arrive in the campaigns view
- Create a new record
- Write the name of a field that doesn't exist, like `dkfjl`.
- A dropdown asks you to “Create `dkfjl`”.
- Click on it
- Crash
```
File “/home/achraf/src/160/odoo/odoo/addons/base/models/ir_model.py”, line 916, in create
if not vals.get('model'):
AssertionError: missing model name for {'field_description': 'dfasf'}
```
This commit removes the assertion to use `model` returned by `super().create`
so that the web client catches the error and proposes to create the
record with not one field name but all the required fields
opw-4116187
Forward-Port-Of: odoo/odoo#186598
Forward-Port-Of: odoo/odoo#186295before this commit, for obfuscating data in the res.partner model, the display_name field is used, which is non stored field and thus in the log, an error/warning is shown as follows while running obfuscate command odoo.cli.obfuscate: Invalid fields: res_partner.display_name the invalid warning is raised as the field is not a stored field and thus removing it from the obfuscation even though, the res.partner name field is obfuscated, the same data is remaining in the complete_name
Original PR description
before this commit, for obfuscating data in the res.partner model, the display_name field is used, which is non stored field and thus in the log, an error/warning is shown as follows while running obfuscate command odoo.cli.obfuscate: Invalid fields: res_partner.display_name the invalid warning is raised as the field is not a stored field and thus removing it from the obfuscation even though, the res.partner name field is obfuscated, the same data is remaining in the complete_name field, so adding this field to obfuscating field list after this commit, the log will not show the invalid field warning and complete name also will be obfuscated --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186583
test_duration_expected_when_done was undeterministically failing, if the test ran at specific times, the difference in minutes between button_start and button_finish functions was rounded incorrectly. having time frozen should solve this behavior. build error in question: [Runbot error](https://runbot.odoo.com/web#id=76232&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F
Original PR description
test_duration_expected_when_done was undeterministically failing, if the test ran at specific times, the difference in minutes between button_start and button_finish functions was rounded incorrectly. having time frozen should solve this behavior. build error in question: [Runbot error](https://runbot.odoo.com/web#id=76232&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185026
Since the unique name constraint only works for the active language, it's possible to have more than one tax with the same name in another language. If that's the case, a `ValueError: Expected singleton` error will occur while retrieving the fields in `unique_tax_name_key`. Found in upg-2077316. Forward-Port-Of: odoo/odoo#183111
Original PR description
Since the unique name constraint only works for the active language, it's possible to have more than one tax with the same name in another language. If that's the case, a `ValueError: Expected singleton` error will occur while retrieving the fields in `unique_tax_name_key`. Found in upg-2077316. Forward-Port-Of: odoo/odoo#183111
Currently when checking if an account.move has downpayments we need to call `filtered` on `self.invoice_line_ids.sale_line_ids`. This can be pretty heavy, especially in `_stock_account_get_anglo_saxon_price_unit` as this method will be called for each account.move.line linked to the invoice being posted. This commit introduces a small method `_get_anglo_saxon_price_ctx` that can be overriden to add data to the context that will be used in `_stock_account_get_anglo_saxon_price_unit`. This i
Original PR description
Currently when checking if an account.move has downpayments we need to call `filtered` on `self.invoice_line_ids.sale_line_ids`. This can be pretty heavy, especially in `_stock_account_get_anglo_saxon_price_unit` as this method will be called for each account.move.line linked to the invoice being posted. This commit introduces a small method `_get_anglo_saxon_price_ctx` that can be overriden to add data to the context that will be used in `_stock_account_get_anglo_saxon_price_unit`. This is done in `sale_stock` to avoid the computation of downpayments for each account.move.line. #### Benchmark Customer database posting an invoice with 5000 lines and 1190 linked sale.orders, products in FIFO. Timing of `_stock_account_get_anglo_saxon_price_unit`: 10min -> 2min30. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186486 Forward-Port-Of: odoo/odoo#184254
Inside `_stock_account_get_anglo_saxon_price_unit` we are retrieving the posted cogs linked to the account.moves. To do that, currently we are retrieving every cogs and then calling `filtered` on the result. This can lead to a huge number of cogs to fetch in large databases. As this filtered call can easily be turned into a search_domain, we replace it by a search call. That way the number of cogs retrieved is way smaller. This has the effect of greatly reducing the memory footprint of the me
Original PR description
Inside `_stock_account_get_anglo_saxon_price_unit` we are retrieving the posted cogs linked to the account.moves. To do that, currently we are retrieving every cogs and then calling `filtered` on the result. This can lead to a huge number of cogs to fetch in large databases. As this filtered call can easily be turned into a search_domain, we replace it by a search call. That way the number of cogs retrieved is way smaller. This has the effect of greatly reducing the memory footprint of the method, as fetching all the fields on a large number of cogs quickly filled up the memory prior to this commit. #### Benchmark In a customer database with 5M account.move.lines, the peak memory consumption of the method when posting an invoice of 5 000 lines goes `1.5 GB -> 250 MB` according to memray --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186443
The lang switching wasn't working properly. The lang bundle was not reloaded when the lang was changed. This commit fixes the issue by adding lang attribute on html element. opw-4246677 Forward-Port-Of: odoo/odoo#186647
Original PR description
The lang switching wasn't working properly. The lang bundle was not reloaded when the lang was changed. This commit fixes the issue by adding lang attribute on html element. opw-4246677 Forward-Port-Of: odoo/odoo#186647
Before this commit, when changing the chart type, the data source was not updated. Which was a problem, because the data returned for different chart types is different (eg. pie charts filter empty points). That meant that when changing the chart type from line => pie we displayed a pie with empty points, but when reloading the page the data would change to the correct one. Task: [4306227](https://www.odoo.com/web#id=4306227&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&
Original PR description
Before this commit, when changing the chart type, the data source was not updated. Which was a problem, because the data returned for different chart types is different (eg. pie charts filter empty points). That meant that when changing the chart type from line => pie we displayed a pie with empty points, but when reloading the page the data would change to the correct one. Task: [4306227](https://www.odoo.com/web#id=4306227&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#186110
Add a check on adyen callback when paying. Verify if the pending payment line exist before processing the callback. opw-4242322 Forward-Port-Of: odoo/odoo#186580
Original PR description
Add a check on adyen callback when paying. Verify if the pending payment line exist before processing the callback. opw-4242322 Forward-Port-Of: odoo/odoo#186580