Monday, July 1, 2024
21 changes · saas-17.1
Miscellaneous changes
[FIX] l10n_pk: script to auto trigger try_loading here->https://github.com/odoo/odoo/commit/049f2a2fad240e738b15794763b48e0e79bf50d3 We did a big improvement in the pk package but if the user tries to use the new stuff He won't have them because he needs to manually trigger the reload button in the configuration page solution: bump-up the package version and add a local script to automatically trigger that try_loading functionality task-id#3871597 --- I confirm I have signed the C
Original PR description
[FIX] l10n_pk: script to auto trigger try_loading here->https://github.com/odoo/odoo/commit/049f2a2fad240e738b15794763b48e0e79bf50d3 We did a big improvement in the pk package but if the user tries to use the new stuff He won't have them because he needs to manually trigger the reload button in the configuration page solution: bump-up the package version and add a local script to automatically trigger that try_loading functionality task-id#3871597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171361
Anglo-Saxon accounting is the main system used in Colombia, this commit enables it by default when installing `l10n_co`. This configuration is only accessible in Debug mode in the `Settings` -> `Bank and Cash` section, so during the implementation it doesn't get much visibility. Setting the correct default for the localization helps prevent re-implementations and reduces accounting errors for companies. At present, the impact of this configuration can only be assessed after going live.
Original PR description
Anglo-Saxon accounting is the main system used in Colombia, this commit enables it by default when installing `l10n_co`. This configuration is only accessible in Debug mode in the `Settings` -> `Bank and Cash` section, so during the implementation it doesn't get much visibility. Setting the correct default for the localization helps prevent re-implementations and reduces accounting errors for companies. At present, the impact of this configuration can only be assessed after going live. [Task link](https://www.odoo.com/odoo/project.task/3990709) task-3990709 Forward-Port-Of: odoo/odoo#170732
Use of the record.{field}.value was causing the displayed (string) values to be used in the kanban card's t-if logic rather than the actual value of the field. This resulted in - `record.cap_accrued_time.value` ALWAYS being evaluated as True (since "False" is True) - `record.maximum_leave.value > 0` evaluating as True when the language wasn't a language that uses "." as it's decimal separator. e.g. "5.00" > 0 == True but "5,00" > 0 == False opw-3999753 Also, re-export the po
Original PR description
Use of the record.{field}.value was causing the displayed (string) values
to be used in the kanban card's t-if logic rather than the actual value
of the field. This resulted in
- `record.cap_accrued_time.value` ALWAYS being evaluated as True (since
"False" is True)
- `record.maximum_leave.value > 0` evaluating as True when the language
wasn't a language that uses "." as it's decimal separator. e.g.
"5.00" > 0 == True but "5,00" > 0 == False
opw-3999753
Also, re-export the pot file since it was noticed that it's no longer correct.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#170321When using base.automation a timed condition using a calendar, the check was done for each record to get the datetime with the delay using the calendar. Now we invert the logic instead of adding the delay to the record in a loop datetime field, we substract from the last_run and now once outside of the loop. It goes from this logic: last_run <= record_dt + delay < now to this: last_run - delay <= record_dt < now - delay In a database with 1000 records to check a single calendar: it
Original PR description
When using base.automation a timed condition using a calendar, the check was done for each record to get the datetime with the delay using the calendar. Now we invert the logic instead of adding the delay to the record in a loop datetime field, we substract from the last_run and now once outside of the loop. It goes from this logic: last_run <= record_dt + delay < now to this: last_run - delay <= record_dt < now - delay In a database with 1000 records to check a single calendar: it went from 15s to 20ms opw-3876867 https://github.com/odoo/enterprise/pull/65417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171270 Forward-Port-Of: odoo/odoo#167310
Steps to reproduce: 1. Go to website > Edit 2. Drag and drop 'Banner' snippet and 'Items' snippet > Save 3. Repeat the step 2 again 4. Error will be generated in terminal Current behavior before PR: Dropping and saving new snippets immediately after snippets containing links would generate a traceback. This issue occurred because the `callPostSnippetDrop` had not completed execution, and `cleanForSave`, responsible for removing `zwnbsp` was called prematurely. Consequently `historySt
Original PR description
Steps to reproduce: 1. Go to website > Edit 2. Drag and drop 'Banner' snippet and 'Items' snippet > Save 3. Repeat the step 2 again 4. Error will be generated in terminal Current behavior before PR: Dropping and saving new snippets immediately after snippets containing links would generate a traceback. This issue occurred because the `callPostSnippetDrop` had not completed execution, and `cleanForSave`, responsible for removing `zwnbsp` was called prematurely. Consequently `historyStep` after `callPostSnippetDrop` would reintroduce `zwnbsp` to links. Desired behavior after PR is merged: Ensure that all post-snippet drop promises are resolved before saving. task-3954229 Forward-Port-Of: odoo/odoo#171068 Forward-Port-Of: odoo/odoo#167365
When reducing the quantity to produce in the subcontracted manufacturing orders, we use the wrong quantity for the call to `change_prod_qty()`. Instead of `production.product_uom_qty` (which is in the **product** uom), use `production.product_qty` (which is in the **production** uom), itself set from the move's uom. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171204 Forward-Port-Of: odoo/odoo#171093
Original PR description
When reducing the quantity to produce in the subcontracted manufacturing orders, we use the wrong quantity for the call to `change_prod_qty()`. Instead of `production.product_uom_qty` (which is in the **product** uom), use `production.product_qty` (which is in the **production** uom), itself set from the move's uom. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171204 Forward-Port-Of: odoo/odoo#171093
*= hr_expense, project_sale_expense -STEP TO REPRODUCE: Create an expense sheet , submit then approve it as well, go to Pg admin or update the view manually to see the field `approval_state`. The `approval_state` is now approved. After that try to refuse the sheet, `approval_state` still approved while it should be consider `cancel` (Refuse) -Solution is to forbids unrealistic case where we shouldn't allow user to cancel when it linked to a journal entry and also update `approval_stat
Original PR description
*= hr_expense, project_sale_expense -STEP TO REPRODUCE: Create an expense sheet , submit then approve it as well, go to Pg admin or update the view manually to see the field `approval_state`. The `approval_state` is now approved. After that try to refuse the sheet, `approval_state` still approved while it should be consider `cancel` (Refuse) -Solution is to forbids unrealistic case where we shouldn't allow user to cancel when it linked to a journal entry and also update `approval_state` as well -> Therefore some test in `test_project_profitability` need to adapt 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#168430
In a large database with lots (>1M) account.moves, installing the ecommerce module can lead to a MemoryError. This is because of the computed stored field `website_id`. Computing this field's value for each one of the >1M account.moves overfills the field_cache and make the 2gb worker hit a memory limit. To fix that, this commit init the compute field through an override of the `_auto_init` method. As `sale.order.website_id` is expected to be NULL at the module installation, creating the webs
Original PR description
In a large database with lots (>1M) account.moves, installing the ecommerce module can lead to a MemoryError. This is because of the computed stored field `website_id`. Computing this field's value for each one of the >1M account.moves overfills the field_cache and make the 2gb worker hit a memory limit. To fix that, this commit init the compute field through an override of the `_auto_init` method. As `sale.order.website_id` is expected to be NULL at the module installation, creating the website_id column on the account.move table is enough. opw-3989064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169991
In this PR fixes the following issue: - This pull request addresses a mobile view issue in the 'customer ratings' section by setting the 'frequency' field width to 'auto.' This adjustment prevents content overflow on mobile devices, enhancing user experience. Your review and feedback are appreciated for seamless integration. - I'm submitting a pull request to address an issue in the 'project.task' kanban card. The problem is the persistent visibility of the 'Assign People' b
Original PR description
In this PR fixes the following issue:
- This pull request addresses a mobile view issue in the 'customer ratings' section by setting
the 'frequency' field width to 'auto.' This adjustment prevents content overflow on mobile devices,
enhancing user experience. Your review and feedback are appreciated for seamless integration.
- I'm submitting a pull request to address an issue in the 'project.task' kanban card. The problem is
the persistent visibility of the 'Assign People' button for sub-tasks, causing UI clutter. My solution
involves displaying the 'Assign People' button only upon hovering over a sub-task line within the
'project.task' kanban card's sub-tasks list. Your review and feedback on this change are appreciated.
task- 3549267
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#139807**Current behavior before PR:** In discuss guest user view, notification settings button was visible, which used to throw a "Session Expired" error upon being clicked. **Desired behavior after PR is merged:** In discuss guest user view, notification settings button is removed. **task:3975859** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169044
Original PR description
**Current behavior before PR:** In discuss guest user view, notification settings button was visible, which used to throw a "Session Expired" error upon being clicked. **Desired behavior after PR is merged:** In discuss guest user view, notification settings button is removed. **task:3975859** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169044
…xerror ForecastedDetails template inheritance wrong declaration of name (sale_stock, mrp, purchase_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_stock, mrp, purchase_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_stock.ForecastedDe
Original PR description
…xerror ForecastedDetails template inheritance wrong declaration of name (sale_stock, mrp, purchase_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails…
…xerror ForecastedDetails template inheritance wrong declaration of name (sale_stock, mrp, purchase_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_stock, mrp, purchase_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> instead <t t-name="sale_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> ``` here is a issue link :- https://github.com/odoo/odoo/issues/167741 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#171098 Forward-Port-Of: odoo/odoo#169804
The TicketBAI EDI integration will pre-process invoice lines to make sure that the description in the EDI is properly encoded/striped of non-supported characters. However this pre-processing step does not take into account the fact that the `name` field of an `account.move.line` record is not required and can thus be Falsy. This causes the EDI pre-processing to crash with a traceback for invoices with empty lines. This also prevents the cron from going any further than such an invoice in i
Original PR description
The TicketBAI EDI integration will pre-process invoice lines to make sure that the description in the EDI is properly encoded/striped of non-supported characters. However this pre-processing step does not take into account the fact that the `name` field of an `account.move.line` record is not required and can thus be Falsy. This causes the EDI pre-processing to crash with a traceback for invoices with empty lines. This also prevents the cron from going any further than such an invoice in its queue. This fix solves this issue. Note that the generated XML will not pass the XLD validation, since the presence of at least one alpha-numeric character is required - but at least the problem will now be explained with an actual error flow and not a complete crash. opw-3974117 Forward-Port-Of: odoo/odoo#171181
Steps: - In Studio, add a many2one field with the widget "many2one_avatar_user" in SO form - Create a SO and confirm it - Press Alt+I Actual result: - Alt+I is related to "Create Invoice" in UI - Alt+I open the user choice for the added field Expected result: - Alt+Q for "Create Invoice" - Alt+I open the user choice for the added field `q` used to be aligned with [sale_subscription](https://github.com/odoo/enterprise/blob/17.0/sale_subscription/views/sale_order_views.xml#L28) `q
Original PR description
Steps: - In Studio, add a many2one field with the widget "many2one_avatar_user" in SO form - Create a SO and confirm it - Press Alt+I Actual result: - Alt+I is related to "Create Invoice" in UI - Alt+I open the user choice for the added field Expected result: - Alt+Q for "Create Invoice" - Alt+I open the user choice for the added field `q` used to be aligned with [sale_subscription](https://github.com/odoo/enterprise/blob/17.0/sale_subscription/views/sale_order_views.xml#L28) `q` used for "Confirm" action in the same view, should not be a conflict opw-4004869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170997
The Odoo Menu linked to the graphs would not be duplicated on sheet duplication. task-3810369 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#170794 Forward-Port-Of: odoo/odoo#167964
Original PR description
The Odoo Menu linked to the graphs would not be duplicated on sheet duplication. task-3810369 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#170794 Forward-Port-Of: odoo/odoo#167964
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`, with too many move lines, so raises MemoryError queries: ``` jard_1413607=> select partner_id, count(id) total_move_lines from account_move_line where partner_id is not null group by partner_id order by total_move_lines desc limit 5; partner_id | total_move_lines ------------+------------------ 1905 | 547530 1371 | 288578 1396 | 18423
Original PR description
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`, with too many move lines, so raises MemoryError queries: ``` jard_1413607=> select partner_id, count(id)…
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`,
with too many move lines, so raises MemoryError
queries:
```
jard_1413607=> select partner_id, count(id) total_move_lines from account_move_line where partner_id is not null group by partner_id order by total_move_lines desc limit 5;
partner_id | total_move_lines
------------+------------------
1905 | 547530
1371 | 288578
1396 | 18423
3223 | 10945
1244 | 6988
```
traceback:
```py
Traceback (most recent call last):
File "/tmp/tmpj_23hd3k/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 151, in check
self.assertFalse(diff, msg)
AssertionError: [('account.menu_action_move_journal_line_form', 125, 'Accounting > Accounting > Journals > Journal Entries', 205), ('purchase.menu_procurement_management_supplier_name', 247, 'Purchase > Orders > Vendors', 218), ('account.menu_account_customer', 115, 'Accounting > Customers > Customers', 217), ('account.menu_action_move_out_refund_type', 111, 'Accounting > Customers > Credit Notes', 207), ('account.menu_account_supplier', 122, 'Accounting > Vendors > Vendors', 218), ('account.menu_action_move_out_invoice_type', 110, 'Accounting > Customers > Invoices', 206), ('account.menu_action_move_in_refund_type', 118, 'Accounting > Vendors > Refunds', 209), ('account.menu_action_account_moves_all', 126, 'Accounting > Accounting > Journals > Journal Items', 204), ('account.menu_action_move_in_invoice_type', 117, 'Accounting > Vendors > Bills', 208), ('sale.res_partner_menu', 179, 'Sales > Orders > Customers', 217), ('point_of_sale.menu_point_of_sale_customer', 461, 'Point of Sale > Orders > Customers', 217)] is not false : At least one menu or view working before upgrade is not working after upgrade.
('account.menu_action_move_journal_line_form', 125, 'Accounting > Accounting > Journals > Journal Entries', 205):
Traceback (most recent call last):
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 252, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 409, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 438, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3538, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3749, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6590, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 745, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4867, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/stock_landed_costs/models/account_move.py", line 19, in _compute_landed_costs_visible
account_move.landed_costs_visible = any(line.is_landed_costs_line for line in account_move.line_ids)
File "/home/odoo/src/odoo/17.0/addons/stock_landed_costs/models/account_move.py", line 19, in <genexpr>
account_move.landed_costs_visible = any(line.is_landed_costs_line for line in account_move.line_ids)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3775, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3825, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3930, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1108, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
Failed request: UPG-1403488
Ticket: 3797437
Forward-Port-Of: odoo/enterprise#60004Avoid to check calendar for each record. Follows the logic of the community PR: https://github.com/odoo/odoo/pull/167310 Forward-Port-Of: odoo/enterprise#65770 Forward-Port-Of: odoo/enterprise#65417
Original PR description
Avoid to check calendar for each record. Follows the logic of the community PR: https://github.com/odoo/odoo/pull/167310 Forward-Port-Of: odoo/enterprise#65770 Forward-Port-Of: odoo/enterprise#65417
Impacted versions: - 17.0 Steps to reproduce: 1. Install l10n_mx_edi module. 2. Go to Company ESCUELA KEMPER URGATE. 3. Go to Settings / Automatic Currency Rates. 4. Run manually the currency rates. 5. Go to Accounting / Customers / Invoices. 6. Create a new invoice with the next values: - Customer: "INMOBILIARIA CVA" - Currency: USD - Product: Any but set the UNSPSC Category (any) 7. Confirm the invoice. 8. Click send and print. 9. Check CFDI and click on Clic
Original PR description
Impacted versions: - 17.0 Steps to reproduce: 1. Install l10n_mx_edi module. 2. Go to Company ESCUELA KEMPER URGATE. 3. Go to Settings / Automatic Currency Rates. 4. Run manually the currency rates.…
Impacted versions:
- 17.0
Steps to reproduce:
1. Install l10n_mx_edi module.
2. Go to Company ESCUELA KEMPER URGATE.
3. Go to Settings / Automatic Currency Rates.
4. Run manually the currency rates.
5. Go to Accounting / Customers / Invoices.
6. Create a new invoice with the next values:
- Customer: "INMOBILIARIA CVA"
- Currency: USD - Product: Any but set the UNSPSC Category (any)
7. Confirm the invoice.
8. Click send and print.
9. Check CFDI and click on Click send and print.
10. Open the generated xml
Current behavior:
- TipoCambio have many variations depending of product and currency value:
Example: June 17th: have:
| Product | Quantity | TipoCambio |
|---------------------------|----------|------------|
| [FURN_0006] Monitor Stand | 1 | 18.538484 |
| [FURN_0004] Letter Tray | 1 | 18.538558 |
| [E-COM09] Large Desk | 1 | 18.538498 |
Expected behavior:
- TipoCambio (inside XML) should have the exchange value of the currency (invoiced). Example: June 17th should have 18.5385 (USD)
Changes:
- Avoid create query to search mx currency
OPW-3985223
Related PR: #64838
Forward-Port-Of: odoo/enterprise#65664Before this PR: In Marketing Automation, upon opening a template form view, a duplicate button is displayed which won't be used. After this PR: Duplicate button is now hidden. Task - 3994775 Forward-Port-Of: odoo/enterprise#64993
Original PR description
Before this PR: In Marketing Automation, upon opening a template form view, a duplicate button is displayed which won't be used. After this PR: Duplicate button is now hidden. Task - 3994775 Forward-Port-Of: odoo/enterprise#64993
In gantt, if there are no allowed companies none of the resources will have their unavailabilities filled in. Resources not linked to any company should still have their unavailabilities filled in. task-3981513 Forward-Port-Of: odoo/enterprise#64254
Original PR description
In gantt, if there are no allowed companies none of the resources will have their unavailabilities filled in. Resources not linked to any company should still have their unavailabilities filled in. task-3981513 Forward-Port-Of: odoo/enterprise#64254
This module adds user facing elements to ecommerce (i.e. the Website > Shop). This results in part of the checkout process showing up in English when customers are using a language other than Spanish. We make an exception for translating a localization into a language other than the one spoken in the country it's specific to because this is customer facing (i.e. in the website) and we do not want to restrict the language of the potential ecommerce customers. Unfortunately some of the terms th
Original PR description
This module adds user facing elements to ecommerce (i.e. the Website > Shop). This results in part of the checkout process showing up in English when customers are using a language other than Spanish. We make an exception for translating a localization into a language other than the one spoken in the country it's specific to because this is customer facing (i.e. in the website) and we do not want to restrict the language of the potential ecommerce customers. Unfortunately some of the terms that show in the extra step added by this model are defined in other `l10n_mx_*` modules and since we don't want to have to track down only these specific terms or translate all of the Mexico localization into French, we leave some parts untranslated (specifically the invoicing specifics) opw-3881171 Forward-Port-Of: odoo/enterprise#65563
Before this commit, the search bar only look at the visible lines. With that a problem arise with hierarchy for example. When writing an account in the searchbar we want to search on the account.account and not the group. task: 3988840 Forward-Port-Of: odoo/enterprise#65101
Original PR description
Before this commit, the search bar only look at the visible lines. With that a problem arise with hierarchy for example. When writing an account in the searchbar we want to search on the account.account and not the group. task: 3988840 Forward-Port-Of: odoo/enterprise#65101