When a form view is opened, the first call to `onchange` should always
compute fields, even if their dependencies have no default value. Make
sure it is the case for main records, and for records inside one2many
fields. The latter case was actually not working as expected.
closesodoo/odoo#63646
X-original-commit: 45422d56bce413b8577f1784e10dd22ede93c751
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
To reproduce this issue, install the module "Accounting" in English,
then switch language to Dutch, and go to a user's form. The selection
field for accounting groups is missing from the users' form view.
The source of the bug is the special case introduced for accounting
groups in d8c5cc1335. The groups in that
selection field are not totally ordered, and the non-ordered elements
are de facto ordered by name, which is a translated field! In the
example above, the English version uses the field name
`sel_groups_22_23_24_25` while the Dutch version uses the field name
`sel_groups_23_22_24_25`. Because the first one is used in the form
view, and it is not found in the model's documented fields (which uses
the second one), the field is discarded from the view.
The patch is much simpler than former versions, which are constrained by
the stable branch policy. We simply normalize the selection field's
name by ordering the group ids used in the name.
OPW-2394209
closesodoo/odoo#63462
X-original-commit: 399b4f1ceb31f560ce534ee8d9605ca43733f68c
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Nasreddin (bon) <bon@odoo.com>
This reverts commit d431f94c75 and even
upgrade the EcmaScript version further to ES10/2019.
The original commit mainly targeted the support of MS Edge
(pre-Chromium) and earlier versions of iOS 11.
As with the release of Odoo 14, we don't support either of those (MS
Edge only Chromium-based and iOS 12), the original restriction can be
lifted and again target EcmaScript 9/2018.
But furthermore, some features of ES10/2019 are already in use in Odoo
14+ (e.g. `Object.fromEntries()` used in SpreadSheet, PoS, WebEditor,
Website Sale...) and the only browser not supporting them is Safari on
iOS versions < 12.2.
As there is no drop of supported devices between iOS 11 and 12 and they
all have access to - at least - the latest revision of iOS 12 (cf.
12.5), it looks reasonable to target the latest revision only and not
the earlier ones. This policy also matches the "ever-green-browsers"
policy applied on desktop.
Note: please note that the tool (es-check) used for testing the
EcmaScript version targeted has for primary goal to catch unsupported
syntax and reserved keywords only, but not the actual APIs available for
a given EcmaScript version. (e.g. async/await keywords or string
literals are tested *but not* Object.fromEntries() or
Array.prototype.flatMap()).
References:
- https://kangax.github.io/compat-table/es2016plus/
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/fromEntries
- https://en.wikipedia.org/wiki/IOS_12closesodoo/odoo#63430
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Consider a model M with a one2many field with comodel L, such that
deleting records in M cascade-deletes records in L. Import a bunch of
records in M with one2many lines having specific external ids. Delete
the imported records: the database cascade-deletes the corresponding
lines, but the lines' external ids are not deleted. Now re-import the
same records: this crashes, because the import process finds the lines'
external ids and tries to update the deleted lines!
The fix consists in checking that an external id's record actually
exists. The existence check was removed for performance reasons by
https://github.com/odoo/odoo/pull/26496. We reintroduce it by resolving
the external id with a join on the model's name, which checks the
record's existence faster than an extra query. This patch allows to
re-create the imported records' lines.
Another patch is necessary to actually update the external ids that
refer to deleted records, otherwise they remain dangling, and importing
the same records again duplicates the lines, because their external ids
do not match any existing record.
OPW 2409649
closesodoo/odoo#63318
X-original-commit: 0322febbea2cfd2d2fd7aedc42ef03632b17c967
Related: odoo/enterprise#15285
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In Belgium, the company registry and the VAT number (no country code) are identic.
The company registry field is not mandatory, but is needed to export the belgian Intrastat XML file.
Now:
- belgian company registry is set by default to vat number.
- missing company registry warning message redirects to company settings.
closesodoo/odoo#58047
Task: 2335088
Related: odoo/enterprise#15270
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closesodoo/odoo#63259
X-original-commit: 47079f67f586adf45da15fc98dbc81571f7a9100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When installing/upgrading a module with broken xml views, the module
installation fails with an error message that should help the developer
locate and correct the error.
Before this commit, a 3-level traceback was thrown at the developer:
1. The initial ValueError containing the original error message and some
view context information.
2. The noisy re-cast of the ValueError to a ValidationError with no
additionnal information.
3. An additionnal re-cast of the exception to add the original source
file path plus the entire XML source code that failed to be parsed.
We argue the error contains too much noise as developers are mostly
interrested in correcting their erronous tag of their view, they are not
interrested in `ir_ui_view` internals.
The new exception report is much less talkative, the two tracebacks from
`ir_ui_view` are logged at the `DEBUG` level. The new exception still
contains the original error message with some context on the view record
and the original source file path but it only show 5 lines of XML around
the erronous tag.
closesodoo/odoo#62757
Task: 2366612
Related: odoo/enterprise#15104
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Create a model as follow:
class FooModel(models.Model):
_name = 'foo'
bar = fields.Char(compute="compute_bar")
@depends('bazz') # wrong dependency, bazz does not exist
def compute_bar(self):
for rec in self:
rec.bar = "Babar raconte des beaux bobards."
Uppon -u foo_module, a ValueError is rose for the invalid dependency
with the following message:
> Field foo.bar cannot find dependency bazz on model foo.
We had feedback the error message was not very clear to some users,
the new error message is:
> Wrong @depends on 'compute_bar' (compute method of field foo.bar).
> Dependency field 'bazz' not found in model foo.
closesodoo/odoo#62328
Task: 2366612
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Introduce a way to schedule the execution of cron jobs *soon*. Triggered
jobs are included in the next execution batch.
Heavy refactor of the `ir.cron` model so the various parallel queries
use the (not so new) `SKIP LOCKED` postgresql select option which skip
rows that are locked instead of throwing an exception like `NOWAIT`
would do. Various methods has been renamed and the overall selection,
execution and update of job records have been re-architectured.
The cron workers can now to wake up early via a notification on the
`cron_trigger` channel of the meta `postgres` database.
closesodoo/odoo#62124
Task: 2368911
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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>
Raphael Collet