ref() always trigger a database query to verify record still exists.
In frequently used methods, it's best to avoid ref calls if not needed:
* either the records should always exist
* either the record isn't always needed and the ref can be sometimes
avoided.
X-original-commit: c1e05da7b71c8274aff00d67f8d1bc7e209fcaab
Steps to reproduce:
- Create a second company
- Enable this company only
- Create a new company
=> Access error is raised because the `intercompany_user_id` is
OdooBot by default and OdooBot's partner cannot be read from
other companies. Hence, the company creation fails.
Like all other internal users/partners, OdooBot's partner should
be shared across companies, even if its user is inactive.
Task 2157039
See also 2390ba6
Task 2157039
closesodoo/odoo#50372
X-original-commit: 379d14d4aa7862176fb7e3f79292a1228c254aa9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Before this change, the SSF would read from the record after
creation but wouldn't do so after a write.
This doesn't conform to the behaviour of the web client (which does a
read() after saving a form), and means the effect of field
inverses (when the dependencies of a writable field are also in the
form) or overrides to write wouldn't be visible afterwards.
It's always possible to just re-create the form from scratch, but the
intention has always been that the form would work correctly after a
save.
closesodoo/odoo#50363
X-original-commit: 45398c09c0231e61b83d378d5939ec12d7465844
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Commit 8c1bb22ec0222dca652e0649454b986c06cb1368 forgot to take into
account migrations, during a migration it is possible that some modules
need to be uninstalled because the target version may have removed /
moved them and since during a migration all modules are set `to
upgrade`, the previous condition made this impossible for migration
scripts that use the ORM for module uninstalls (not Odoo's case, mind
you)
With this commit it is again possible to uninstall modules from a
migration script during a migration.
closesodoo/odoo#50322
X-original-commit: a7c90a6d080a77316924cec9d3c64f9662ac7436
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The population of res users was emptying the list of populated partner
ids.
The lunch.supplier population was crashing because no partner id was
present in the partner population registry to use as `partner_id` for
the generated lunch suppliers.
closesodoo/odoo#50266
X-original-commit: a2adc346906ee753df6d8e49caa4ee5381629695
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When the PostgreSQLHandler is used to store some logs in the ir_logging
table of a database, the log record pathname is truncated to keep only
the relevant part of the path. In some circumstances, the path is
wrongly truncated, leading to totally invalid paths.
e.g.: When using an addon-path like `/data/build/enteprise` the removed
part correspond to the length of `/data/build/odoo/`. The resulting path
is `prise/....`.
With this commit, the full path is kept.
This commit is mainly a fix for the runbot logs and should not have an
impact on existing databases.
closesodoo/odoo#50246
X-original-commit: f3c96aa21ad0d8756fadc1608107438ba8cd6c05
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Http routing and websits module will already do it later and handle the case.
The only ModelConverter used that will be impacted is:
/web_editor/attachment/<model("ir.attachment"):attachment>
that is a json controller called with eisting data
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Without this commit, if `lang_code` or `env.context.get('lang')` was set, we
would still access `env.user.company_id.partner_id.lang` to fill the loop array
even if we break and don't need that value.
Switching from loop to if conditions prevents that.
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Followup fix of #48912
The multi-company group should be given to users if they have access to
multiple companies and do not already have this group.
closesodoo/odoo#50233
X-original-commit: 0c721d90c5cd428ef8d51f195da8e02ee91d4364
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prevent unexpected country creation when creating a state. Indeed,
there is usually no reason to create a new country.
opw-2239697
closesodoo/odoo#50210
X-original-commit: a502a404b18a0946d9ff64de9e05c28737e82c57
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Instead of triggering one has_group by user (one sql query/user if not already ormcached),
and potentially filling the `has_group` cache with new users data (we don't know if and when this data
will be used anyway), compute this field from the groups information already in cache.
X-original-commit: d771d7e9c8503543d29fdbf2ab961c2a32cc3bac
Improve the performance of the default method for user groups by avoiding a `ref` call,
using the group in cache instead.
Calls to ref always trigger one SQL query to verify record still exists
This means that creating 10k user would trigger 10k queries only for the default.
X-original-commit: e67efb88338ef669059591728e7722fe1dff4bf0
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
Added country states for 6 EU countries: Estonia, Latvia, Lithuania,
Finland, Sweden, Norway. used ISO 3166-2:EE, ISO 3166-2:LV, ISO
3166-2:LT, ISO 3166-2:FI, ISO 3166-2:SE, ISO 3166-2:NO
The county structure in Norway changed on 1 January 2020, but not yet
published in ISO 3166-2
NB! Import for field country_id:id with value "no" for Norway do not
work, must be "base.no", otherwise considered as False
closesodoo/odoo#50168
X-original-commit: 882fa61fd3c3e0e332fb62ecb92a6c4416864321
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating new translations, do not prepopulate the translation
with src.
Take the following scenario:
- set a value in a translatable field in English
- open the translation popup -> creates all ir.translation
- notice an error in English, close the popup
- correct the error in English
- reopen the popup -> existing translations not modified
Add test about reseting
closesodoo/odoo#50147
X-original-commit: 619eccc7a533eedfb3aec0c3740ead1006e0f2f7
Related: odoo/enterprise#10194
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A plaintext email is displayed in a `<pre/>` tag to conserve spacing.
But since there is no escaping, if in this text there was XML tags or
HTML entities, they would appear as HTML in browser which is not wanted.
Do note that this was not a security issue since the content will still
be subjected to the checks and foundling of HTML emails.
Without the change, the added test would fail because character &,<,>
were not escaped.
opw-2242323
closes#50003closesodoo/odoo#50123
X-original-commit: 932532b5b59e0b71c8e16dadfb2ff36c38764208
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since a0f9ef56, a _vendor module was added without `__init__.py` file,
following the PEP 420 specifications.
Unfortunately, as the `setuptools.find_packages()` only recognize
packages if they have such an init file, the _vendor module is not
packaged. This leads to an import error when running Odoo from the
src,deb and rpm packages.
The `setuptools.find_namespace_packages()`, which is compliant with PEP
420, could have been used instead. But this function does not exists in
setuptools 39.0.1 which is the one packaged in Ubuntu Bionic.
Finally, this commit simply adds the missing dunder init file.
closesodoo/odoo#50051
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With this commit, module operations such as install, upgrades and
uninstalls are henceforth forbidden inside unit tests and instead such
tests must be performed with standalone Odoo scripts.
This is done because module operations during tests are not
transactional, this can leave the registry in an unclean state and
further tests may be affected by this, it also creates a new registry
which complicates registry cleanup if anything crashes,
because the registry to be cleaned up is not the same one that crashed.
Instead, what should be done is a script that imports odoo as a library,
and loads the database necessary then performs whichever operations
necessary. This script should contain a single function with a single
parameter (env) and should be decorated with
@odoo.tests.common.standalone in order to be executed properly, this
decorator accepts any amount of positional parameters as tags that can
be specified when calling the script in order to execute only a select
subset of scripts.
Special tags are: 'all' and <module_name>, these are generated
automatically, the first will execute ALL scripts available whereas
<module_name> will execute all scripts introduced by said module.
When calling the test_module_operations script, only scripts found in
*installed* modules will be executed, script discovery is only possible
if the code is loaded therefore it is only possible if the module is
installed.
closesodoo/odoo#49669
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
- Create 2 companies C1 and C2
- Install any module with access rules, e.g. `account`
- Create an invoice in C1, attach a document
- Switch to C2
- Go to Settings > Technical > Attachments
An `AccessError` is raised.
This happens because the `_search` skips the ACL and record rules for a
system user, while they should only be skipped for the superuser.
opw-2236561
closesodoo/odoo#50067
X-original-commit: 9a71d60c25804bc4bae8c2c680c537f8a7a0900f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a user is linked to a contact, the type should not be
modified. Otherwise, the res.partner type may become incompatible with
the res.user record (e.g. is set as a private address and a user no
longer has access to its own user)
Fixesodoo/odoo#48177closesodoo/odoo#48590
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Werkzeug 1.0 adds a `merge_slashes` feature which calls rule.build()
*during match*[0] (= during dispatch).
However at this point our environment still contains an invalid /
placeholder UID, so `display_name` / `name_get()` fails dramatically.
One possibility would be to update the slugifying to not access the
record (outside of the id) if the environment is not "proper", an
other alternative is to just disable the feature since it seems to not
have been necessary so far.
The latter seems less hacky so do that for now, we can always swap the
solution later if we need to.
[0] https://github.com/pallets/werkzeug/blame/048cdfd9b969c0c3a133d7ff43b8ad1ad6a673ec/src/werkzeug/routing.py#L904
Those were deprecations implemented in 0.15
* all middlewares have been moved from `werkzeug.wsgi` to
`werkzeug.middleware`, including the `SharedDataMiddleware` we use
* ProxyFix was moved to werkzeug.middleware.proxy_fix, this had
already been fixed but I forgot the import
* sessions support was moved to a separate package
(`pallets/secure-cookies`), however while distros are starting to
update werkzeug to 1.0 (e.g. done on Arch, and in Debian
Experimental) they're not bundling secure-cookies so using a
vendored version seems like the least bad thing we can do, even more
so as conditional dependencies are not really a thing (e.g. even
with just pip we can't depend on secure-cookie iff werkzeug >= 1.0)
* remove SessionMiddleware we don't need as it's responsible for most
imports
* fix relative imports to absolute imports from werkzeug
* remove py2/py3 compatibility imports, shims and conditions as we're
P3 only
* remove deprecation warning (duh)
In Werkzeug 1.0, sessions support was moved out and into a separate
package (secure-cookies). Issue is distros are already starting to
update werkzeug to 1.0, without necessarily adding
secure-cookies (e.g. arch, debian experimental). Plus secure-cookies
has some changes e.g. different filename & al. So just vendor the
"continuity" version which is the last werkzeug before removal.
This commit copies the original file as-is so we can track eventual
changes if necessary.
DeprecationWarning was configured as `once` which might be why I
missed some previously: `once` means the *filter* will only signal
once, meaning only one DeprecationWarning gets shown per run. Even if
there are 5 *completely different* warnings getting generated by the
codebase.
`default` should be more suitable, I think I'd originally
misunderstood it as "whatever the default is for this warning" but
what it *actually* means is "print once for each (module, lineno)".
An alternative could be `module` which would show the warning once per
module but wouldn't trigger from different warnings in the same module.
There are bytecode operations we don't support because we've never
needed them, and there are bytecode operations we don't support
because they're vectors of security issues.
Currently no difference is being made between the two, so when looking
to add a new opcodes it's hard to know whether it's been considered
and rejected or whether it just hasn't been considered (or found
useful) yet.
Add an explicit blacklist, which is explicitly subtracted to all
opcodes lists, to allow motivating the bans of certain
opcodes. Opcodes listed in no lists are the "graylists" of opcodes we
either haven't yet considered or have not had a use for.
Also cleanup the existing lists of opcodes to remove long-gone (or
even never-existing) opcodes, and add a few missing opcodes:
* DUP_TOPX was removed from Python 3, replaced by DUP_TOP_TWO
* STORE_MAP was removed in Python 3.5
* BINARY_DIVIDE and INPLACE_DIVIDE were removed from Python 3 (they
were used to invoke P2's integer division)
* the SLICE+<X> were removed from Python 3, which only uses
BUILD_SLICE
* CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW were removed in Python
3.6 and functionally replaced by CALL_FUNCTION_EX (bpo-27213)
* JUMP_IF_FALSE and JUMP_IF_TRUE were removed back in 2.7, replaced by
POP_JUMP_* and JUMP_*_OR_POP (bpo-4715)
* various finally-related bytecode instructions were added to Python
3.8 to improve and speed up the handling of return, break and
continue (bpo-17611).
* INPLACE_REMAINDER, INPLACE_LEFTSHIFT and INPLACE_RIGHTSHIFT were
mentioned in PEP 202 but never actually implemented: INPLACE_
instructions were intended to mirror the BINARY_ instructions, these
mnemonics didn't match the BINARY_ ones, so the actual mnemonics are
INPLACE_MODULO, INPLACE_LSHIFT and INPLACE_RSHIFT
* while at it, BINARY_ and INPLACE_ mnemonics: as noted above they're
mirrors of one another with different prefixes (except for SUBSCR
which doesn't have an INPLACE version), we only supported a fraction
of the INPLACE codes for unknown reason.
Initially looked at simply aligning the BINARY and INPLACE mnemonics
e.g.
'BINARY_POWER', 'BINARY_MULTIPLY', 'BINARY_FLOOR_DIVIDE',
'INPLACE_POWER', 'INPLACE_MULTIPLY', 'INPLACE_FLOOR_DIVIDE',
...
so it would be easier to notice discrepancies, but it seems simpler
and clearer to just move the suffixes to a single list and generate
the BINARY_ and INPLACE_ mnemonics from that
* moved STORE_SUBSCR from EXPR to SAFE, I don't see how `foo[...] = 3`
could be in an expression
* remove pseudo-graylist `_POSSIBLE_OPCODES_P3`, was intended as a
list of new P3 opcodes we might want to add, but the purpose was
hard to understand and a proper blacklist makes way more sense
closesodoo/odoo#41085
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
Consider a sales order with a single line. Edit the sales order: remove
the line, and add another line with the same subtotal. When saving, the
total of the sales order is 0.0.
Here is the explanation: the form view performs a `write` on the sales
order, and modifies the lines with a command `2` (remove line) and a
command `0` (create line).
After deleting the first order line, the cache is emptied, and a call to
`flush()` forces the recomputation of the total. The value is computed
to be 0, and assigned to the field. The assignment converts the value
for the cache, without prefetching the currency field (optimization),
and puts 0.0 in cache. The assignment then converts the value for the
database, which prefetches most fields on the sales order: the cache is
now inconsistent and contains the old value V, while the database is
then updated with 0.0.
After creating the new order line, the total is once again recomputed.
Its value is V, and because the cache also contains that value, no
update is performed to the database, which remains at 0.0!
The fix consists in avoiding the prefetching of fields when accessing
the currency field to round a monetary value.
opw-2223134
closesodoo/odoo#49741
X-original-commit: 048ea2f20a0a2fa6d629cbe262cbbe765248d36f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
It is now possible not to format integers according to locale
This is particularly interesting and relevant when a number holds
some sort of code rather than a number
Task 2050119
*: base, fetchmail, l10n_cl
closesodoo/odoo#39767
Related: odoo/enterprise#6964
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a static template of the form:
```xml
<div t-name="ComponentA">
<ComponentB title="no export" />
</div>
```
To be used by OWL (github.com/odoo/owl)
In this context, the title in the attributes of ComponentB
should not be considered as *the* title attribute of HTML
but as a sort of variable declaration
Before this commit, the string contained in the value of this
title attribute was exported. It was not translated at runtime,
but we want to export as less stuff as possible in PO files
So, after this commit, none of the attributes held by a OWL directive
are exported
This commit relies on OWL Syntax, which makes mandatory
for a component directive's first letter to be capitalized
https://github.com/odoo/owl/blob/master/doc/reference/component.md#composition
Also, it relies on the good practice and widespread convention to have
every HTML node lower cased
https://www.w3schools.com/html/html5_syntax.aspclosesodoo/odoo#46191
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Screencasts were saved in the right directory (screencasts_frames_dir)
but the given path for ffmpeg was wrong (screencasts_dir) and it wasn't
possible to read theses files to make the video.
After this commit, we use the screencast_frames folder to read files.
Steps to reproduce:
Execute Odoo with these additional command:
--screencasts "folder_of_destination" --test-enable (with a failed JS test to produce a screencast)
X-original-commit: 0c0b7a656388d65de15796f07a3f4cc93028f1d7
Set a default email signature to an empty string to avoid `False` when
evaluating `${user.signature | safe}` in email templates.
opw-2229846
closesodoo/odoo#49558
X-original-commit: 96f46fba2635d8050aef03c7d4744a87ac8a597e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
odoo/odoo#46024 improved the serialisation of arrays being logged (in
order to get more relevant data than just `Array(5)`.
However, chrome apparently serialises *argument* objects as array-like
with a few nits, namely that arguments have non-numeric properties
which don't necessarily have a value associated with them.
The array formatter / converter assumed all properties had a value,
resulting in the process crashing rather dramatically.
Filter out non-numeric properties on arrays.
closesodoo/odoo#49418
X-original-commit: 5ff1e41c98f042fd13a1762977cc76604231dfd4
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.
However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:
* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
lazy, which might have worked except
*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).
This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.
This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.
Related to task 2170343
closesodoo/odoo#49286
X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit if the loading of the registry failed because of an
AttributeError or a psycopg2 error the http dispatcher would redirect
the user to the database manager.
This can be problematic because integrators (e.g. odoo.sh) may choose to
disable / forbid access to the database manager, and when the registry
crashes because of e.g. a migration, the real error will be overshadowed
by an AccessDenied error or somesuch depending on the path taken to
forbid access to the database manager.
With this commit, the real exception is simply reraised
closesodoo/odoo#49238
X-original-commit: de4e67dcc52916337251370387aea6aea893a60e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Currently, sometimes users are getting confusing between the concepts
of 'objects' and 'models' when doing advanced configuration or
customization.
So, In this commit we replace 'object' label by 'model'.And also add
quicksearch on the relation field.
TaskId: 2209594
Related Ent PR: https://github.com/odoo/enterprise/pull/9556
closes odoo/odoo#48647
Closes: #48647
Related: odoo/enterprise#9556
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* add a `raw` computed field, though only update some of base to use
it (addons for which that makes sense can be migrated progressively)
* avoid working with base64 data when it's possible to work with the
actual data
* improve datas (base64 encoded content): should depend on bin_size
closesodoo/odoo#47212
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
While installing a module on an existing database, the modification of
groups should reset the `base.user_groups_view` to a dummy view in order
to validate user views. The `user_groups_view` is set to its "right"
value at the end of the installation.
closesodoo/odoo#49114
X-original-commit: 071bd77944484bad6f2c0cb9a7a98785dcc693c6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Iteration methods on LRU were removed because they were not
thread-safe and it's not clear that making them thread-safe is the
correct thing to do, so not providing them seems saner.
I thought I'd looked for usages of the LRU but apparently didn't look
hard enough as I missed that it's used by the cron workers (apparently
using the threaded server we only run crons for dbs currently living
in the registry cache, the more you know).
Convert these to iterating on the LRU's internal mapping, and also
don't iterate on the LRU to clear its entries one by one when we can
just clear the entire thing safely, although Registry.delete_all
really seems completely unused.
closesodoo/odoo#49023
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Victor Feyens