This commits adds a message to the module import wizard to make it more
clear what kind of modules can be imported through the front end.
project : RD feedback
task : [base_import_module] what it is not for.
opw-1939967
closesodoo/odoo#31057
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
- Create a simple module, set version to 2.0
- Import the zip file
The 'Latest Version' (field `installed_version`) is set to 11.0.1.0,
while one would expect 11.0.2.0.
There are several reasons for this. First, the method
`get_values_from_terp` doesn't return the version, so at this point the
information is already lost. Then, the field `installed_version` is a
computed field which retrieves the version from the `__manifest__.py`
file. In the case of an imported module, there is no such file in which
we can look up for the value (even though the imported module contained
one).
To avoid this, we explicitly set the 'Installed Version' (field
`latest_version`) to the version retrieved at import. Since this field
refers to the version installed in the database, it makes sense to use
it this way. Moreover, in the case of imported modules, we use the value
of `latest_version` for `installed_version`.
Fixes#23988
opw-1833522
Before this commit, while performing a check on whether a customization
being imported was done using studio or not, we would assume that the
.zip would, at the very least, contain a data folder.
This is not the case as loose files can be imported and the data folder
is only generated by studio customizations.
To solve this, we walk over the whole zip instead of walking over the
data/ folder only (which may be non-existant), so loose files, files
inside the data folder and potentially files in other folders can be
parsed without raising unexpected errors.
