ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Importing 100 records and getting 100 errors (often the same every
time because a required field was not mapped) is not super useful and
spams the logs a lot.
Cutting off at one point seems useful.
Note: integrates warnings-related fix from #47972 reported by Grzegorz
Marczyński in #47936.
closesodoo/odoo#48095
X-original-commit: 6b05f1d13c862dd66e89f35607d072315be80995
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose of this commit is to improve english wording in Odoo
regarding res.partner.industry model.
For that purpose we rename "Sectors of activity" with
"Industries" everywhere we use that naming.
Original feedback #2212682
Task ID #2214290Closes#47559
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, url_lang (= url_for) will make query to find the lang_code
but we alrady have this info in ormcache with get_available method.
So instead to rebrowse (search query) the lang, we use a new method that will
try to find it in cache if possible before to make the query.
The gain on each page is n-1 (where n is # lang installed)
Because the switcher of languages do an url_for for each lang available.
Related to #47257
task-2211013
X-original-commit: 2cecbe356ce283e15fb0bbd0a6e9aa4735af520e
Before this commit, we compute the hash on each request, to know if we need to
download the file from the frontend or if we can use cache.
Now we store the hash computed in cache. The cache will be invalidated when we
touch one of these translations (openerp-web in the comments) or when you
install a new lang (already the case).
+ avoid to use read on a record, since it will not use the cache from record.
Related to #47257
task-2211013
X-original-commit: d5aaecbc51de19ef1d8d9988b691177fc73a4b86
This warning should only appear when Chrome is used.
closesodoo/odoo#48009
X-original-commit: 013b32f000520217af17b6e1ffe1872ec97afdf0
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
* from collections import <ABC> is deprecated, unclear why the
deprecation warning didn't appear before (possibly only appears in
3.7/3.8?) either way `collections.abc` should be 3.3+ so switch
everything to it.
* add some more ignores on third-party packages deprecation
warnings (meh)
* while at it, mitigate generation of non-breaking space on some
versions of Babel (in the french locale used by our tests anyway)
closesodoo/odoo#47581
Related: odoo/enterprise#9214
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, when a user try to import data with a XLSX file, the
file was mistaken by an SVG file. This issue arises because a XLSX file
from import isn't encoded in base64, and for testing if the file is an
SVG file it will be decoded. base64.b64decode by default (when validate
is False), will remove all characters that are in the base-64 alphabet
from the input prior to decode. So in our case, when the non encoded
XSLX file is force decoded the results starts, unluckily, with '<' and
it's mistaken by an XML/SVG file. Note that, the XSLX file is wrongly
tested because a XSLX file is just a ZIP file, and all the ZIP files
start with PK\x03\x04, and P is the first byte of a base64 encoded XML
file.
Now, only files that were previously encoded into base64 are decoded to
be tested. The validate = True parameter in base64.b64decode will raise
a binascii.Error if there are a non-base64-alphabet characters in the
input, this will allow us to know if the input was or wasn't base64
prior encoded. As base64.b64decode with validate = False, removed the
non-base64-alphabet characters this allows to decode input files
compatible with RFC 2045 (MIME). The files compatible with this standard
will have a newline character (b'\n') after every 76 bytes of the
output, and end with a newline. To keep backwards compatibility, we
remove the newlines and the carriage return from the input before the
decoding.
opw-2194468
closes#36081closes#31849closes#33543closesodoo/odoo#47906
X-original-commit: 65d709c9ab386d646f682c494cfb21cb06ec8034
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
When passing a view
from `active` `False`
to `active` `True`,
its xml wasn't being checked, and it could be very well be invalid.
e.g.
Create a view inheriting from `base.view_partner_form`
`active` set to `False`
`arch` set to
```
<field name="foo" position="after">
<field name="bar"/>
</field>
```
On creation, the `_check_xml` constraint is valid because the view is disabled.
Now, write `active` to `True`. Notice no constraint error is raised while the view is invalid.
This is particularly critical now that we automatically disable invalid custom views
during upgrades. When the user tries to re-enable the view which has been disabled to see
what was wrong, he doesn't get any error because of this.
closesodoo/odoo#47897
X-original-commit: fb2aeb29cd62e02ca5485e5b60d6b61ae4acc252
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When uninstalling a module, all related ir.model.data records are
unlinked, if the unlink fails, a dichotomy is performed until all
records are unlinked.
It happens that a record appears in both part of the dichotomy. In that
case, the record is deleted in the first part. When second part records
are unlinked, a crash occurs because the record cannot be found anymore.
With this commit, sets are used instead of lists to store the records
that need to be removed, avoiding duplicates in dichotomy.
closesodoo/odoo#46323
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With this commit, a new script "tests-uninstalls.py" is added in order to
test module uninstallation.
This script is a kind of standalone tool. It uses odoo as a library but
the odoo server is not started at all.
In its standard invocation, it tries an install/uninstall/reinstall
cycle for each all module found in the specified database.
By specifying '-U', it only tries to uninstall the comma separated list
of modules following the argument.
Be aware that this tool, will alter the database against which it was
invoked.
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit adds the possibility to compare a view arch to another one.
The result will be shown in a diff viewer (github like).
This is following what was done at #32009
task-2190072
closesodoo/odoo#44646
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the query to fetch records with/without relations would be
done in a separate query which results would be then passed to the main query.
This commit adds this query as a subquery of the main query to do it in the
same SQL query instead of separately.
task-2211013
closesodoo/odoo#47729
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:
The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.
This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries
Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.
This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)
A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.
closesodoo/odoo#47283
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Combining a state and attrs does not work
Apply all in the same domain
closesodoo/odoo#47676
X-original-commit: 3588487ab4ef867f7fb981a395deaf298eb4a4e4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The `__closer` attribute is filled with the origin of a call to
`cr.close()`. That information is reused in the `check` decotator that
ensure the user is not using a closed cursor. In case he is using a
closed cursor, an error is raised with that optional origin in case of
`--log-sql`.
The attribute is a dundler so it is only accessible within its class, as
the decorator has been moved outside of the class by 058cf208a8 it is
not directly accessible thus `__getattr__` is called as a fallback. The
`__getattr__` itself is protected by the `check` decorator thus they
call each other in a infinite recursion.
As the related dundler is no more used internally, it has been decided
to remove it entirely.
closesodoo/odoo#47616
Task: 2199895
X-original-commit: 3ebf7cb9cca37b05f44aaffc0b1f289cc65f300f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this, the master version is the next major version without taking
intermediate saas versions into account.
Depending on the point of view, one or other choice can make more sense. Anyway,
master is always closer to next saas than next release.
Using next major release can be problematic from a technical reason, mainly for
upgrade scripts
A simple exemple is to write upgrade scripts for master. The script version
will be something like 13.3.1.2 since next saas is saas 13.3 and module version
1.2. The problem here is that installing a database in master will have module
versions setted to 14.0.1.2 since release.py indicates that version is 14.0,
making it impossible to test an incremental version script 13.3.1.3 in master
(will never be executed, 13.3.1.3 < 14.0.1.2)
Another exemple is when testing migrations on a not-rebased branch.
Hypotetically if all upgrade scripts are linked to a specific
version of a module (module version is incremented each time a
upgrade script is added), someone using an old version of the master
won't have the script 13.3.1.3 executed if current module version is 1.2.
(which is not true now since module version will be considered to be
14.0.1.2 (> 13.3.1.2).
closesodoo/odoo#47281
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The function get_inheriting_views_arch, retrieves the architecture of
views that inherit from the given view. In the case of the module init
is currently in process only views from modules whose code is already
loaded are taken into account.
Before this commit, the function didn't process views that has been
copied (copy on write, web editor, customize show, manual copy, ...),
this raise an error when trying to install a module. For example,
install module website_sale, copy on write the view 'Main layout',
install module website_sale_wishlist.
Now, views that has been copied are also processed.
opw-2181968
closesodoo/odoo#47590
X-original-commit: d5a2890b30f869c9b4cf7aafed0e05aff9440360
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
The method `recompute()` should not recompute fields on new records.
This is both a speedup (those recomputations are not necessary), and
fixes an error following an `onchange()` (a field recomputed in an
environment with the wrong context.)
OPW 2184998
closesodoo/odoo#47545
X-original-commit: fa852ba1c5707b71469c410063f338eef261ab2b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The synchronisation of commercial_partner_id was introduced at
0d68acff8e as a way to ensure the value is always correct.
The order or the operation was not important though.
This synchronisation has a side effect in the following scenario:
0. install base_vat
1. disable vat_check_vies in the settings
2. set an invalid VAT number on a company with at least one contact
3. enable vat_check_vies in the settings
4. correct the VAT number on the company with a valid one
--> an error was raised for an invalid VAT number on the contact
This is because the commercial_partner_id synchronisation is done
before the update of the VAT number. Even if the value has not
changed, this triggers the check_vat method.
Invert both instructions
Courtesy of Wolfgang Taferner
Closesodoo/odoo#43065Closesodoo/odoo#42973closesodoo/odoo#47543
X-original-commit: d9b2605eadc129924d085fffc4056d777cfbbbeb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
When incoming emails bounce due to alias security bounce email is quite
generic. Purpose of this task is to ease its customization and update.
SPECIFICATIONS
In order to improve the flexibility of alias, add a customizable html field
on the alias model. This html content will be send as bounce email core content
in case of bounced/unauthorized mail received for this alias,
Obviously it has no effect on 'everyone' security setting as no email will
bounce due to that issue.
If it is not set a default generic mail will be send depending on security
setting. It allows to keep void html fields when no specific bounce content
is required
In HR, an old template allowing some light customization for employee based
security option is removed as it is completely replaced by the new feature.
Also add references message-id of the mail received to the answer so that
threads are correctly set.
LINKS
Task ID 2126509
In odoo empty html is not always completely empty. This tool method allow
to consider html holding void tags as empty html. This happens notably when
using the editor that may store <p><br><p> even if displayed content is void.
Task ID 2126509
PR #41827
Before this commit:
- Install a module
- Uninstall the previously installed module
- The registry will complain that some dependencies may be missing
for the module being uninstalled
This happens because we check after the installation / upgrade of
modules that none have been left in a transient state to verify that new
dependencies have been properly installed and loaded, this applies to
'to install' and 'to upgrade' states however it's not the same for 'to
remove' states, as the process of uninstall happens much later in the
code.
After this commit, simply uninstalling modules will not trigger this
error log.
Do note that in case of a problem with an uninstall, the function
"reset_module_states" will tackle the case of leftover transient states.
closesodoo/odoo#47495
X-original-commit: c095a28314f78d1d9854e5e9bcb26014922a4f12
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When testing odoo, errors can occur an undeterministic way, wich can
lead to strange and unreproductible behaviour. This also means that the
performance can change from one execution to another, making it quite
difficult to track performance variation on a global scope.
This commit makes the result of `exists()` deterministic in terms of
order. The side effect is to keep record ids in the same order as the
original recordset, which may be useful.
closesodoo/odoo#47282
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Before this commit:
- Install some random module that can be uninstalled (so not base)
- Open the uninstall wizard for said module in two different tabs /
windows / whatever
- In one tab, confirm the module uninstall and wait for it to be
done
- As soon as the other tab is done with the uninstall, go to the
second one with the uninstall wizard still open, and proceed
with the second uninstall
- Boom, the registry crashes and completely fucks up the DB because
there's no check at all that prevents the uninstall of already
uninstalled modules.
After this commit:
- `ir.module.module.button_uninstall` will check if all the
modules being uninstalled are in the installed state
and if not a UserError will be raised, preventing a second
uninstall of the module which could potentially break the DB
Do note that this fix is LOCAL, the problem is however more or less
global, wherever there's user-actionable buttons that should only be
pressed once there's a potential for bugs / breakage if a similar fix is
not implemented locally. Perhaps a more global fix should be implemented
eventually, but it's generally less annoying for business cases since
those probably won't break the registry, see task 1859014.
opw-2213679
opw-2212594
opw-2206446
closesodoo/odoo#47450
X-original-commit: 8c1bb22ec0222dca652e0649454b986c06cb1368
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Before this the `--unaccent` flag does double duty to specify whether
to create new databases with the extension *and* to try to use the
corresponding function.
The latter is further gated on the function existing at all in the
database.
Given postgresql does not have unaccent installed by default it seems
only the latter is really useful and we can ignore the flag to decide
whether to enable unaccent features, if the extension is installed
consider that it should be enabled and move on.
Merge this in master rather than previous versions as it can change
things like index access / use.
closesodoo/odoo#47377
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit adapts some existing steps or add new ones to execute
the same tour on mobile.
This tour has many steps and give a good idea to know if new tasks
broke mobile or not.
The goal is that even if the design isn't perfect, users aren't blocked
and are able to perform their usual tasks.
Task ID: 2149402
This commit moves some step utils in a dedicated file and add new ones.
These steps will be very useful for the Main Flow Tour to avoid
duplicated code.
To do this, we also had to transform it into functions to allow
utils to call each other. Existing one are converted for
standardization purpose.
Note that 'WEBSITE_NEW_PAGE' wasn't considered as an util.
This is a very simple step only used twice.
In this commit, we are still running the main flow tour on desktop
but we also run it a second time on mobile.
It's only available in enterprise, otherwise the test will be skipped.
'375x667' correspond to the Bootstrap XS size.
This value is already used for the mobile tests suite.
Task ID: 2149402
Note that tours shouldn't be language dependent.
By using XMLID's we are able to find a menu even if the tour
is running in another language.
The tip has been moved slightly but it's not a big deal,
others selectors menu already used XMLID's.
The unaccent extension was installed only at restore, not at creation
of a database.
Make both consistent.
closesodoo/odoo#46534
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
A future upgrades improvement will be to add tests in upgrades
modules. This small imp will scan in upgrade for some tests,
specific tooling will be added to upgrade repository in odoo/upgrade#878closesodoo/odoo#47030
X-original-commit: 59b5a03bdf7ae1ad8851a67d278edc31a26a96a8
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, one could create a custom, non-stored m2m field
through the web interface BUT the deletion of the custom field would be
impossible after saving the form.
This is due to the fact that the relation would not be stored in DB
since the field is store=False, therefore the value of the relation
would equal to None, and since the unlinking mechanism assumes that
the value is never None, it tries to drop a table of name None, which
does not exist.
closesodoo/odoo#46909
X-original-commit: cdd1439a380810569db80d984c8cb80d213b1bf3
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Before this commit, x2m fields were described as 'sortable'
This was odd since:
- When actually sorting on one of those fields through the webclient
the sorting was gibbrish
- Even the orm silently warned in the log that
the field was not a sql column and therefore was not sortable
After this commit, only a field which is column (and a few other conditions)
can be sorted
Task 1863492
closesodoo/odoo#46921
X-original-commit: dd3094378fc322447d1aef994f6bace3f0c24288
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- In some cases One2many fields defined as computed without
inverse field defined could cause crashes if it is used
in a search.
This should not be done, but shouldn't crash either.
With this fix, trying to search on one of this fields
would just print a warning.
closesodoo/odoo#46742
X-original-commit: 4b4f1623590f2e872c565e8e56002bc3f5bf9efe
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Before this commit, the amount currency could be wrapped on a
second line (on mobile).
To fix this, we had to find a way to have more space:
- Buttons are now displayed at the top (mobile only).
- Amounts can grow (col-auto) and the other column will take the
space left (col) and add "..." when there is not enough space.
(mobile + desktop)
We also had to remove a button from a div tag in order to display
the buttons next to each other on mobile (buttons are "inline-block"
but div is a "block").
The main flow tour has been adapted accordingly and the typo has
been fixed too...
closesodoo/odoo#46680
Task-id: 2184243
X-original-commit: 159e3d4cb8a301c908f7718a56138528033e75d4
Related: odoo/enterprise#8963
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the company specific colors and font were
implemented by systematically overwriting a "virtual" report SCSS
asset file before rendering each report.
This caused many issues, forced frequent asset bundles recomputations
(performance problem + cache invalidation causing random bugs).
And it could simply not work in a multi-company setup where multiple
styles are involved, as the asset management could be made not
thread-safe.
PR #44225 was a first attempt to mitigate the numerous problems by
making the asset bundle invalidation less frequent. But the problems
were still present and a more complete solution was necessary for
multi-company setups.
Besides, the design of the bundle forbade making company specific assets.
This commit uses a different approach: instead of having a
company-specific asset that needs to be constantly updated, a global
"multi-company" asset is maintained and included in the report assets.
It only needs to be generated when a company style changes, not for
every rendering operation.
Unfortunately this change cannot be fully performed without updating the
template declarations, so it will require an update of the `web` (or
`base`) module to be operational.
As this represents a rather invasive change in a stable branch, extensive
testing was conducted to minimize the effects and ensure proper
degradation of features for production deployments where the new code
would be deployed without forcing an update of the `web` module:
- The report SCSS files were left untouched, to prevent any bundle
invalidation, ensuring that old cached assets would remain valid. This
means that single-company setups should not see any visible difference
after pulling the code (with or without updating `web`).
SCSS cleanup will be done later.
- Existing Python methods were kept but emptied, to make sure that
old templates and code would not crash.
- For multi-companies, the last used colors will be applied for all
reports until the `web` module is updated. The old behavior was not
working correctly anyways, so the degradation is actually limited.
- For all setups, changing the colors after deploying this patch will
have no effect unless the `web` module is updated.
/UPDATED FOR master on top of #44393/:
- removed the `res_company.update_scss()` method entirely
- fixed the report SCSS styles, as the variable names referred to the old
behavior, e.g. "$o-company-primary-color" is nonsense.
Renamed to "$o-default-report-primary-color" etc.
--
Improves #44225
Forward of #44393
opw-2168623
opw-2171040
closesodoo/odoo#46647
X-original-commit: a5b1421aecf27b1de408434d3bb6d7ac81f57dc3
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Victor Feyens