Some modules are only adding data/tests/routes/static content.
In this case, it is useless to check the database schema or setup models
in registry.
closesodoo/odoo#78898
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With a lot of module installed setup_models can be quite slow.
One of the reason for that are the call to resolve_mro.
This operation is fast, but called for a lot of models/fields this
become an important part of get_depends and setup_base.
- This is call once for each models in setup_base
- This is call more than once for each computed_field in get_depends.
The use of a cache shows significative performance improvements.
During the install of a database with all modules, the install times
is reduced by ~3 minutes over ~14
Part-of: odoo/odoo#78898
Co-authored-by: Raphael Collet <rco@odoo.com>
Improves on _attendance_intervals_batch to profit more from batching.
Resources are grouped by timezone since we know they will all have the
same result except for when there are resource assigned attendances.
Those have to be handled separately but are incoroporated in the same
routine.
TaskId-2674527
closesodoo/odoo#78741
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If no timezone is given to _attendance_intervals_batch, the timezone was
overwritten by the first resource's timezone.
TaskId-2674527
Part-of: odoo/odoo#78741
Make tax field "Base Affected by Previous Taxes" only visible in debug mode.
closesodoo/odoo#78733
Task: 2608764
Signed-off-by: William André (wan) <wan@odoo.com>
A time off for multiple employees was not showing who the employees were
in the list view.
Now it shows the avatar of all employees in the list view.
closesodoo/odoo#78758
Taskid: 2674062
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Removes the ability to select a portal user as time off manager for an
employee.
This also adds a domain to restrict the time off manager on users that
have access to the employee's company.
TaskId-2671420
closesodoo/odoo#78605
Signed-off-by: Kevin Baptiste <kba@odoo.com>
I- mediaDialog/linkDialog:
1- Website editor > Add image/link using "/" commands.
2- The mediaDliaog/linkDialog will be shown to select item.
3- Click on "Add/Save" without selecting any image/setting
any link.
4- traceback.
II- mediaDialog (Video):
The same flow for videos will add an empty <iframe> (with
no src specified) to the DOM.
The goal of this commit is to prevent this behaviour
by adding a test on values passed to the 'save' event
listeners.
task-2628964
closesodoo/odoo#78967
X-original-commit: 1e5c7d6f3525823101215cb18b44d2b936c9c521
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Seems like depending the pillow version, the output image size could differ
from one or two bytes. Now we check the expected size with a tolerance of
+/- 1 byte.
closesodoo/odoo#78965
X-original-commit: 42d3427975592a914b5a61aee304d499750e8afe
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
ISSUE:
The width of menu items is computed (in 'initAutoMoreMenu')
to check for overflow and fold extra items in a "+" dropdown.
[1] When the page is not in cache yet, the width is computed
while font is not loaded yet and the value obtained is not
the same when font is already available [2] (e.g. if we go
to another page).
This explains why we get an additional folded item comparing
[1] and [2].
The goal of this commit is to fix this behaviour by recomputing
the width after font loading.
IMPORTANT REMARK:
When the code was overridden on 'initAutoMoreMenu', the idea
was to update the menu as soon as the DOM is available and add
adjustments after in this order:
[A]- _adapt();
[B]- await _afterImagesLoading(...);
_adapt();
But since it's not possible to prevent the changes in menu
width after images are loaded, we remove the first update
in [A] (This update has no effect in current code because
it was placed after the "await..." in [B]).
And we still start the updates on menu after image loading.
task-2618929
closesodoo/odoo#78959
X-original-commit: 69b97d8e95da3efa62882228e79dc357e19e0fe6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The current code in 'initAutoMoreMenu' doesn't work properly
on navbar after the update on dropdown in [1]. Small tweaks
were added in this commit to fix that.
[1]: 84715436d87bb05b421bc9ccaacda67d07571690
task-2618929
X-original-commit: 29b9280c44534d2f210dbcea83e0049365949f48
Part-of: odoo/odoo#78959
Steps to reproduce:
==============
1) Go to Project app and create a project A if you don't have any project.
2) Go to Project > Configuration > Settings.
3) Enable the "Project Stages" feature.
4) Go to Project > Configuration > Project Stages.
5) Show the Email template field in the list view and set a template on a stage. (create a stage before this step if none exists)
6) Go to the main view of Project App.
7) Move Project A to the stage with the template set.
Expected Behavior:
==============
The system should use the template for the mail tracking.
Current Behavior:
============
Traceback because the method `xmlid_to_res_id` does not exist in `ir.model.data`.
Task-2677199
closesodoo/odoo#78947
X-original-commit: 1d1eaad402dac523404296024f44d3c852ee1daf
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In the new version of Odoo and in the drivers we "map" the actions.
The "mapped" functions must take at least 2 variables as parameters; Self and Data
closesodoo/odoo#78912
X-original-commit: 86653d2024075129c3f52390abdce0abb8d8ec31
Signed-off-by: Masereel Pierre <pim@odoo.com>
Assign a search_range for calendar_end in the _adjust_to_calendar method in all conditions.
The search_range was only assigned a value if the start and end are on the same date before.
The _adjust_to_calendar method receives a start and end from midnight to midnight in the resource timezone.
Start and end datetimes can be set on a different day via the Gantt view set in month or year for example.
This commit ensures that a search_range is always assigned to find the calendar_end and not only when start and end are on the same day.
This allows to find the end of a shift searched over two days if the employee is only working one day.
Task-2628876
closesodoo/odoo#78746
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Same fixes for the purchase scope
1) Do not overwrite lines description if the line was not modified
2) Correctly recompute prices/sellers on quantity change.
When no new line was added to the PO through the matrix, the
prices/sellers were not recomputed, even if the qty was modified for
some products.
closesodoo/odoo#78971
X-original-commit: 591e424fd29856c1ce05ef3436db7f129fb29c2e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) Do not overwrite lines description if the line was not modified
Fixes#78833
2) Correctly recompute prices on quantity change.
When no new line was added to the SO through the matrix, the prices were
not recomputed, even if the qty was modified for some products.
The prices have to be recomputed in this case since pricelist provide
rules based on minimum qty.
X-original-commit: 4f819438aafead57d6bc79e03f9a7980c6420783
Part-of: odoo/odoo#78971
Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value.
This value is extracted during the pricelist price computation (but not used anyway...).
But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value. In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment with the same values (user, context, ...) exists.
During this comparison, the new context, with an id (int) as `partner` value, is compared with existing contexts, potentially including some with a recordset on the same key. Such a comparison fails on the lowest `__eq__` level, raising "Comparing apples with oranges" error.
This commit fixes this case, by making sure the value put in the `partner` context value is always a recordset, and not an id.
closesodoo/odoo#78963
Note: In the future, this context key should be dropped because it's still a bad practice to put recordsets in the context.
Forward-port-of: odoo/odoo#78950
Forward-port-of: odoo/odoo#78276
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Some records have NULL create_date. In that case we get a traceback like
below.
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 259, in _compute_avatar_128
super()._compute_avatar_128()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 62, in _compute_avatar_128
self._compute_avatar('avatar_128', 'image_128')
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 263, in _compute_avatar
super(Partner, partners_with_internal_user)._compute_avatar(avatar_field, image_field)
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 39, in _compute_avatar
avatar = record._avatar_generate_svg()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 66, in _avatar_generate_svg
bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp()))
AttributeError: 'bool' object has no attribute 'timestamp'
```
Observed during upgrade request 40906
closesodoo/odoo#78945
X-original-commit: 559d53fd2a0d437fae595dd4700f2607c8de81a8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The validation error raise
"AttributeError: module 'odoo.exceptions' has no attribute 'ValidationEreror'"
Instead the the correct message
"Member assignment domain for user %(user)s and team %(team)s is incorrectly formatted
closesodoo/odoo#78943
X-original-commit: a7ae22d0206eb833d584755e55351c41a12fd274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit,
it was raising an error while try to preview the certificate
after this commit,
prevent the preview of certificate, as it is not possible to
set the preview of certificate
task- 2623276
closesodoo/odoo#78911
X-original-commit: 8c51d83855566cb21578f18ebf460cead484aed2
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Hide the "Clear All" button next to "Assign Serial Numbers" button when
there are no move lines to clear.
Follow up to task: 2426281
closesodoo/odoo#75676
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.
Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`
Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)
Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`
But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received
opw-2600221
opw-2613116
closesodoo/odoo#78858
X-original-commit: 0c8ea86fb8d706af139cd2d412d01487e5899df6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
and in the notification zone.
part of task-2634175
closesodoo/odoo#78865
X-original-commit: 88fc69c06e4f1516c8d95812395f1e2fbf10f44c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
1. Log on odoo with a user A on mobile device
2. Log on odoo with a user B on desktop
3. User B call user A
4. User A answer the call and the keyboard popup on the screen => BUG
To avoid this behavior, we disable the input auto-focus when we open a
chat window like other chatting app on mobile devices (like: Signal,
Messenger, WhatsApp...)
closesodoo/odoo#78864
X-original-commit: cf36921df8dff114f26a161c4f9d2f6a05ac2adb
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently the runner kinda sorta tries to run the message pump when it needs a message, but it makes for messy and convoluted code as the "request/response" callers have to deal with a bunch of events they don't understand or care for, and can lose other people's events entirely.
Try to use a more evented model: the downstream from Chrome is handled by a separate thread which can handle all events and responses somewhat uniformly. Request/response callers can register their desire for feedback and get a nice `Future` to wait on (or add a callback to).
Also:
* removes the failfast mode of JS tests as that mostly just makes fixing tests more annoying (as only one failure is shown per run)
* fix a hitbox bug in calendar on Chrome 94
* fix a somewhat latent race condition in the qunit test suite / runner, which triggered during the POS qunit run (and is now a hard failure)
closesodoo/odoo#77735
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* remove `component_extension_tests`, that's a test from web and
already tested by web, no idea why it's rerunning in POS
* remove all failfast specs, after discussion with ged, seb, and
xdo it was considered not useful: it's mostly for the runbot but
turns out to be pretty minor as far as positives go, and it makes
fixing errors much harder
Part-of: odoo/odoo#77735
By delaying the check of `didLogInfo` until run end, it becomes
possible for the test suite to start running before all the test
modules have loaded, which leads to some of the modules loading after
the test suite "ends" and start running at that point, leading to
multiple teardowns of the test suite.
This would occur in the POS test suite, leading to the `QUnit.done`
callbacks running multiple times, and multiple `"test successful"` to
be emitted.
This has historically not been an issue (hence having remained
undiscovered), but with the "success state" being a `Future` it now
breaks the corresponding test, as a resolved future can not be
re-resolved.
Part-of: odoo/odoo#77735
The new handler changes the behavior of `wait_ready`: before it would
wait for the `ready_code` to be `true` *or a settled promise*.
Now it waits for `wait_ready` to resolve to true, whether it's a
promise or not.
Part-of: odoo/odoo#77735
The current system uses an imperative request/response model to a
communication which is full-duplex and thus (hopefully) more suited to
a reactive approach.
This updates the Chrome runner to:
* use a separate thread for reading from Chrome, which limits stalling
/ buffering
* uses futures for request/response cycles
* uses a callbacks system for events (unrequested messages from
chrome)
The test end (success / failure) is also signaled via a future.
This requires a bit more cleanup as the browser is reused for all
tests of a *class*, so e.g. the results future must be reset between
tests.
Also for convenience add debug logging of WS requests / responses,
it's convenient for looking at a test / tour's traffic.
Part-of: odoo/odoo#77735
How to reproduce the problem:
- Install hr_timesheet and create a project.
- Create a task in the project, and assign a Partner as the Customer
- In the Timesheet tab of the Task, add a new entry. Save the Task.
- Edit the task again and change the Customer. Save again.
-> the partner on the Timesheet entry did not change.
With sale_timesheet, the Sales Order Item of the timesheet entry can
be updated from the Sales Order Item of the Task, but it isn't the case
with the partner, which is not logical.
Solution : Now, the partner_id is computed and will automatically be
updated from the Task's Customer/partner_id. If sale_timesheet is
installed, it will first filter out the invoiced timesheet entry:
we don't want to change an already invoiced entry.
opw-2616784
closesodoo/odoo#78861
X-original-commit: 200a16ee15c0f2f2d07367eee984aaedccd26a6f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.
Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report
Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`
Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report
Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)
Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.
OPW-2611892
closesodoo/odoo#78853
X-original-commit: f4df8b5eec788cf701e58b02a4be58266d5ddc71
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a componentes is in a modal and uses the positioning hook (filter dropdown in the Search More modal for example), it will shifted from the toggler button.
This is due to a `-webkit-transform: translate3d (0, 0, 0);` applied on the `modal-body`
which influences the `position: fixed` attribute of `.o-popper-position` in the `dropdown-menu`
"It is positioned relative to the initial containing block established by the viewport,
except when one of its ancestors has a transform, perspective,
or filter property set to something other than none (see the CSS Transforms Spec),
in which case that ancestor behaves as the containing block. "
See: https://developer.mozilla.org/en-US/docs/Web/CSS/position
the translate3d was applied with https://github.com/odoo/odoo/pull/20314
As the bug is no longer exists, we can remove this style.
opw-2668638
closesodoo/odoo#78775
X-original-commit: 1f86e285aeb69578378cc89771cd090cc29ccc7d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
- Improve _search methods of stock/product by using subqueries
- Improve efficiency _search_on_hand of stock.quant (see
odoo/odoo#77190)
closesodoo/odoo#78847
X-original-commit: 82562cc25c10500d30056ca19d816c1d211a24eb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Expected behavior : The order button should go green and active when you 'unskipped' an orderline
Current behavior : The order button doesn't go green and can't be clicked when an orderline is 'unskipped'
Steps to reproduce the error :
First of all, you need to setup a PoS Restaurant with these options :
~ Bar/Restaurant
~ Enable `Table Management`
~ Enable and setup `Order Printer` with IP Address and choose Categories to be printed on.
1. Open a restaurant session
2. Pick a table
3. Select a product and put it on hold
4. Select the **same** product and order it
5. 'Unskipped' the product from step 3
Order button should be green and active but is unactive so the order can't be sent
Previously, the condition was only based on the product_id so error occurs when multiline of the same product are handled
opw-2557518
closesodoo/odoo#78850
X-original-commit: 8159e5ac93b18d147fc8688f1dc48f75cbd44a9b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce:
- On bank journal set the outstanding payments accounts and the
outstanding receipts accounts, respectively to 101403 and
101402
- In Accounting > Configuration > Settings > Default Accounts,
let the two outstanding accounts empty.
- Customer > payment > create a payment : payment type "Receive",
amount 5 for example. Save it.
- Edit the payment and change the payment type to "Send".
- Click on Save.
Issue
Got an UserError "Cannot create unbalanced journal entry"
Since the payment_type has changed, the computed outstanding_account_id on the payment is recomputed.
When splitting journal items using the _seek_for_lines() method, odoo is not able to retrieve the liquidity lines since outstanding_account_id has changed.
opw-2620046
closesodoo/odoo#78866
X-original-commit: 865c5d7741ca1bf003b4181d06484cc4ecaf8fcb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
The commit 6135b04 forgot to remove from the assets_frontend bundle
the DebugMenu which depends from the @web/core/commands/... features.
closesodoo/odoo#78863
X-original-commit: 60f000a3d538cbc64f86aeef8aae66149d60ff7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
quotation_description on the sale order is copied from the
product template, where it already is sanitize_attributes=False,
and it has to stay like that because otherwise widgets like
"tab" or "accordion" cannot be rendered correctly.
This is also linked to a bug in the ORM where the _related_attrs
weren't copied correctly.
Related ORM PR: https://github.com/odoo/odoo/pull/78687
Ticket link: https://www.odoo.com/web#id=2487749&model=project.task
opw-2487749
closesodoo/odoo#78836
X-original-commit: ee90f6bcea35350efa9eae8db749199b39ff5644
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
After some analyze on a lot of customer databases, seems like most of the time
their are performance probleme, and big store, it is due to a lot of big file
uploaded without reason. E.g. barcode, photo, ... a small one will be enough.
Now, we decided (in stable) to auto resize these pictures to 1920x1920px
by default and compress it with a quality of 80 when the source is bigger.
You can bypass this behaviour in your specific use case,
using a context key: 'image_no_postprocess' set to True.
You can disable the resize (and quality implicitely)
using an icp: 'base.image_autoresize_max_px' set to '0'.
You can change the default resize (1920x1920) format using an icp:
'base.image_autoresize_max_px' set to '<width>x<height>' (e.g. '1024x768')
You can change the default quality (80) using an icp:
'base.image_autoresize_quality' with a value between 0 and 100 where 0 skip it.
You can change the type of file that will be post process using icp:
'base.image_autoresize_extensions' (subtype of the mimetype comma separated).
Api of image has not be changed in this commit, only refactored to allow to
work with image directly without the need to encode/Decode in base64 the raw.
We decide to keep 1920x1920 by default instead of 1080p to avoid to resize
portrait picture in 1080px and stay consistent with field image_1920 that
return a 1920px image for width or height whatever the orientation.
+ fix some lint diff for ci style in master
closesodoo/odoo#78556
X-original-commit: d9ce0507960f247e1187baf7bd8399f90be237aa
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
There exists an optimization when creating fields to avoid calling
`setup_models()` for fields when creating a custom model, since the
latter already calls `setup_models()`.
We add the same optimization for field selections, so that creating a
custom field with selections only calls `setup_models()` once. Note
that both optimizations are combined when creating custom models with
selection fields: `setup_models()` will be called once for all.
closesodoo/odoo#78514
Related: odoo/enterprise#21746
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, trying to create a field related to another field in
the same batch raises an error, because the computation of the field
'related_field_id' cannot find the target field in the registry.
The new approach consists in getting the target field from the database
instead. It works when creating fields in batch, because all records
are inserted into the database before the field is computated.
This costs extra queries, but it allows to batch field creation and
avoids multiple calls to setup_models() when creating a model with
partner field in Studio. (see odoo/enterprise#21746)
The creation of a simple custom related field (related="x.y") costs 3
additional queries to determine the target field:
- 2 queries to get a given field on a given model
- 1 query to get the first field's comodel
Part-of: odoo/odoo#78514
The real overhead of creating a related field is actually two queries:
- one query in update_db_related, the purpose of this test
- one more query for _compute_related_field_id in flush()
With the previous version of this test, one prefetching done in the
first create was not present in the second create since it was in cache.
The fix clears the caches to make the creation of both fields in the
same situation, such that query counts are compared in a fair way.
Part-of: odoo/odoo#78514
Registry updates can be quite expensive (on the order of a second).
When creating new fields, this update is performed *for each field*,
leading to sub-par performances when bulk-creating fields.
Also remove `_existing_field_data` which has been unused since
9afce4805f, and the `clear_caches`
set up for that purpose.
Part-of: odoo/odoo#78514
When using a profiler manually inside the code, and longpolling uses
this part of the code, an error will appear on runbot since gevent
server cannot be profiled properly.
This fix mitigate the issue by disabling the profiler automatically in
this case.
Part-of: odoo/odoo#78514
When installing a database with all modules in enterprise,
install take around 20 minutes and almost half of that is spent in the
`setup_model` method.
There is actually two calls to `setup_models` for each module.
One of them was introduced in b5c50fa824
and only looks useful when upgrading a module with migration scripts.
This first fix proposes to skip `setup_models` if the module state is
`to install`.
closesodoo/odoo#78808
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Harald Panten