Allows better formatted and commented log_handler items in
configuration files: configparser allows multiline values and
interspersed comments (stripping out comment lines), but while it
removes indent it leaves the linebreaks, so e.g.
foo =
bar,
# qux
quux
when parsed and split on "," results in `['\nbar', '\nquux']` which is
obviously an issue for logging (as it assumes the leading `\n` is part
of the logger name proper).
Since log_handler items can be fairly long and are not necessarily
self-descriptive as to *why* they were selected for re-configuration,
allowing one per line & comments is helpful.
Sink handling of JS logging, exceptions and websocket timeouts so
calls other than _wait_code_ok handle them somewhat properly: the
issue fixed by odoo/odoo#41231 passed because it occurred during
module loading, which happens during initial page loading (browser_js
> navigate_to > _websocket_wait_event), which ignored logs (and
exceptions though here it's a console.error log), and as a result
reported no failure (and would simply miss that specific test as well
as every test following it).
Also since ChromeBrowser treats console.error as an exception,
important messages should be logged atomically. Merge two consecutive
console.error into a single one at the loading of modules so we don't
just get an exception "error while loading foo.bar" without any of the
useful details.
That ChromeBrowser treats console.error as exception is also why the
new method gets a flag (to suppress this behaviour): in the case of
two console.error, upon encountering the first it's treated as an
error so we try to take a screenshot, which goes through the messages
in order to get the screenshot response, which encounters the second
console.error, which gets treated as an exception, which hides the
first error.
Instead, screenshotting (and more generally _websocket_wait_id) should
treat console.error as a regular logging call, probably.
Also run JS tests in debug=assets for easier debugging (ha!) and
improve formatting of exception object when receiving an exception:
* if we can get a description on an `exception` remote object just
print that, it's formatted to show the exception type, message &
traceback
* otherwise format the garbage that is an "ExceptionDetails" object
When migrating a database, load_marked_modules will be called multiple times, alternating
to upgrade and to install modules. The main reason for this is still a litle confusing
but it as the side effect to log "Unmet dependencies" error multiple time in add_modules,
even if the dependency will be resolved later.
This commit removes the error level for this log, and replace it by another check,
performed at the end, logging any module in "to install"/"to upgrade" state.
Also log removed module as info (25), not warning. This may be changed latter
closesodoo/odoo#43797
X-original-commit: c5d6a3977de85fb974a4940fb11d54ef847e08e4
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
At 795c7b0a94 the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/
"The pyldap fork was merged back into python-ldap, and released as
python-ldap 3.0.0."
Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.
The Debian control file package name is adapted to use the latest.
The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.
closesodoo/odoo#43769
Note: This library should be replaced by the pure python "ldap3" library.
X-original-commit: 1afd0ccf20881ba97e3c07dffb33e9a3a0b2cda4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit the search would search for phone numbers that contained a part of a string. The mobile phone would only look at exact matches so if we'd search for '0492700' the only result would be contacts with this exact match. After this commit every mobile phone that contains '0492700' will match and be shown. This allows for quickly finding customers by a partial mobile, just like the phone number does.
closesodoo/odoo#43752
X-original-commit: 8a34a6a66f3f06829231e5d0ba536fcdd27d17ea
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Correct the rounding of several currencies which should be 0.001.
opw-2172122
closesodoo/odoo#43715
X-original-commit: 71f01060ea359814ffdb9ef506a01a2543dfc9ea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This is the second move to replace Filipino by Tagalog language
Using Filipino (code fil_PH) is problematic as conflicts with Finnish
(code fi_FI) and users having their browser in Finnish were redirected
to the Filipino version of the website (cf discussion at opw-2172710).
This problem was also raised in other softwares like in the below
discssion in Mozilla L10N groups
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/TW2qYyDDNoE
Quoting the discussion in above thread:
> Filipino is the national language of the Philippines, but it is
> commonly referred to (and registered as) Tagalog, since most of the
> terms therein were derived from it (Tagalog).
This commit targets the master (future 14.0 as of today), adds a new
Tagalog language and removes the Filipino.
In 12.0, only the Tagalog was added.
As fil_PH is only translated on odoo-com project but remains at 0% in
other Transifex project, it is assumed the language switch won't
impact too many people.
closesodoo/odoo#43634
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Previously, mapped was following a very naive approach, which was simply
calling the field name passed as input for every record in a recordset,
sequentially.
The problem with this approach is that we will potentially recompute the
same fields multiple times for differents records, when this could be
done once per field for ALL records, and store this value in cache for
further access.
Another potential problem is that we don't take advantage of the ORM's
prefetching to fetch all the records that are not in cache at once,
instead of doing the same query for every record in the recordset.
Yet another problem is the conversion of each cache value to a record
format and then combining all of the individual records into a single
recordset, which, depending on the size of the recordset, can take an
unbelievable amount of CPU time.
With this new implementation of `mapped()` we take care of all of these
problems:
This is done by first delegating `mapped()` from the model to the field,
this mapped takes a recordset as input and it will try to batch compute
and prefetch as much as possible for the entire recordset, but it will
not keep these values for the actual output, it just stores everything
in cache and then at the end, retrieves everything from the cache to
guarantee the same order.
After the mapped, the conversion from cache format to record format is
delegated to the new `convert_to_record_multi` which will fetch all the
ids and then perform a single browse to encapsulate all of the records
into a single recordset with the least amount of overhead possible.
Part of Task 2170344
closesodoo/odoo#42611
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Bug in 13.0 regarding company_id field of partners when creating them from
their parent contact or when setting their parent.
The field 'company_id' of res.partner is set by an onchange on 'parent_id'
to that of it's parent; unfortunately the field is readonly if parent_id
is set and not set to force_save.
Furthermore, creating a child partner from the main one (in the 'Contact'
tab of the main partner form view) does not follow the same behaviour
(company_id is unset in that case, meaning that children don't have
the same company as their parent).
Since the company_id is already set by an onchange when we change 'parent_id'
and set to readonly in that case, I assume the expected behaviour is actually
that children partners should have the same company as their parent by default.
Fine tuning of 7b49f5836c
opw:2176384,2167106
closesodoo/odoo#43621
X-original-commit: 92737f21acf9b044df99e111fceffc08e05abe65
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1/ When the new database is created without demo data, the admin has a
'silhouette' as a default picture. When a new user is created without
picture given by the current user, the new user will have a 'silhouette'
as a default profile picture.
2/ web: image for fa-user-slash. This image will be used when a record is
unassigned.
3/ web, *: Change placeholder by default when record is unassigned.
We want to have a fa-user-slash icon when a record is unassigned instead
of 'placeholder.png'. A method is created in the BaseModel to have a
generic method to change easily the placeholder for other models.
4/ Adapt kanban test to keep the same behaviour. Attention the behaviour is
a bit different. Because, now the default image is given by the server to
change easily the default image when a record doesn't have an image.
Thus, we don't say if it's the default placeholder, but we can say it's
not the same image of the record (in this test, the record, it's the
partner).
5/ misc: display 'Unassigned' in the hover on kanban cards if record is unassigned
closesodoo/odoo#41356
Taskid: 2060206
Related: odoo/enterprise#7758
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: jdoutreloux <jud@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Computing the `cache_key` turned out to be a big factor during the
lifespan of a `BaseModel.mapped` call and a lot of this time is spent
computing the same `cache_key` over and over.
These unnecessary computations can be easily reduced to a couple by
moving the `cache_key` method on the environment (instead of the field)
and by implementing a memo for that method. The rationale is that the
`cache_key` of a field does not change for a given environment.
The result of this patch is up to 50% faster `Field.__get__` which in
turn means a GLOBAL gain in performance, especially for methods /
functions that rely heavily on `__get__` such as `BaseModel.mapped`.
closesodoo/odoo#42674
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Before create_multi, in case of invalid syntax used in an XPath, only
the problematic record was displayed. It was not ideal for long
definition but still usable.
Since the views are created using create_multi, the whole file content
is displayed in the error traceback, making it almost impossible to
locate on files with multiple records.
closesodoo/odoo#43590
X-original-commit: 8622469e1fdd4789cc45ed52093d0f329abca14e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
We optimize the search on domains like `[('line_ids', 'in', ids)]`.
The condition is rewritten `('id', 'in', ids1)` where `ids1` is the
result of
SELECT <many2one_field> FROM <comodel_table> WHERE id IN <ids>
The issue is that the latter potentially returns many duplicate values.
The fix consists in having as few duplicates as possible in `ids1`.
Note that domains like `[('line_ids.foo', '=', 42)]` implicitly benefit
from the optimization, as they are rewritten as the one above with
ids = comodel.search([('foo', '=', 42)]).ids
closesodoo/odoo#43574
X-original-commit: a13c05fa5df9c98504e8e1cdb09d8d4a8d13ea91
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Fix the prefetching mechanism to never consider a recordset with
duplicates.
closesodoo/odoo#43426
X-original-commit: c312e1e5e5e23d1d8dc172aa6e5f8f07f5638792
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The faulty code modifies a dictionary in-place to apply a formatting
function to each value. In this case, the formatting is `browse`, and
the issue occurs when `ids` contain duplicates:
for id in ids:
result[id] = format(result.get(id, default))
Fix it by returning a new dictionary based on `result`.
X-original-commit: bd4565e227c7196604af9c5c51ce136a2beac088
Apparently some solutions (e.g. bitnami) deploy odoo using async
workers, and not all pg/psycopg2 features are supported in that mode,
notably COPY FROM (bulk-copying data from a stream to postgres). Work
around this issue by disabling "async mode" as we do the copy (by
resetting the wait callback) then re-enabling it.
While this is not an officially supported run mode, it should Do No
Harm™ for normal operations and could help users and clients.
Of important note: while this fixes an error running in async mode, it
will also prevent the worker from yielding while copy_from is
executing. Hopefully that doesn't take too long (as the entire point
of the copy_from is to be fast) but there you are.
Fixesodoo/odoo#24145closesodoo/odoo#43481
X-original-commit: c4583cf89c2b24085a2eeafea5ef76f474c5ff84
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Some code modify return of res.users().context_get, but this is a
cached method so this will unexpectedly affects totally unrelated code.
For example, changing the company with the company switcher could add
`allowed_company_ids` inside the cache, then it will be cached until the
server is restarted, even if we change company again inbetween.
Added test failed with:
"NotImplementedError: '__setitem__' not supported on frozendict"
on the line with `User = User.with_context(context)` where User already
contained `allowed_company_ids` in its context.
note:
in this forward-port, context_get is also changed to return frozendict
and prevent being able to have an unexpected issue by code that modify
context_get returns.
opw-2158340
closes#42465closesodoo/odoo#42723
X-original-commit: 5d69885c1cd6921b3de00aae7e0ed6fff243ff95
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, bank accounts tab on partner view is available directly
in base whereas it should not, as it contains information useful only
for accountants. We therefore move them directly to account.
Task ID: 2172260
closesodoo/odoo#43322
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Sort of but not really, this commit fixes a special case in which
launching a --test-file of a file with at least two SavepointCases would
create a postgresql deadlock and it would be impossible to terminate the
Odoo process without sending a SIGKILL or waiting for the lock to
timeout.
This was introduced at #39368 and happens because of the way that
unittests unwraps suites, to keep it short, when it unwraps the custom
OdooSuite class internally, it ends up with a vanilla TestSuite with
which to run the different test cases, and since #39368 depends on the
overrides added to OdooSuite to function, the class cleanups are not
triggered at the end of a test class (rollback, cache cleanups, env
reset, registry reset, etc.).
The fix is to manually unwrap the suite of tests to keep OdooSuite as
the suite with which to call the tests, which was already done for
--test-enable (although for different reasons, --test-tags?) which is
why --test-enable didn't have any problems.
This commit also fixes a typo I found on the backport, which meant
classCleanups were not being executed if the setUpClass failed, but it
had no effect on classCleanups during tearDownClass.
Task-ID 2160398
Depends on #43135closesodoo/odoo#43296
X-original-commit: 7a5ded7d40afc29043d356b5dece0dbe1fbd5ab3
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
An http-port provided on the command line (may also have been an issue
for config files, didn't check) would not be taken in account anymore,
because `odoo.tests.common` would be imported during the import of
`odoo` itself (when loading odoo.service.server), itself importing
`odoo.tools.config` leading to a default configuration being set up.
* remove `odoo.tests.common.PORT`, `config['http_port']` should be
used always
* defer the import of odoo.tests.common by moving it inside
load_test_file
* stop generating default configs
closesodoo/odoo#43283
X-original-commit: 45871f498ea4cf3ada719692e69cd413883ab442
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Query counts weren't adapted to recent performance changes.
This commit updates the different query counts to make sure
any commit changing the query counts knows it and does it on purpose.
Some query counts may vary between community and enterprise
and therefore have a higher value than needed in community version.
closesodoo/odoo#43202
Related: odoo/enterprise#7682
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
If check company is set on a field and if the user has no access
right to the field value (example: address_id on an expense sheet
could be set to a private res.partner, on an onchange method when
setting the employee), then the check_company mechanism will
raise an AccessError when trying the validate the companies on
the different records.
Specification
=============
As we only wish to validate the new record values and not the
access rights, the validation could be done as a superuser to
avoid unecessary errors.
closesodoo/odoo#43240
Taskid: 2170006
X-original-commit: 37a9b6c63dcbc268013fbe1a890cf9390eb8e223
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the SSF, o2m updates get initialized with no values (1, id,
{}). The record data is only fetched when the "record" gets updated
explicitly from which updates will hopefully get properly tracked &
saved.
However if the "record" was first initialized through an onchange
values which are updated by the onchange (diverging from the db) those
would not get tracked and thus wouldn't get saved when the record is
saved.
* use more specific placeholder (None) for "o2m records to update but
we don't have values yet"
* once we have values, always store them as an update-tracking dict
* if we don't have values yet for an o2m and an onchange is trying to
write to it, initialize with values from database first (might
eventually be a good idea to initialize upfront though there's the
question of what happens for default values and recursive views)
* mark anything coming back from the onchange and differing from local
values as changed (so they get sent out on save)
* properly reify parent values for onchange instead of sending them
as-is
* the evaluation context for contexts (and domains) needs properly
formatted values so use `_values_to_save` to get them, however it
cares about neither required-ing nor filtering out e.g. unmodified
fields, therefore add an awful toggle to handle this
Task 2150302
Probably todo in the future:
* better UI for change-tracking dict, should have "snapshot"
support (to freeze / discard previous changes)
* cleanup save, it's unclear that it properly resets the form
closesodoo/odoo#43235
X-original-commit: 6c99fe3ffec3aeb8d210e3b943ccef81d62d44ce
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Example:
User 1 has access to company A
User 2 has access to company B
Customer 1 is shared, has user 2 as their Salesperson
Try to create a SO for Customer 1 as User 1
=> access rights issue, the quote is trying to set User 2
as the salesman of the quote but cannot because of
base.res_users_rule
This commit makes this flow possible by sharing users
if they're not portal.
closesodoo/odoo#43190
X-original-commit: ebc8d85d383643c1d4d2aa6723bc7a589c7d1c68
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit:
If neither Invoicing nor Accounting are installed, users are stuck with menus
items to create bank-related informations (Banks and Bank accounts). They won't
be able to set these information directly on their contacts.
After this commit:
The Bank Accounts part of the Invoicing tab has been moved from the `account`
module to `base`, so it's now visible in the partner form even when only
`contacts` is installed
Task ID: 2126832
closesodoo/odoo#40563
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some library versions are outdated since the release of Debian Buster.
With this commit the required libraries versions will match as close as
possible the versions available in the current Debian stable release
(Buster).
Also, the requirements were tested against a Windows Python 3.7 to
ensure that a "pip install -r" can be used without the need of a CPP
compiler.
As Babel format_time now returns 'HNE' (Heure Normale de l'EST) for Fr
locale instead of the zone offset, the test is adapted.
Finally the babel.dates is explicitely imported, otherwise the proper
import of this submodule is relying on a side effect.
closesodoo/odoo#43106
X-original-commit: 32e455bf72980e6330871aa9cd99c26c6e1225d7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since dae065d, model defaults are retrieved based on the env company instead of
the user's company.
However, for a request with auth='none', the company might not be set on the
environnement (if `allowed_company_ids` is not in the context).
This makes the sql query crash, trying to compare an integer to `false`.
closesodoo/odoo#42951
X-original-commit: fa47b1b23a7fa09166c16aacf025cdcefcfaa9fd
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
The constraint view in Odoo has no good quick search options to filter/group and find
specific constraints easily.
This commits allows you to easily group and search for the most used values of
constraints. This will make the finding of constraints easier for functional people.
closesodoo/odoo#41288
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
``_split_street_with_params`` method is defined in base, on partner model. It
is redefined in ``base_address_extended`` without calling super. Only that
module use it. That means that the base implementation is not used anywhere
in the codebase, leading to dead code. Let us remove that method.
Task ID 2158302
PR odoo/odoo#42678
Currently when writing on street field of company model, its sub-fields
(notably street_name, street_number and street_number2) are not correctly
computed again in cache.
Indeed address sub fields have no direct trigger as it depends on its
partner_id and its partner_id children (see ``res_partner.address_get()`` and
``res_company._compute_address()``).
When writing on address fields from the company record, we then invalidate
all address fields cache in order to force their computation.
This commit adds a new tool method giving the list of fields coming from the
address partner to copy upon the company.
Task ID 2158302
PR #42678
Consider an x2many field with `context={'active_test': False}`. The
value of that field should always contain inactive records, as the
field's own context overrides the context of the current record.
closesodoo/odoo#42824
X-original-commit: a2fc37adc179fb8bfc11251137334f0a43c58135
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
`run_action_` hooks don't always return a value, in which case
invoking run() over RPC will raise a TypeError (though the call itself
should still succeed).
Somewhat oddly, "standard" hooks (e.g. in mail) generally do
things safely and return a `False`, but the "builtin" hooks (code,
object create and object write) tend to return nothing, and thus break
when invoked over RPC.
Fixes#42268Closes#42272closesodoo/odoo#42804
X-original-commit: 9ad01ef242afc9602d4a1470cb321374129f29b9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously it was always possible to create within the calendar view.
For some modules this did not make sense and lead to confusing behavior,
for example: a new model instance created in the calendar view that was
not viewable in the calendar view, but was viewable in other views. By
adding a 'create' attribute (to be used in view xml), we allow users to
choose whether or not they want a calendar view to be able to create.
Note that this change does not affect the edit ability of calendar views
for existing instances.
Part of
Task: 2126530
* add a runtime warning when an onchange method contains the string
'domain'
* add a lint test to forbid the string 'domain' in onchange methods,
this is easy to defeat (e.g. `dict(domain=...)`) and can have false
positives (literal `'domain'` strings for reasons other than an
onchange result) but overall it seems to work nicely
* implemented as a non-pylint test as pylint takes ages to run. While
at it, remove the long-disabled and long-useless
PEP3110TokenChecker (checks for `except Exception, a` which is a
syntax error in P3)
Task 2115472
closesodoo/odoo#41918
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Without this flush, partner computed fields are not computed when creating
the company, leading to a cache miss. It is due to the quite complex model
introduced in base_address_extended with multiple related / computed / inverse
fields.
How to reproduce
* have base_address_extended installed;
* create a company with address bits (street_name, street_number,
street_number2);
* encounter a nice cache miss bug (partner<ID>.street_number):
Original task ID 2068145
PR odoo/odoo#42701closesodoo/odoo#42722
X-original-commit: 69ea928828fca06c9b0f589e23ca3c0d4c387ab0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
The orderby specification is a string, not a list
Using a list as a orderby clause produces an error in the construction
of the group by query
closesodoo/odoo#42451
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Fine-tunning of 42eec88e5da164e4930c48113109f2c8d4b73da3
Before this commit, the assets were not found when the user is connected
in mode debug assets in a multi-website and multi-company. This occurs
because the attachments (assets) were created only for the first website
accessed, and cannot be loaded when trying to access the second website.
Now, the attachments are created for each website accessed and can be
loaded withtout problems.
closesodoo/odoo#42593
X-original-commit: 95077a8cdd9f2cd99c2ef85bdf7ca5d58e006b71
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Commit d86c2c5883 removed the multi-company partner rule because it
interfered with the users rule. Indeed, interference between the user's
default company and its corresponding partner's company made it possible
to have users that were basically unselectable in relational fields if
you were not viewing more than one company at the same time.
However, this generates a lot of frustrations and tickets for Odoo
users, since having everything shared by default is annoying and a clear
departure from the expected behaviour.
This commit tries to mitigates this fix's side-effects by re-introducing
the multi-company rules but by not applying it to partners who are linked
to a non-share user (basically, any partner who has a user that is not
a portal user). That way, customers and vendors remain filtered by the
multi-company rules and only partners of internal users bypass the rule.
This is still a side-effect, and might raise a few eyebrows (why is this
partner visible even though it is in another company?), but the
trade-off seems to be worth it since it fixes the original issue with a
far smaller behaviour change.
Fixes#41720.
closesodoo/odoo#42592
X-original-commit: 2390ba60b8bd624daaea2e6d4e3fd85ef1b1faeb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This is a changement succeeding 13.0 7eb603b26c, in that commit the issue
was solved but only in the case of en_US base language of translation
which can not be the case on a website.
opw-2153422
closes#42269closesodoo/odoo#42467
X-original-commit: 191075454563c7e15b22d20b21afeb8bcc5601c4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit nothing prevented high concurrency on a threaded http
server to consume too much resources, ending up failing requests either
because the OS is unable to spawn that many threads
(`RuntimeError: can't start new thread`), either because the Odoo db
connection pool is full (`PoolError: The Connection Pool Is Full`).
This commit adds the ODOO_MAX_HTTP_THREADS environment variable which
allows to limit the amount of concurrent socket connections accepted by
a threaded server, implicitly limiting the amount of concurrent threads
running for http requests handling.
Note that if a value has been provided to ODOO_MAX_HTTP_THREADS that cannot
be parsed as an integer, a value will be automatically set to half the
db connection pool size (which defaults to 64). This dynamic value is
chosen because while most requests will borrow only one cursor
concurrently, there are some exceptions where some controllers might
allocate two or more cursors.
closesodoo/odoo#42327
X-original-commit: d42a951369ee87b50e834f73cd2af5cf031d43f7
Signed-off-by: Christophe Simonis <chs@odoo.com>
Collisions in table names of ORM models with built-in PG structures such
as "attributes", "domains", "routines", "parameters", ... could occur
and render the result of `table_kind` meaningless.
Based on what was done via https://github.com/odoo/odoo/pull/16651 more
than 2 years ago, it seems relying on our tables being in the 'public'
schema is safe, even though it's only a default from PG. We reuse that
same logic rather than the alternative of excluding
('information_schema', 'pg_catalog', ...), even though it looks safer at
first. If we did the latter we'd have to change the other comparison for
consistency, i.e. more risks.
closesodoo/odoo#42358
X-original-commit: d8e74eb14990c82f65a44ffe163aa84159d6ccc4
Signed-off-by: Denis Vermylen <Icallhimtest@users.noreply.github.com>
glibc's malloc() uses arenas [1] in order to efficiently handle memory
allocation of multi-threaded applications. This allows better memory
allocation handling in case of multiple threads that would be using
malloc() concurrently [2].
Due to the python's GIL, this optimization have no effect on
multithreaded python programs. Unfortunately, a downside of creating one
arena per cpu core is the increase of virtual memory which Odoo is based
upon in order to limit the memory usage for threaded workers.
On 32bit systems the default size of an arena is 512K while on 64bit
systems it's 64M [3], hence a threaded worker will quickly reach it's
default memory soft limit upon concurrent requests. We therefore set the
maximum arenas allowed to 2 unless the MALLOC_ARENA_MAX env variable is
set.
This commit also brings the following changes:
- allow to disable the memory hard limit for all servers if the provided
value is 0 (instead of crashing)
- increase the log level for threaded server in case of limits reached
Note: Setting MALLOC_ARENA_MAX=0 allow to explicitely set the default
glibs's malloc() behaviour.
[1] https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps
[2] https://www.gnu.org/software/libc/manual/html_node/The-GNU-Allocator.html
[3] https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=00ce48c;hb=0a8262a#l862closesodoo/odoo#42323
X-original-commit: 85fe2c6e60f7f1f6ea72cb55e85f85d420ce6616
Signed-off-by: Christophe Simonis <chs@odoo.com>
When an attachment is linked to a record (res_id and res_model are set)
we check the access rights and access rules of that record.
The access we check on linked record has changed as follow:
- 15905e78 (2013) => we check `write` access right/rule for `create`
- f5ebc509 (2014) => we check `write` access right for all mode
- 66644e85 (2015) => we check write access right for all but create mode
So currently we check on the linked record for each mode:
- create: write access right / write access rule
- read: read access right / read access rule
- write: write access right / write access rule
- unlink: write access right / unlink access rule
The behavior is not expected for `unlink`, we should check if we have
write access through access rules instead of checking unlink access.
Without the change, the added test failed with a `unlink` access rule
AccessError on the linked record.
opw-2154448
closes#41814closesodoo/odoo#42264
X-original-commit: 2b3fc2e3b80f191b4cd126abccf6f94b1302ac11
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Xavier Morel