Improve the performance/scalability of the forecasted compute.
Duplicate the code of the `_get_report_lines`
(`_get_forecast_availability_outgoing`) and specialize it to only
compute necessary information for the `_compute_forecast_information`.
It is mandatory to readd 'Component/Product Availability' (MO/picking)
which aggregate the result of `_compute_forecast_information`.
Note that with this refactor, it is still too slow to add in the
view normally. We should fetch it with a lazy way.
With a DB populate with 3 company and 6 warehouses (2 for each company),
50 locations, 30K stock moves, 9K quants and 1700 products.
Before fix:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.031 ± 0.0004 sec of SQL, 0.204 ± 0.008 sec of Python
=> 0.235 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
382 SQL request, 1.334 ± 0.052 sec of SQL, 6.807 ± 0.223 sec of Python
=> 8.141 sec
After refactor:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.029 ± 0.0004 sec of SQL, 0.074 ± 0.003 sec of Python
=> 0.103 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
369 SQL request, 0.550 ± 0.009 sec of SQL, 0.969 ± 0.012 sec of Python
=> 1.519 sec
task-2579011
Part-of: odoo/odoo#77092
- Clean the `report_stock_forecasted` for the next commit.
- Add some test about the `_compute_forecast_information` to ensure
the correctness of the forecasted widget.
task-2579011
Part-of: odoo/odoo#77092
The `_compute_warehouse_id` wasn't never batched (never prefetch)
because of the `recursive=True` in its declaration.
Remove the recursion depends and add manual
invalidate cache to stay consistent.
It avoids extra SQL request by prefetching correctly
the `warehouse_id` fields.
task-2579011
Part-of: odoo/odoo#77092
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
The `_compute_json_popover` of (`mrp.production`)
was slowing down the tree view of MO (because it loaded
every move due to `production.move_raw_ids` even if there
isn't `delay_alert_date`.
Make it more lazier: we gain a speed up
when the there aren't any delay_alert_date
(always when the setup is simple)
To read 150 MO (7500 moves behind):
Before: 0.099 ± 0.002 SQL sec, 0.224 ± 0.005 Python sec (37 SQL requests)
After: 0.060 ± 0.0008 SQL sec, 0.096 ± 0.002 Python sec (29 SQL requests)
Also, unify the code with `stock.picking`.
task-2579011
Part-of: odoo/odoo#77092
The reserved and the done column doesn't have any sense for
draft picking and the forectasted button was always green.
-> Fix it
Also we add forectasted information for draft move in mrp
(281e1a57b3).
-> Use it also for outgoing picking
task-2579011
Part-of: odoo/odoo#77092
In multi-warehouse, when we open the forecasted report from a component
line of MO, the default warehouse in the forecast_report was always the
first of the company. Because it took destination location warehouse
(== False because it is destination location == subcontracting location)
instead of the source location in case of MO.
task-2579011
Part-of: odoo/odoo#77092
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.
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.
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")
```
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.
closesodoo/odoo#76336
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since odoo/odoo#35700 department_id is not a searchable field in the
employee search view as it has been added in the searchpanel. Since
then, the view from department > absence has been broken since it was
not filtering on the department anymore.
This commit fixes that behaviour by defaulting to the department in the
searchpanel instead.
TaskId-2648380
closesodoo/odoo#77157
X-original-commit: 9200742a1bde75ec2de02b9d11f67dc77538d79d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This branch add new template for the **s_dynamic_snippet_products** and adapt the current ones.
task-2602978
#75623closesodoo/odoo#77153
Forward-port-of: odoo/odoo#75623
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adds new templates for the s_dynamic_snippet_products
and improves the current templates for a better reading of the product’s
title and a better management of space when the content have different
width.
Part of https://github.com/odoo/odoo/pull/75623
task-2602978
X-original-commit: 49bd79b0bdca76415780bdfa199195371c2692e5
Part-of: odoo/odoo#77153
This commit adds a new template called "Rating: static star compressed
widget".
Instead, having 5 stars, it returns an empty/half/full star with the
average rating. This smaller layout is used in the dynamic snippets
product.
Adapts the style of empty stars (it uses the outline star icon instead grey
background) to work well on light and dark backgrounds.
Part of https://github.com/odoo/odoo/pull/75623
task-2602978
X-original-commit: 0690e187ebb7e67694c8236f420213beed29993d
Part-of: odoo/odoo#77153
Now if you fetch 4 elements, we preset to 4 the number of record displayed
X-original-commit: 5c1d0c4249a16e41eac361728df6e95674e26d3d
Part-of: odoo/odoo#77153
On rendering, we check the higher slide to set this size as min-height of the
carousel and avoid flickering.
X-original-commit: c2e3fdccd84a9077b50d2fcf0dd147026cbc613a
Part-of: odoo/odoo#77153
This commit will correct an inaccurate comment introduced with
odoo/odoo#76951. The comment states that the 'joinButton' shall be
disabled when the current user is NOT a guest, which is not true:
'joinButton' can only be disabled if the current user is a guest.
closesodoo/odoo#77149
X-original-commit: 93a78e437e9c7775f4b174f660e22368bdd4a3aa
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, using a do_action that throws an error opened two
error dialogs.
To solve this, in the compatibility layer, we check that the error has
not already been thrown.
To reproduce the problem, you can execute an action using do_action
which will return an error. For example, an action performing an rpc
and the server returns an error.
You can find an example scenario to test the problem on the 2618694.
closesodoo/odoo#77148
X-original-commit: 582604990e28c329348475f373b03295903ed77e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When booth management is activated, we have a dedicated product for the event
booth. Currently, the product type for this product is set as 'Service'.
This happens after a recent commit[1]. With this commit, we now have a
dedicated detailed product type for event booth, but in data file of
booth product it is set to `service`, which in this case should be
`event_booth`. Apart from that, when creating a booth product for event
booth category, the product type is set as 'consumable', which should
be 'service'.
This commit updates the data for the default booth product and sets the
detailed product type to `event_booth`. And this commit also passes
correct context when creating a product for the event booth category so
that the product type is now set as 'service'.
commit[1] - https://github.com/odoo/odoo/commit/3d7b9bbf27298dc7f2f7e61a13120988f9bd422a
Task-2648950
closesodoo/odoo#77146
X-original-commit: e466430e44844339f1ec9f2ed3c79f6f34501291
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Module `account_check_printing` exist on community edition so
It doesn't makes sense to apply `upgrade_boolean` widget on that.
However, It is necessary to have supported modules installed to
use Check Layout.
closesodoo/odoo#77145
X-original-commit: adc24d9082933f801f972fa93e1866be194c8b7a
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Deleting record from tasks analysis report tree view has been stopped.
Issue:
If the record is opened from the list view, auto-generated from view is opened,
so the list view is restricted.
Closes#76465
task-2645891
closesodoo/odoo#77094
X-original-commit: e9ad8994c2836fcec41565c40e36784bd6152943
Related: odoo/enterprise#21136
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Fix some activity tests: use real test models, try to avoid date issues
by using freezegun.
Followup of odoo/odoo@a26e6e954c and odoo/odoo@06dee038dd .
Task-2654840
closesodoo/odoo#77120
X-original-commit: 2387c2ee6272a7c260386427c108208e747b819b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This matches the behavior of GDocs and CKEditor.
closesodoo/odoo#77115
X-original-commit: a84a6c869b815bf372d81db538b458cd23c99b07
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If you unplug the iot box and wait 15 seconds or so, and then plug it
back in, it's possible to get an exception from helpers.get_ip, because
neither the wired nor the wireless interface has an IP. In that case,
the exception would kill the Manager thread, since it was uncaught.
This fix adds a catch-all to the Manager thread that logs any uncaught
exceptions and continues its main loop.
closesodoo/odoo#77111
X-original-commit: a9808a4efe46c4ba7948f5d6a8757546c6b4147b
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Raf Geens <raf-odoo@users.noreply.github.com>
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
closesodoo/odoo#77110
X-original-commit: f2eb1dca99d16d70613c2f724d4b73f273a49ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
t-field of a Text field, will use nl2br function that replace \n to <br>.
So it is html that we need to parse.
Add one return line in your sale description, and the rendering will fail
with an error opening and ending missmatch for br...
closesodoo/odoo#77108
X-original-commit: 3b3f9b24362e57b4c1538d8377ef4de5f3d65058
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
`fields.Date.today` doesn't give date based on TZ which might be wrong
in some cases as it doesn't respect TZ.
With this commit, we are using `fields.Date.context_today` as default date.
closesodoo/odoo#77104
X-original-commit: 24b91073a67b97af1ef3d61aee02a4ddd7053cd5
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
- add outer shadow to bill in wizard preview
- move address block to right in generated pdf, same as in wizard preview
- set invoice date & due date on one line in pdf, same as in wizard preview
closesodoo/odoo#77093
Task: 2581377
X-original-commit: ecf2bba66782cd8b2455bf656cdf2a41fafecf89
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: jbw-odoo <jbw-odoo@users.noreply.github.com>
Currently when move the task from one project(A) to another project(B)
and open the burndown chart of second project(B) it shows the stages
of first project(A). which is wrong.
so in this commit, include the tracking values of the current project
only, do not include the tracking value of the older projects.
Task-2616736
closesodoo/odoo#76964
X-original-commit: 9a6624f5f743677a233489932840e3a739330452
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
We don't have any option to see to see all the events currently. However
this option can be useful sometimes. For example you are looking for an
event but don't know whether it's already finished or upcoming. Or if you
are looking if some event "types" are available (e.g.: Do they sometimes
organize Tennis competitions ?).
In this commit a new filter is added in the last 'All events' which allows
users to see all the events.
Task-2581308
Part-of: odoo/odoo#75066
Before this commit, the useTooltip hooks didn't call clearInterval
when the component using it was unmounted/destroyed. In practice,
it wasn't an issue because the only component using it was the
webclient, and it is never destroyed. However, for this hook to be
usable in other contexts, it is important to remove this leak.
closesodoo/odoo#77113
X-original-commit: d076afd035ad8fadc5a0774c6c0eec15acb15026
Related: odoo/enterprise#21147
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allowing to specify components inside tooltips to obtain dynamic
and/or html content was a bit overkill and unnecessary: a template
can do the trick and it is easier to define.
This commit thus renames attribute "data-tooltip-component" into
"data-tooltip-template" (the name of the qweb template) and
introduces the "data-tooltip-info" attribute (its value is then
available in the template under the "info" variable).
X-original-commit: 8683a8d762339451e3d9f8706aac86da80510b37
Part-of: odoo/odoo#77113
Since the merge of 0573aca the override was no longer working.
closesodoo/odoo#77097
Taskid: 2651838
X-original-commit: 947194644a09f186899f2b2526cf0b0675af7304
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Don't set 'repeat-y' to false explicitely as it is the default value.
X-original-commit: 26612818d71f072eaf291df6d4ee839301f36dc7
Part-of: odoo/odoo#77119
In [1], we rewrote the effect feature in the wowl infrastructure.
However, we lost something in the process: the "type" of effect
(basically "rainbow_man" as it is the only implemented effect)
became a mandatory param, whereas before it simply defaulted to
"rainbow_man" when not set. As a consequence, previously defined
effects in views could crash.
This commit fixes that issue, and reworks a bit the feature by
introducing a registry of effects, which easily allows to add new
effects from the outside. An effect is a function that may return
a Component (and its props) to display.
Most of the diff in the tests is about moving files where they
should be (the effect feature being in core/, the tests must be
in core/ as well, and not depend on the webclient).
[1] 0573acae23
Task 2652927
closesodoo/odoo#77109
X-original-commit: 74dc3f654ee5849982b494e46eefb1fc2b4e0c74
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Rémy Voet (ryv)