Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently on branch saas-13.5
Without demo data
closesodoo/odoo#57168
X-original-commit: 32f752b486053b19a8c6167efb5ca0813f2bf3f8
Related: odoo/enterprise#12997
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Forgotten TODO
Instead of checking in _for_xml_id (where 99% of calls are static),
verify on the few calls that accept an arbitrary argument
closesodoo/odoo#57117
X-original-commit: efc0263b2574fa355ea794514eb3285d8c449260
Related: odoo/enterprise#12975
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Values for "context" and "data" key were injected into the action
dictionnary by report_action to be used by the /report controller
later
Courtesy of William Henrotin (whe) for the test
X-original-commit: 4d43a301fd10cfeb498d9bf6b614779e26e12d16
Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closesodoo/odoo#56995
X-original-commit: c121a246f16899735306266a3a12b526e08e7620
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Go to Contacts > Configuration > Country Group
- Open Europe
United Kingdom is still in the group, but should not.
opw-2328125
closesodoo/odoo#56987
X-original-commit: e43c35d3c95c58d6d6af424d4eebf8244c83f332
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The modification of countries data should be restricted to knowledgeable users.
Indeed, by modifying, deleting and/or creating res.country records, the resulting
behavior generally won't be what you expect, breaking existing flows (delivery, taxes, VAT validation, ...)
in an open OR hidden way...
By restricting those modifications, we reduce the risks of users breaking their database through
'minor' changes unexpectingly triggering 'heavy' problems.
1) Avoid the storage of all country flags as ir_attachment (230+
ir_attachment in a new db) to reduce the filestore of databases.
The country flags are nearly static and not expected to be modified on
Odoo instances.
This change is based on the new "image_url" widget logic (see previous commits).
2) Extend the flag coverage for countries
Add the missing country flags & specify a mapping to provide flags
for overseas administrated countries/territories.
The new "image_url" widget logic provides the ability to provide static image
links in Char fields instead of duplicating the image file in database (+ filestore)
through an Image field (& ir_attachment).
This commits implements the frontend qweb logic for this widget, following the logic
of the existing "image" qweb widget.
Before this commit, the evaluation context was forced with sudo(False)
as the call to _render_qweb_html was made with sudo(True). The sudo
was removed to prevent rendering a report on any object.
This was problematic for reports such as sale.order portal page where
the public user does not have access to the record but uses a custom
verification mechanism using an access_token field and then calling
_render with sudo.
This commit moves the sudo call to keep the _get_evaluation_context
with the same environment and allow to call _render with sudo
Add tests with sale portal building the report as low-priviledge user
closesodoo/odoo#56890
X-original-commit: 57665a02f7b4cd113f8f40ec47c58a518fe8669c
Related: odoo/enterprise#12845
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, the access to private addresses group show in the other
category in user form view and due to that it is visible in non-debug
mode too.
So in this commit, Move the private addresses group to tehcnical
category so it should visible in debug mode only.
closesodoo/odoo#56811
Task-id: 2318509
X-original-commit: 5f0ef2e36c33343a6beada36ef121de4b8767089
Related: odoo/enterprise#12803
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Clean code. Be more performance oriented.
SPECIFICATIONS
Improvements applied in this commit
* not all() --> any(not) for earlier returns;
* all([generator]) --> all(generator) to avoid unnecessary list casting.
This code construct is better managed by all;
This commit will probably not have a big performance effect on standard
production databases. However each performance and cleaning improvement
is welcomed.
LINKS
Task ID-2328619
closesodoo/odoo#56810
X-original-commit: 1cc6bb1231401ea7f501d2f5b5e9641ec8734850
Related: odoo/enterprise#12802
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Have a fairly long (but reasonable) address
Print a report
Before this commit, the address line is split into two lines.
After this commit, the address displays on one line.
closesodoo/odoo#56809
Task-id: 2321081
X-original-commit: efd7da201694fdbc4e0370b3275daa676429b9ba
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
Upgrade scripts are now doing custom check on view/field/model unlink. This check
can be removed from odoo.
closesodoo/odoo#56657
Related: odoo/upgrade#1711
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The Form class already handles cases for attrs that contain boolean
values, e.g.:
`attrs="{'readonly': True}"`
But it doesnt for integers, e.g.:
`attrs="{'readonly': 1}"`
This commit changes the expected non-domain value from boolean to
integer, because both are valid cases and the former is a subset of the
latter.
[1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54closesodoo/odoo#56612
X-original-commit: 782534a429f10e7b114c838687d38aa4080a920c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>
Currently the method `read` uses by default the parameter `load='classic_read')`
- `self.read(fields, load='classic_read')`
So, it computes `name_get` for all m2o fields for all records in `self`.
If you want to avoid computing the `name_get` to save time and process
You can use an empty string in load parameter:
- e.g. `self.read(..., load='')`
The method `self.search_read` call to `search` and `read` methods
but `search_read` method is not possible to assign `load=''` argument
(or other arguments of the method `read`)
- e.g. `self.search_read(..., load='')`
So, you need to use 2 lines of code:
records = self.search(...)
records.read(..., load='')
This commit changes `search_read` method to receive all keyword arguments of the method `read`
So, you can use `self.search_read(..., load='')` and the `read` parameter will be propagated
closesodoo/odoo#46391
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
PURPOSE
Ease the configuration of external email servers by adding links to the
documentation and by making errors more user friendly.
SPECIFICATIONS
This is done by catching more exceptions when testing outgoing mail server
connection and giving related hints.
A link to the documentation is also added in mail: Settings > External Email
Servers feature: add a link to this doc: https://www.odoo.com/documentation/user/13.0/discuss/advanced/email_servers.html
Task ID-2273671
PR #54176
X-original-commit: d30682f4d4aeaefa077ba284a60c93f3a020365f
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In this commit we set tree view of partners (contact) as multi edit enabled.
As some fields still rely on onchange, they are kept readonly in tree
view, notably state_id / country_id, parent_id, is_company.
Email has an onchange used only in form view. It enables gravatar. As it is
not really business critical multi edit on phone is available.
Specifications: Contact (res.partner): base.view_partner_tree
phone
email
company_id
city
state_id
country_id
category_id
date_review_next
grade_id
user_id (+ add a limitation to not share users)
Task ID-2200674
PR #56378
X-original-commit: 5b87603b7620da1badd860abb97d5bcacfc96ad5
ir_sequence is currently broken when trying to view the list of
sequences (if there are any in the system) and when trying to create
one:
During the sql-thingie, I prepared the `params` local to differentiate
the params to provide in both cases of a conditional, then promptly
forgot to do that, so no parameter is provided when one is needed,
which breaks... on every pg >= 10 (which at this point is probably all
of them).
Correct this error.
Furthermore, the "computes are onchange" was not impacted on
`_get_number_next_actual`. On creation, this leads to trying to format
a NewId as a number. If that is just defaulted, we will then try and
`_predict_nextval` for a sequence which doesn't exist in the database.
Just yield `0` if the sequence hasn't been created yet.
closesodoo/odoo#56417
Reported-by: @youring
X-original-commit: 11d676b464d739d10b61bc666fef65698ebc03a6
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Until now, the quick creation dialog of the calendar view assumed that
the underlying model used a 'name' field for quick creation, with a
graceful degradation if it was not the case (redirect to the form view).
This prevented quick creation of models created through customizations
(for example).
This commit adds a `create_name_field` attribute on the view declaration
(similarly to many2one field) that allows to specify the field to use
during quick creation.
Task-2185423
closesodoo/odoo#48122
Related: odoo/enterprise#11242
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
post upgrade tests will trigger 'module not found' warning when testing modules views
because of 'fake' modules without real file path.
closesodoo/odoo#56335
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This module provide routes to manage people, companies, and
leads from the outlook add-on. It could eventually be accessed by
add-ons for other mail clients.
closesodoo/odoo#44936
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Use case:
When the server is restarted, the python is updated,
but some users may have an ongoing session in a browser tab
This may lead to code being unsynchronized and ultimately to some
odd bugs.
Purpose:
When we are in such a case, that is, the assets were recomputed
after a update of the code and a restart of the server by the request of another user,
notify connected users that assets have changed.
Then propose them to reload the page.
Known caveats:
- This is not a developer's feature.
Since assets computing is ORM cached, they have limited
opportunities to rebuild. Namely, the feature won't trigger
each time the JS has changed, rather, it will
when JS has changed AND the cache has been reset somehow (e.g. when the server is restarted).
- This not a portal/website feature either, but only in backend.
Business clients won't be notified that the JS has changed.
- While requests debug=assets do trigger a recomputing
of the *components* of bundles, they do not save a bundle
This means that the requests that sends the notification
cannot be debug=assets.
Task 2034462
closesodoo/odoo#39875
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Before this commit:
* Add a field with studio to any view of module A
* Note that the model has to be unique to module A
* Uninstall module A
* Try to uninstall the `studio_customizations` module
-> MissingError, impossible to uninstall `studio_customizations`
This happens because when uninstalling module A, all `ir.model.fields`
for models of said module are deleted in cascade by PostgreSQL when
unlinking the module's `ir.model`, this means that the ORM has no way of
knowing exactly which `ir.model.fields` where deleted and which
corresponding `ir.model.data` should be deleted, so the `ir.model.data`
remain in the database as orphans (that can, and will be cleaned up
later).
However since #34435 the mechanic that avoids the removal of
LOG_ACCESS_COLUMNS performs field access on records that may not exist.
This commit solves this by simply making sure that all records exist
before performing any checks that may require field access (and thus can
trigger a MissingError if the record does not exist).
opw-2316973
closesodoo/odoo#56285
X-original-commit: 08e662823ccf7dbe4d497f3f487287cba285a852
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Non-stored readonly computed fields must be assigned by compute method.
Make the error message more explicit.
closesodoo/odoo#56269
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Execute shouldn't really be overriden because it handles a very touchy
case: module (un)installs, if it is poorly overriden it can create
registry inconsistencies and can make databases crash in really dumb
ways, since the module operations *need* to be performed at the end of
the transaction (last).
Most of the time, an override of set_values() does the same job and is
much safer.
This commit updates the `res.config.settings.execute()` documentation to
reflect this.
closesodoo/odoo#56032
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Consider models `M` and `L`, with a one2many field `M.l_ids` with
inverse `L.m_id`. Consider also a computed field `L.foo` that depends
on `L.m_id`.
The field `L.foo` is not computed correctly by `onchange` on a new line
in the form view of `M`: its value is forced to `False` because it has
no default, and is not recomputed by `onchange` since the field `L.m_id`
is never triggered an `onchange`.
Modify the method `onchange` to not force fields without a default to
`False`, and return all fields.
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
When creating a new record, the client calls `default_get()`, completes
the returned values with `False`, and calls `onchange()` to apply the
onchange to the defaults.
Optimize the double round-trip by integrating `default_get()` inside
`onchange()` for the first call. The method is called with an empty
list of fields, and usually no field values, except for records in a
one2many field. In this case, `onchange()` does both steps above.
Task 2261084
By adding a parameter `_table_query` on the Model, we can now have views
that depend on the context. The query is used instead of the table name
in ORM operations. This allows to pre-compute some values to improve
performance, instead of storing context values in the database.
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
odoo/odoo#53938 improved the SQL linter and used psycopg2.sql to
silence the linter where that still made sense. However I forgot to
mark table names (pretty much exclusively) as `sql.Identifier` in a
few somewhat rare callsites, which consequently break when invoked as
a simple string is not a Composable and psycopg2 therefore rejects it
when composing the query.
odoo/odoo#54556 fixed a few mis-updated ones, but apparently I still
managed to miss one here.
closesodoo/odoo#56191
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Leftover from testing a post-load report of all test failures.
Intent was to provide test failure details either during or after
loading, but feature was not actually developed and I forgot to remove
this bit before merging.
closesodoo/odoo#56186
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Odoo provides basic handling of CORS preflight requests: if an
endpoint is marked as `cors=<truthy value>` then it'll automatically
reply allowing the request.
*However* this is performed in `HttpRequest.dispatch` (likely in order
to correctly handle the nodb case), which means it's executed after
the auth handler has run... which means custom auth handlers will be
called on preflight requests.
This is a problem because they are missing relevant
information (e.g. which endpoint they're invoked for), plus having to
deal with preflight requests in every custom auth handler is annoying,
and simply allowing preflights could cause issues if the decision
diverges between the auth handler and the automatic
handling.
To fix this issue, extract the preflight *decision* into a separate
method so we get the same decision-making process everywhere, and in
case of CORS preflight set the auth to none to limit the eventual
capacity for nuisance in the span between the bypassed auth and the
automated preflight handling.
Also change the signature of IrHttp._authenticate so it's clearer if a
callsite was forgotten somehow (and this makes for less changes and
duplication at the callsites).
closesodoo/odoo#56029
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* remove useless OdooTestRunner
* don't log results & time per-file, log a module-level tally instead
* add number of tests to post-test results
* generate a single test suite per module (see note)
* use the previous item to split out the at_install test-running in
two steps: generating the suite for the module then running that
suite, this way for modules which have no test, or for
which all tests have been deselected by test tags, we can avoid some
of the setup necessary to prepare for running tests but possibly
quite expensive (e.g. `setup_models`)
Note: single test suite per module
I wanted to stop creating a test result for (essentially) every file
in the module, however because of the class-level ``addCleanup``, a
TestResult can't be reused by independent suites:
In order to run class-level cleanup, the test suite checks between
tests if the test it's *preparing* to run is in the same class as the
last test it ran, and if not applies the class-level cleanup.
The problem is that the "previous test class" is stored on the result
object, which is never cleaned up, and the "between tests" check is
really performed *before each test*.
This means when reusing results across suites it will run the
class-level cleanup at the end of one suite and immediately at the
start of the next, which will cause issues if class-level cleanups are
not idempotent (thankfully ``TestTestCursor`` has a non-idempotent
``tearDownClass` which let me discover the error).
Possible fixes are:
* don't reuse results
* clear the relevant states / attributes between suites
* put individual suites in a Big Suite for running
The latter seems simpler: just create a single suite for the entire
odoo-level module instead of creating one suite per test module.
Note to the note: the case of nested suite is taken in account, the
"end of suite" cleanup only runs at the end of the top-level suite, so
technically we don't have to unwrap suites for *that* purpose, we're
doing so in order to filter the test cases inside the suites. But
maybe we could integrate this feature to the suites themselves...
closesodoo/odoo#55185
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
That's a not-very-useful subset of OdooTestResult, so:
* make results merge-able (aka add ability to update a result with the
contents of another)
* remove support for test data files, and transmission of the
assertion report thing through the data-files loading
* replace "legitimate" uses of assertion report by test result
* have run_unit_tests manipulate and return a result instead of weird
flags & ternaries
Since commit 11857adec0 the invisible form
widgets are not rendered at all. This caused an issue in the document
layout designer where the "custom_colors" field was invisible but still
referenced by a label with a "for" attribute.
Now, said field is not completely invisible anymore; it is set with
"display:none" instead to be rendered invisible and interactive as
before.
closesodoo/odoo#55970
Task: 2320982
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Missed while merging the 2FA: in a mono-db scenario, the request is
bound to a database more or less immediately; however in a multi-db
scenario the current request *may* not be bound to a database by the
time we reach session authentication, this binding is performed *by*
the authentication step[0].
By trying to access an environment (requiring a db) before this
binding is performed, the authentication procedure broke.
We could create the environment by hand, but it seems completely
unnecessary: while there is a bundle of operations to perform in all
cases and a bundle to perform during finalization, they don't seem to
strictly depend on one another (and indeed this separation is already
a reordering of the operations from before), so the finalization can
be performed *after* having bound the current session to a database.
In fact that is closer to the older order: in the pre-totp iteration,
only the binding of the uid was performed before that of the login,
and even it was done after binding the database.
[0] this really is mostly a concern when using this step
programmatically, as interactively the database selector should
require selecting (and binding) a database before it's possible
to log-in
closesodoo/odoo#56093
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make the method `_search` return a `Query` object, and make that object
generate a subquery when used on the right-hand side of a condition.
closesodoo/odoo#52403
Related: odoo/enterprise#10945
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Introduce better methods for introducing tables, join clauses and where
clauses to the Query object, and other methods to generate a complete
SELECT query. The Query object can also behave as a tuple of ids, where
the query is made on demand, and the result is memoized.
Victor Feyens