Comments in .po(t) files for translations of type "code" (e.g. field labels)
specify the path to the file containing the translation. This path should be
OS-independent to get the same result whatever the plateform the instance is
If we export False or an empty string, the Excel export will consider the field
similarly to a boolean, and en empty value will be converted into "=False()" in
Excel. To prevent this, we return "None" in the following cases:
Introduced by 6243d18
Some models (e.g. calendar.event), use "virtual" ids which are not represented
as integers. It was not possible to use sorted method on those models as calling
int() is failing.
This commit fixes the method, making it agnostic to the type of the
'id' member variable.
In version 8.0, postgresql's pg_size_pretty function is used
getting the size of a binary field when reading if `bin_size`
or `bin_size_[col_name]` is set in the context.
So in 8.0 the size of a binary field get units bytes, kB, MB, GB and TB
which was not taken into account. e.g: '5.3 GB'.
This fix uses the size of the string to choose to differenciate the two.
e.g: '10000 bytes' (the longest size) will be returned directly, but
for something longer the human size of the content length will be
There is a corner case if a file is shorter than 12 bytes but
it is an enough of a small scenario with small implications that it is
Previously, if the ID column was displayed it was not sortable.
The particular case added 247c1972 is no longer needed with the new api,
id is in the list of existing fields (see xmo comment in #7461).
Pretty much completely rewritten theme with custom HTML translator and a
few parts of the old theme extracted to their own extensions.
Banner images thought not to be that huge after all, and not worth the
hassle of them living in a different repository.
co-authored with @stefanorigano
The `search` method of models has an additional keyword parameter, `count`.
It not being specified in the docs could lead people to inherit `search`
without defining it, which would result in a `TypeError` when called with
The field display_name is present in account_report_company but not in base
on the res.partner (has been added in v8 in base).
Create a hook method to keep using the slow CASE in base and switch to the
faster display_name when installing account_report_company.
Revert 83282f2d for a cleaner sanitizing earlier in the generation of the error
If the import is failing, the error message contains the value that is
problematic. Escape this value in case it contains '%'
Using the `start` CLI command with the `--path` or `-p` option arrors with:
odoo.py: error: no such option: --path
This is because the `--path` option is passed on the server start routine,
and it's invalid there.
A workaround is to remove those command options from the arguments passed
to the main() server start.
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
View validation accounts for a fair cost of module installation, most of
that is spent checking for view validity, and a significant fraction
of *that* is spent reading the validated view from the DB.
Turns out _check_xml requested *all* view fields even though it needed
none of them save for the arch. Specifying fields to read_combined
rather than fetching all fields seems to result in a ~30% speedup of
_check_xml (under line_profiler). Most of the rest is spent fetching
sub-views (in get_inheriting_view_arch), I don't know that it can be
improved without hand-crafting a fairly complex SQL request.
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.