Odoo Changelog — 2021-09-24

Friday, September 24, 2021

43 changes · master

Improvements(1)

Enhancements to existing features

[IMP]tests: autoretry mechanism for stagings

Coremasterteststools

The test system can now automatically retry failed tests in staging environments to reduce disruption from random, one-off failures. This helps avoid unnecessary delays and manual rework when large batches of changes are being validated, while keeping normal test behavior unchanged.

Original PR description

This branch have been tested with the nightly multi build, creating 40 identical build without test-tags to disable know random errors. This multi build is used to detect test failing randomly, this is an excellent candidate to detect the effect of the retry.
On average, with the current base of this pull request, there is between 10 en 15 failures over 40 build.
With the auto retry mechanism, only 1 build failed over 40 builds since the same error was triggered twice: https://runbot.odoo.com/runbot/build/9972771. This is simply because with the retry mechanism, an error that has a probability of p to fail randomly will still have a probability of p² to fail with the retry mechanism. A error that occurs 10% of the time should only appear 1% of the time with one retry. In most of the case, the retry is sucessfull: https://runbot.odoo.com/runbot/build/10053257

The current solution to allow to enable this mechanism only in some cases (staging) is to check an environment variable "ODOO_TEST_FAILURE_RETRIES" that defines a number of retry. This will allow to retry more than once if an error still occurs to ofen with the autoretry.

**Random error:**
![image](https://user-images.githubusercontent.com/35262360/132853932-98d1ea8c-ecc7-49c5-afbd-57f76eaafef9.png)
**Real error:**
![image](https://user-images.githubusercontent.com/35262360/132853980-bddfd4a9-aceb-4dea-b728-0d2081861350.png)

The mechanism will run multiple time the same test on the same test_case, meaning that some modification on self may impact the second execution. The following code is an example of how this could be problematic, but also a good example to test the auto-retry mechanism.

```python

class TestRetry(HttpCase):
def test_fail(self):
self.t = getattr(self, 't', 0) + 1
if True or self.t == 1:
import logging
_logger = logging.getLogger('test_a')

with self.assertLogs(level="ERROR"):
_logger.error("This shouldn't be log at all")

with mute_logger('test_a'):
_logger.error("This shouldn't be logged (mute)")

_logger.error("This should be log")
```

![image](https://user-images.githubusercontent.com/35262360/132854106-a4d7f7d7-4fe5-4054-bae6-5dd685a1222c.png)

As we can see here the error logs are also managed, and emit at a lower level the first time, butany log higher than 25 will make the test "failed" and the autoretry mechanism will be triggered. The second time, everything is logged normally. We also need to replace Traceback by _Traceback to avoid being catched by runbot Traceback detection regexes.

The inspiration here commes from the assertLogs, that replace all handlers. The mute_logger had to be adapted to use the same strategy, so that quite_logger won't detect logs catched by mute_logger or assertLogs.

#testing#staging#reliability#automation

Bug Fixes(2)

Resolved issues and error corrections

[FIX] account: fix wrong call to super()

PR #76898

Coremasteraccount

This update corrects an internal issue in the accounting report code that could call the wrong underlying behavior. It helps keep accounting report generation reliable without changing how users interact with the system.

#accounting#reports#stability

[FIX] planning: fix warning display

PR #20534

Enterprise

Other(40)

Miscellaneous changes

[FW][ADD] web_editor: add a new shape

PR #77119

Coremasterweb_editor

Reintroduce a missing shape for Theme Bistro. Related: [PR#35](https://github.com/odoo/design-themes/pull/35) [task-2545200](https://www.odoo.com/web#action=333&active_id=4733&cids=1&id=2545200&menu_id=4720&model=project.task&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#76353

Original PR description

Reintroduce a missing shape for Theme Bistro.

Related: [PR#35](https://github.com/odoo/design-themes/pull/35)
[task-2545200](https://www.odoo.com/web#action=333&active_id=4733&cids=1&id=2545200&menu_id=4720&model=project.task&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#76353

[FW][FIX] hr: bring back "My Profile"

This pr proposes an auto retry mechanism for tests. This shouldn't impact normal testing: tests are not supposed to fail, but the growing number of tests and pull requests can lead to some bottleneck when a staging fails because of a random error. This mechanism should help to reduce splits/the need to retry a failed pr. This branch have been tested with the nightly multi build, creating 40 identical build without test-tags to disable know random errors. This multi build is used to detect test failing randomly, this is an excellent candidate to detect the effect of the retry. On average, with the current base of this pull request, there is between 10 en 15 failures over 40 build. With the auto retry mechanism, only 1 build failed over 40 builds since the same error was triggered twice: https://runbot.odoo.com/runbot/build/9972771. This is simply because with the retry mechanism, an error that has a probability of p to fail randomly will still have a probability of p² to fail with the retry mechanism. A error that occurs 10% of the time should only appear 1% of the time with one retry. In most of the case, the retry is sucessfull: https://runbot.odoo.com/runbot/build/10053257 The current solution to allow to enable this mechanism only in some cases (staging) is to check an environment variable "ODOO_TEST_FAILURE_RETRIES" that defines a number of retry. This will allow to retry more than once if an error still occurs to ofen with the autoretry. **Random error:** ![image](https://user-images.githubusercontent.com/35262360/132853932-98d1ea8c-ecc7-49c5-afbd-57f76eaafef9.png) **Real error:** ![image](https://user-images.githubusercontent.com/35262360/132853980-bddfd4a9-aceb-4dea-b728-0d2081861350.png) The mechanism will run multiple time the same test on the same test_case, meaning that some modification on self may impact the second execution. The following code is an example of how this could be problematic, but also a good example to test the auto-retry mechanism. ```python class TestRetry(HttpCase): def test_fail(self): self.t = getattr(self, 't', 0) + 1 if True or self.t == 1: import logging _logger = logging.getLogger('test_a') with self.assertLogs(level="ERROR"): _logger.error("This shouldn't be log at all") with mute_logger('test_a'): _logger.error("This shouldn't be logged (mute)") _logger.error("This should be log") ``` ![image](https://user-images.githubusercontent.com/35262360/132854106-a4d7f7d7-4fe5-4054-bae6-5dd685a1222c.png) As we can see here the error logs are also managed, and emit at a lower level the first time, butany log higher than 25 will make the test "failed" and the autoretry mechanism will be triggered. The second time, everything is logged normally. We also need to replace Traceback by _Traceback to avoid being catched by runbot Traceback detection regexes. The inspiration here commes from the assertLogs, that replace all handlers. The mute_logger had to be adapted to use the same strategy, so that quite_logger won't detect logs catched by mute_logger or assertLogs.

The combination of a RR and a supplier that has a minimum quantity and a lead time leads to incorrect results To reproduce the issue: 1. Create a product P: - Type: Storable 2. Add a reordering rule for P (min: 10, max: 50) 3. Add a vendor to P - Quantity: 1 - Price: 1 - Delivery Lead Time: 7 4. Run the scheduler 5. Open the generated PO Error: The order deadline is <today minus 7 days> instead of today. The receipt date is today instead of <today plus 7 days> When computing the quantity to order, the method needs the value of `qty_forecast` (L254 in [1]) The computation of `qty_forecast` leads to the computation of `lead_days_date`. To do so, it gets the lead days of the associated stock rule `_get_lead_days`. In this method, a seller is selected: [2] However, none of the parameter is defined: [3] In the above case, the seller has a minimum quantity of 1. Therefore, since this information is not given in [2], the vendor is not selected and his lead time is therefore not taken into account. So, `lead_days_date` will be equal to 0 and won't be recomputed. As a result, the planned delivery date is today. Then, the quantity to order is computed (L260 in [1]), so later, the module is able to select the correct seller. However, this one has a lead time of 7 days -> the generated PO will have the planned date to today and the order deadline to <today minus 7 days> Once an orderpoint has its quantity to order defined, its lead time should be recomputed because it may be different depending to the selected seller (and thus we should take this quantity into account when searching for a seller) [1] https://github.com/odoo/odoo/blob/59ac8d891de6e20604494d6cfc6fc357a88d226c/addons/stock/models/stock_orderpoint.py#L254-L260 [2] https://github.com/odoo/odoo/blob/1b03087524080f1a9751b1561cd8891466e72367/addons/purchase_stock/models/stock_rule.py#L153 [3] https://github.com/odoo/odoo/blob/045c6ad3353bb0849d3f93d3488d8dcd8b8975b0/addons/product/models/product.py#L602 OPW-2614798 Forward-Port-Of: odoo/odoo#76956 Forward-Port-Of: odoo/odoo#76162

Improvements(1)

[IMP]tests: autoretry mechanism for stagings

Bug Fixes(2)

[FIX] account: fix wrong call to super()

[FIX] planning: fix warning display

Other(40)

[FW][ADD] web_editor: add a new shape

[FW][FIX] hr: bring back "My Profile"

Improvements(1)

[IMP]tests: autoretry mechanism for stagings

Bug Fixes(2)

[FIX] account: fix wrong call to super()

[FIX] planning: fix warning display

Other(40)

[FW][ADD] web_editor: add a new shape

[FW][FIX] hr: bring back "My Profile"

[FW][FIX] account: typo, change active to activate

[FW][FIX] sale_purchase: fix purchase count MTO

[FW]Saas 14.5 tooltip aab

[FW][FIX] project: fix burndown chart stage issue

[FW][FIX] account: fix 'upload bill tour' bill layout

[FW][FIX] stock: use context_today instead of today

[FW][FIX] website: dynamic snippet, use lxml.html to process rendered view

[FW][FIX] purchase_stock: include qty in lead days computation

[FW][FIX] hw_drivers: Don't terminate Manager thread on exception

[FW][FIX] web_editor: fix traceback when no image selected

[FW][FIX] web_editor: split list on enter in empty li

[FW][FIX] test_mail: fix activity tests

[FW]Update 15.0 themes

[FW]Saas 14.5 lazy report views lpe

[FW][FIX] project: fix various issues

[FW][FIX] account: remove upgrade_boolean from community module

[FW][FIX] event_booth_sale: set correct product type for 'Event Booth' product

[FW][FIX] web: do_action open twice error dialog

[FW][FIX] mail: correct inaccurate doc comment

[FW][FIX] web_editor: fix traceback when no command is selected

[FW][IMP] website_sale: new templates for s_dynamic_snippet_products

[FW][FIX] hr_holidays: fix wrong context for absent action

[FW]Master availability component forecasted v2 ryv

[FW][FIX] mail: avoid exception when creating channel

[FW][FIX] crm: forecast filter

[FW][FIX] web_editor: collaboration should be opt-in

[FW]Saas 14.5 staging qdp

[FW][FIX] hr_payroll: fix unnecessary recompute

[FW][FIX] web_dashboard: transition between legacy to wowl when open in f…

[FW][FIX] l10n_ar_reports: document type wrong codes

[FW][FIX] industry_fsm*, planning, project_enterprise: fix various issues

[FW][REF] *: lazy loading of legacy reporting views

[FW][FIX] hr_appraisal: Last appraisal smartbutton

[FW][FIX] Planning: exclude archived records from the group_expand

[FW][FIX] web_enterprise: correctly catch error when scanning a barcode

[FW][REF] web_dashboard: adapt code to useTooltip API changes

[FW][FIX] pos_blackbox_be: correctly compute discounted value

[FW][FIX] web_enterprise: fix barcode scanner