Despite being part of the requirement.txt, xlrd apparently was still
optional-ish, and absent from some environments like the iotbox.
Restore this by only monkeypatching xlrd if it's actually present.
closesodoo/odoo#63045
X-original-commit: c36aa16c2cc431a1e3b3bb7047dbae4fcac13946
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The parsing of external ids was made with the regexp `(\w+)\.([\w-]+)`.
This regexp is inadequate for external ids that contain non-alphanumeric
characters like. We have such a use-case with the selections of field
`rating_operator` in module `sale_subscription` that uses the values
`">"` and `"<"`.
The fix consists in replacing the regexp by `(\w+)\.([^ ]+)`.
closesodoo/odoo#63017
X-original-commit: 52bf0e331fb9230423b76b9014bb13d490930e76
Related: odoo/enterprise#15189
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Python 3.9 has 10 new bytecode instructions, for now this commit adds 8
* CONTAINS_OP / IS_OP: moved out of COMPARE_OP which is now only used
for *rich* comparisons (bpo-39156)
* JUMP_IF_NOT_EXC_MATCH: also moved out of COMPARE_OP for the sole
purpose of testing exception types
* RERAISE and WITH_EXCEPT_START (bpo-32949) used to simplify the
context manager bytecode, but RERAISE was then used for
try/except/finally, we don't support context managers in safe_eval
so we don't care about the latter
* LIST_TO_TUPLE, LIST_EXTEND, SET_UPDATE, DICT_MERGE and
DICT_UPDATE (bpo-39320) updates to unpacking (* and **) in various
contexts
* LIST_TO_TUPLE we're skipping as it's only used when calling a
function with two `*arg` parameters (aka `foo(*a, *b)`)
* SET_UPDATE is used for set literals of 3 or more items or
unpacking ({*a})
* LIST_EXTEND is used in the same cases as well as function calls
with unpacking
* DICT_MERGE is used for function calls with `**kwargs`
* DICT_UPDATE is used when unpacking in a dict literal (`{**kw}`)
See odoo/odoo#59980closesodoo/odoo#62989
X-original-commit: 3d1c7231a080eebb4f6a7d56cbfa5721bf76befd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Old naming has been deprecated for a long time, it's been removed
entirely in 3.9 (bpo-37804).
X-original-commit: c4a94bc99285aba085badeb1a41e8fe04562ef50
This is a minor issue, but determinism is better than non-determinism.
closesodoo/odoo#62904
X-original-commit: 1b0869554d8755f8fdeb73dd2aa2ae7426522e84
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
In case a user has installed a module where the code becomes unavailable or during migration a module was removed and needs to be removed after migration it is impossible to uninstall the module from a database still holding the fields or the models.
In order to disable prefetch based on information from the database it is needed that the module and models of the unavailable module are initialized with related fields and models.
closesodoo/odoo#62895
X-original-commit: e4a1121e572d07cc720ede8c1b1116d4f1d7ae98
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Upon the first call to `onchange`, the `values` dict is filled with
default values. But the fields without a default are left unassigned.
This allows to compute fields when accessing them, but non-computed
fields will ask again for their default value, which is a waste of time
because we know they don't have one. This may even be a performance
issue on forms with many fields.
Fix this issue by completing `values` with falsy values, and consider
the fields with some initial value (given or default) as the assigned
ones for triggering onchanges. This explicitly triggers the computation
of fields that depend on fields with some initial value, without forcing
them to `False`.
Also avoid accessing x2many fields on the record in `snapshot.diff()`.
Enable the prefetching by simply putting the right value in cache.
closesodoo/odoo#62844
X-original-commit: 80c1dad6d9124da9459ce38d9e8c03e5c461c180
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit adds a pylint checker that will check every override of
`BaseModel.unlink` to verify that there are no raise statements within
the body of the method, if that is the case, an error will be raised.
closesodoo/odoo#58517
Related: odoo/enterprise#13557
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
With this commit, a new ORM api decorator is introduced:
`api.ondelete(*, at_uninstall)`.
This decorator is to be applied to Model methods that check for specific
business conditions when attempting to unlink a record via the
interface.
E.g. trying to unlink a validated journal entry
This decorator allows this logic to exist outside the `BaseModel.unlink`
method and is automatically bypassed when in uninstall mode, this means
that during an uninstall any and all data related to a module can and
will be removed easily and cleanly while still being able to apply
business logic to manual deletion of records.
This feature opens the gates to solving a very big problem with
uninstalls: records and tables that remain in a database despite the
relevant module being uninstalled, because if an override to unlink
raises an error, the data will never be deleted from the database.
Henceforth, overrides of unlink shall solely be used for data-cleaning
purposes, i.e. deletion or modification of data that is related to the
one currently being deleted but cannot be automatically deleted because
there are no proper SQL relations.
In certain very specific, low-level scenarios an unlink may be
overridden to raise an error, but this should only be done if you know
what the fuck you're doing, most of the time you'll want to resort to
`@api.ondelete`.
Note that this new decorator includes a keyword-only, required argument
called `at_uninstall`, in most business cases this argument shall be
False as this argument dictates whether or not this method should be
executed in the `unlink` call during uninstall. It should only be set to
True if you are certain of all the implications which most likely means
that the records of the model in which this ondelete function is defined
will NOT be removed during uninstall, they will forever linger in the DB
until manual intervention, this in turn can mean a wide range of
undefined problems due to crap left on the database.
Following commits will replace any `unlink` overrides that raise
business errors by methods decorated with `api.ondelete`, another commit
will introduce a pylint checker that will raise a warning any time that
an unlink override raises an error.
Bug
===
Sometimes, the registration testing tour failed.
The bug can be semi-deterministic if we add a "sleep(1)" in the endpoint
"/event/<event>/track".
Reason
======
The reason for that is the service worker. It will pre-fetch all the
links in the page (see "prefetch-pages"), so for the "Online Reveal"
we will pre-fetch ~100 pages... If the server is slow, it can cause
issues.
If one endpoint takes some time, all other HTTP requests done by the
service worker will be waiting for it.
So, at the end of the testing tour, the service worker will continue to
make HTTP requests (because it makes the request sequentially) and so
some threads will still be created after the tour.
Even if "_wait_remaining_requests" is called to wait those threads, as
the service worker is still running, it will still continue to make HTTP
requests, creating new threads...
Fix
===
The solution to this issue is to kill the service workers of the browser
when we stop the tour before waiting for the end of the "HTTP request
threads".
Task 2381066
closesodoo/odoo#62827
X-original-commit: 6d08408a33880221b28f0f8a81d699825d927a48
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the company recordset returned by
env.company/env.companies
was sometimes in sudo and sometimes not.
If 'allowed_company_ids' was specified in the context, the returned
recordset wasn't sudoed.
If no company was specified through the context, company/companies was
using env.user.company_id(s)
as fallback, which is always sudoed since env.user is always sudoed.
With this commit, the behavior is now consistent, we enforce that the
returned recordset is only sudoed if the current environment is.
As everybody has read access on res.company records, there is no need
to return the company as a sudoed record.
When a specific operation has to be done on the company, then a sudo
should be called if needed.
closesodoo/odoo#62074
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This fixes the issue introduced by revision fd50ba9fb8
The way computed fields are invalidated depends on the order of the dict
passed as a parameter to method onchange(). This causes some unexpected
behavior when dealing with computed editable fields: the user loses the
value in that field because of the onchange.
Explanation: during the onchange, the modified field is cached by
record._update_cache(changed_values, validate=True)
If the field is a one2many, 'value' contains an update command for each
modified line. Because of 'validate=True', the assignment triggers
field computations on the lines, which are already handled by another
call to onchange(). In case anything on the parent model modifies some
line, the whole one2many values are returned to the user, and
accidentally recomputed fields show up in the interface.
closesodoo/odoo#62748
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this change, the apikeys' ``_check_credentials`` override would
hard-check the ``'interactive'`` key. This turns out to be less than
ideal for compatibility with older code which might not properly
forward the environment (or might call ``_check_credentials`` from a
non-override and pass in an empty env) as it straight crashes.
Update the override to assume an interactive login if the information
is missing (as that seems like the more secure option: it ignores
apikeys and takes 2FA in account if enabled). Also trigger a warning
if the key was missing from the environment, such that the maintainer
hopefully takes a look at the issue.
Also allow a ``user_agent_env`` of ``None``, this will also trigger
the warning so seems OK.
closesodoo/odoo#62683
X-original-commit: ee2625a9311f308b9df3fc160dc5c9fe4cc5a497
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
This fix makes sure we can still remove a company from a contact linked to a user.
Related: https://github.com/odoo/odoo/pull/62418
opw:2391464
closesodoo/odoo#62591
X-original-commit: 59413ad88a97b3221526c2b560178a0f94ddee05
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
We provide a new helper class to help redact x2many commands for create
and write methods. To ensure best compatibility with the xmlrpc layer we
do not change the protocole, the commands are still 3-elements tuples
where the first element is still an integer in between 0 and 6. The
helper class provide the cannonical constants and static methods to ease
working with the commands. The new helper class is also available in QWeb.
Developers are encouraged to transition their code so it uses this new
helper class.
Task: 2366606
From python code, import a module class and print one of its field, it
shows garbage because the `model_name` and `name` fields are None. We
provide a default str/repr of the field.
closesodoo/odoo#46996
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The "active" field is a non-working deprecated alias to "auto_install",
it does not work and was confusing users (see #59850). It has been
removed.
closesodoo/odoo#62086
Task: 2361729
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
A manually created decimal precision won't have any impact on the system
unless used in custom code, and in this case, the record should be
specified directly in the custom code datas.
Furthermore, it can still be created/deleted in superuser mode if really
necessary.
closesodoo/odoo#60744
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The names of the decimal precision shouldn't be modified as this field
is used as reference in the code.
Modifying (e.g. translating) the name of a decimal precision will
disable the precision, always using 2 as precision fallback when the
specified precision is not found.
Without this commit, when the compare/reset view feature was reading the arch,
it would translate it.
3 issues :
- When reading from file (hard reset), it would translate the file version
- When reading current arch, it would translate it
- When reading compare view arch, it would translate it
closesodoo/odoo#62521
X-original-commit: 1aa4d3cb57844c24d8520b6b974bb36526392ecf
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Only updates outdated requirements which actively cause issues:
* freezegun broken in 3.8 (removal of time.clock)
* xlrd broken in 3.8 (removal of time.clock)
* also monkeypatches xlrd.xlsx for 3.9 (removal of
Element.getiterator, breaks because of defusedxml)
* jinja triggers DeprecationWarning in 3.8
* pillow triggers warning in 3.9
* lxml, greenlet don't compile in 3.9
* reportlab doesn't work in 3.9
New versions try to match those of Debian Bullseye.
Also adds a script to more easily compare dependency versions between
the requirements files and what's in various distributions (currently
supports checking against debian and ubuntu).
Furthermore updates warnings filtering:
* removes xlrd (mischeck was monkeypatched as noted above)
* removes setuptools (was for older versions, one would hope this
isn't an issue anymore)
* adds babel: python-babel/babel#684 fixes the deprecation warning but
is not part of any release yet
* ignores error related to `random.sample` on a set, this is a
diagnostics bug because recordsets implement both Sequence and Set,
and the stdlib checks for Set first (bpo-42470)
See #59980Closes#61103closesodoo/odoo#62510
X-original-commit: 648635deca67df09417ae55c6eb181c98524b74d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
Create a new local Odoo DB
Create another company on the DB
install the CRM module
Create an opportunity on the CRM app for each company.
Execute This server action (CHANGE THE res_id TO THE IDs OF THE OPPORTUNITY CREATED):
```
for _ in range(0, 300):
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 31, 'type': 'binary'})
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 45, 'type': 'binary'})
```
go to the Settings / Technical / Database Structure / Attachments.
Server will look in endless call because the search try to retrieve
`limit` records, but after applying company record rule we have
`limit - e`, so it begin a second search for e records.
Even the second search will look for limit and possibly will find less,
starting a third...
If the sub call is aware of how much records we actually need after
checking permission, we can return the recordset if we have collected
enough
opw-2369722
closesodoo/odoo#62456
X-original-commit: 6a8f28c4d0f9df7cd8451f4caf4f3bf7d64330da
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
opw:2391464
closesodoo/odoo#62464
X-original-commit: 80902bee453cf485906bb07be6af9072aee2e76f
Signed-off-by: backspac <backspac@users.noreply.github.com>
Before this commit, it was impossible to write to a delegated m2o field
if the length of the recordset was greater than 1.
The reason was because the special case for delegated fields inside
fields.Many2one.convert_to_cache would check for `record.id` which is a
bit misleading, since record can be greater than one.
The solution is to check whether any of the records are real records
instead, as if all of the records are NewRecords, then the parent is a
NewRecord too.
Fixes#62069closesodoo/odoo#62343
X-original-commit: 76bf9dc94165c79be873a8864bfdb50a0a636084
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Same change in several areas where translations existed:
- website editor notification popup
- elearning share popup
- forum remediation filter popup
- event registration attendees popup
- portal rating popup
- stripe payment error popup
And many other locations where there were no translations yet
"×" has been replaced by its UTF8 character.
Also introduced aria-label where missing.
Before this commit the close icon was included in translated resources.
For example, in Spanish the "×" had been turned into "&veces;"
thus not rendering an icon anymore
After this commit the close icon is not a translated text anymore and
remains an icon across all languages
https://github.com/odoo/odoo/pull/60186
task-2312878
closesodoo/odoo#62250
X-original-commit: 9896af94ebc887d98ccf44e6568ef7eeb5a27172
Related: odoo/enterprise#14937
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When modifying a field's decimal precision, the caches are cleared in
order to retrieve the new value from the database. As the new value is
retrieved in pure SQL, one has to flush the updates before doing the
query!
X-original-commit: 8a9617d045c2afda8d804a5863df927012f0692c
During the uninstall step of the registry, we perform a commit right
after the uninstallation of all module data, this commit is performed
right before the creation of a new registry, this means that said commit
will call `flush_env` and thus `recompute` on an environment that is
based on a stale Registry (memory and database are unsynchronized).
This means that during this specific moment, there's a chance that the
recompute function may have to fetch some fields it depends on to
perform its computations if said fields are not in cache, this in turn
means that it will try to prefetch fields that are potentially no longer
in the database, making the registry crash and preventing the uninstall.
This is what happened with multiple if not all `payment_*` modules, the
main module `payment` depends on a `ir.module.module` record, most
notably the `color` field of the `payment.acquirer` model which depends
on the `state` field which in turn depends on the
`ir.module.module.state` field.
This meant that uninstalling a module such as `payment_paypal` triggered
a recompute of `payment.acquirer.color` during uninstall, and to perform
that computation we need several `payment.acquirer` fields to be fetched
from cache or the database. If in cache, the uninstall would go through
without a hitch, if not in cache, we would fetch the required fields
from the database but we'd also attempt to prefetch the fields
introduced by `payment_paypal` that had just been deleted from the
database!
To avoid this, the `_module_uninstall_data` method of `ir.model.data`
will henceforth guarantee that `ir.model.fields` that are to-be-deleted
will have their prefetch set to False, meaning only existing fields will
be fetched from the database during the uninstall of extending modules.
Fixes#60424
opw-2372598
closesodoo/odoo#62247
X-original-commit: 7bffd2df0d5d7eff841cdf7ba7cb6ea84a5c5c49
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
In unit tests, this avoids side effects from one test to another. In
particular, a test modifying the user's company can make other tests
fail because `env.company` defaults to the user's company when nothing
else is available in the context.
The now unique class behaves as the former class `SavepointCase`. It is
now up to the developer to use `setUp` or `setUpClass` for preparing the
tests.
The way QWeb handles text nodes and node tails makes it generate
white spaces copied from the XML indentation even before the first
useful character
Before this commit blank lines appeared at the beginning of generated
documents as well as inside the document content
After this commit no blank lines appear at the beginning of generated
documents and blank lines inside document are removed
task-2366756
https://github.com/odoo/odoo/pull/60850closesodoo/odoo#60850
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Christophe Monniez