This commit takes advantages of the features added in the parent commit
to have better/cleaner tests.
closesodoo/odoo#39368
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This commit partially backports bpo-24412, which allows the definition of
class cleanups (addClassCleanup) and module cleanups (omitted),
similar to instance cleanups (addCleanup).
This is useful for tests that override unittest's setUpClass and
could crash during its execution: If this happens, it is possible that a
bunch of crap is left in the database or even worse, the cursor becomes
completely fucked; Thanks to the addClassCleanup, we can undo the damage
done by the setUpClass.
Another benefit is that it is called unconditionally after tearDownClass
is called, so it can also be called as a replacement and/or safer
tearDownClass.
Purpose
=======
This is the first huge step to improve the test suite in several ways:
- Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases.
- Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing.
- Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners.
- This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example.
closesodoo/odoo#39868
Taskid: 2075739
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since commit 62c9dedafd attachments almost always require employee
user access, unless some specific flow grants super user rights. Moreover
other flows like portal checks user rights before going into attachments
management with superuser rights.
In this commit we simplify code by directly checking current user belongs
to internal employee group (or is a superuser / admin).
We consider tt is the role of controller/model using attachments to check
and grants access to attachments.
Some history of attachments management improvement (not complete, just
an overview of discussed points)
* 3620cb68a0: improve attachment management in portal;
* de7c119e66: improve message_post and its attachments management;
* 62c9dedafd: clean ACLs;
Task ID 2004031
PR #38358closesodoo/odoo#39869
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
Allow to add an attribute ``show_unusual_days="True"`` to display
some days in green, according to a linked method ``get_unusual_days``
that should be defined on the related model to return all the
concerned days for a given period.
odoo/odoo#28519 removed large parts of pycompat, but left reraise
despite that not having much value.
Remove that helper and replace it by just a `raise` in most cases:
when raising from an except block, the old exception is automatically
chained to the new one, no need to mess around.
There is one exception: in http we have to re-raise an existing
exception explicitly (aka `raise exc` rather than just `raise).
This is less than ideal as Python *concatenates* stacks: the
previously reified stack (from the except clause) is stacked on top of
the new stack (from this raises), this leads to tracebacks "jumping
around" at the break point of the handler and is somewhat confusing.
So we want to use explicit chaining (`raise a from b`) with the
"source" providing the caught exception's original traceback and the
child providing the rest.
However since callers rely on the exception making sense, we need the
re-raised exception to be the original[0]. Copying the exception
doesn't work (see [0]), chaining an exception to itself doesn't
do anything useful, and while we could probably copy exceptions using
the pickle method[1] that's still risky.
So the most reliable option seems to be to create a new "cause"
exception, move the old traceback over to it, then re-raise the
original exception having cleared its traceback, chained to new the
cause.
[0] or a copy thereof but Odoo exceptions don't all work properly with
copy.copy and we don't want that to fail so not really an option,
we can't rely / bet on every new exception being cleanly copy-able
[1] create an "empty" instance using __new__ (or an instance of
something else onto which we re-set the __class__ in case the exctype
actually overrides __new__) then copy the __dict__
closesodoo/odoo#39709
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The unittest signature of `assertRaises` allows a named parameter
`msg`[1]. The message is displayed in case of assertion failure if
`assertRaises` is used as a context manager (but not when giving it a
callable).
The Odoo implementation did not implement this behavior, despite it
being expected by multiple odoo tests.
Fix Odoo version to be in line with the method we're overriding /
shadowing.
[1] https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaisesclosesodoo/odoo#36719
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In the contacts app, you can select 2 partners and merge them.
Before this commit:
- If a partner was added by a SQL query and not directly on Odoo,
the create_date will be empty. This causes a crash because the
merge wizard try to sort the partners by date
After this commit:
- If a partner do not have a create_date, it will be considered
as 01/01/1970. The merge wizard will sort the partners by IDs too.
OPW-2091925
closesodoo/odoo#39523
X-original-commit: deeb769c0d579c51ab42b072ccc1c013d79fcea4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
odoo/odoo#30688 (6ce2d6efb5) added an
indirection in prefork workers: Python-level signal handlers are
delayed until native calls have ended (e.g. accept() or
execute()). Running the actual work in a sub-thread allowed the main
thread to handle signals in all cases.
However there is apparently an issue with SIGXCPU on linux (possibly
other cases as well): SIGXCPU is delivered to the child thread (if
possible?) and Thread.join apparently stops it from redelivered to
the main thread (Thread.join is signal-interruptible since 3.2 but
possibly not Python-interruptible).
Blocking SIGXCPU on the child thread causes the OS to deliver on the
main thread and fixes the issue.
Also split set_limits so it sets the signal handler in the parent
thread but properly updates the soft limit in the child after each
request, as the goal is to put a hard limit on the CPU time per
request, not on the worker. 6ce2d6ef would set the limit once then
never update it, likely cycling workers more than desired.
While at it:
* block other signals with a handler set, they seem to work
regardless on linux but other OS may have a different way of
dispatching process-directed signals
* unset signals which are set by the prefork server but whose
set behavior makes no sense in workers:
- TERM and CHLD were already unset
- HUP is used to restart the server, workers can just be killed
- TTIN and TTOU configure the number of workers
closesodoo/odoo#39731
X-original-commit: 549bd199bad269e4e28efac933efac3f41495877
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`is_false` relies on no small part on equality tests between the input
triplets and either `TRUE_LEAF` or `FALSE_LEAF`. While these are
defined as tuples, RPC domains will always be lists (as neither
XML-RPC nor JSON have tuples, and their arrays deserialize to Python
lists).
This is an issue, because tuple and list never compare equal. As a
result, while the in / not in predicates can succeed, the TRUE_LEAF /
FALSE_LEAF never will, and thus domains which contain either and might
shortcut (avoid a query entirely) will always go through the entire
process.
Fix by having domain normalization also ensure all triplets are
tuples: that's the first thing `is_false` does, it should never cause
issues and could fix / improve / shortcut other routines.
Note: Also implements TRUE_LEAF and FALSE_LEAF handling in the
SSF's modifiers evaluator. And fixes the ValueError to work
correctly if it breaks on a tuple / dict.
closesodoo/odoo#39706
X-original-commit: a44f008b918ee66742f7e943b00e4ee3d7fe2b78
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In 6b048a8b8 most issue with trigger causing error when uninstalling a
module were solved.
But there was a particular case if the current uninstallation of modules
there was an update of `ir.model.fields.selection` to be removed. The
unlink of `ir.model.fields.selection` would cause a `setup_models` call
that would add all removed triggers back and possibly down the line
cause an trigger recomputation error.
With this changeset, we do as is already done for ir.model.fields and do
not re-initialize the registry during module uninstallation.
opw-2098915
closes#39796closesodoo/odoo#39824
X-original-commit: 0ccf2ab8e7f3edabb2d3d4c17a20829de21cca49
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
When importing an O2M value (sub-record), rather than raising an error
if the value has a xid set (foo_ids/id) and the xid does not exist in
the database, re-insert the xid as the "id" field of the sub-record,
then re-extract it at creation (the ORM will have ignored it) and
associate it with the newly created record.
Advantages:
* keeps o2m creation in the proper order during import (sub-records
remain created after the parent) meaning o2ms with a required parent
can take advantage of the feature
* avoids breaking batching when creating the objects
* no new command or smuggling through an existing command
closesodoo/odoo#35995
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Turns out almost no user of odoo.tools.osutil actually imports
it. Following odoo/odoo#39573
(355e360973) removing what were
apparently the only two users of the submodule properly importing it,
other calls to osutil features now blow up, which went unnoticed as
these calls are lazy (so don't prevent starting the server) and only
happen for very specific operations.
The smallest change there is to simply re-enable the old behaviour by
explicitly importing osutil from tools.__init__.
closesodoo/odoo#39705
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When testing the import of records, a flush should be done to check
all databases constraints and fields computations.
Moreover, in case an exception is raised within a savepoint,
the environment should be cleaned up, to avoid tricky bugs (see below).
We replace the manual handling of savepoints with the savepoint
context manager, which already handles all of this.
This code predates the context manager, so in a way it was archaic.
When testing the import of records, the following could happen:
"An unknown issue occurred during import (possibly lost connection,
data limit exceeded or memory limits exceeded)."
This would happen on project tasks; the fields 'working_hours_open',
'working_hours_close', 'working_days_open', 'working_days_close',
all depend on the computation of _compute_elapsed.
Because this is a test import, the records would raise a MissingError,
and fields_to_compute would always contain 3 of the fields.
The resulting is an infinite loop giving this error.
opw 2092134
closesodoo/odoo#39682
X-original-commit: 1a315e87b05fcbdefcb3db6d8d4837f6cc3e835c
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Initial b6ed34e1 idea was to ensure that we always have
_rewrite_len and _routing_map defined. Unfortunately, this
is not correct since class attribute defined dynamically
are actually added in registry, and recomputed on each install.
More than that, the call si shared between multiple database
meaning that routing_map cache may be shared between multiple
database whcich is not correct.
After b6ed34e1, when installing discuss on a fresh database without
demo, all discuss routes will be unknown since None is already in
_routing_map and thus routing_map is not recomputed.
When routing_map is on the model class, in registry,
a new install will reset the class, remove the _routing_map attribute,
which will fix the problem.
Task #2117275closesodoo/odoo#39640
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Activate developer mode, generate a report (print an invoice)
The report will have missing pieces, like the footer or some part of the
header. This is probably caused by wkhtmltopdf not loading properly some
resources
Wkhtmtopdf generate the same warning message for every problematic resource:
"Warning: Received createRequest signal on a disposed ResourceObject's
NetworkAccessManager. This might be an indication of an iframe taking
too long to load."
Related issue on wkhtmltopdf project page:
wkhtmltopdf/wkhtmltopdf#1865wkhtmltopdf/wkhtmltopdf#3933wkhtmltopdf/wkhtmltopdf#2565
The problem is located in the response that wkhtmltopdf receive:
in debug mode the header of the response contains
'Cache-Control: no-cache' which probably create a race condition during
the rendering while a second request is attempted to verify the
resources.
Adding a raw user agent check to not include this header directive
fix the problem
Notes from odony:
We've considered some alternative solutions to preserve the purpose of the
DisableCacheMiddleware without having to explicitly test for wkhtmltopdf.
* 'Cache-Control: no-cache' (current behavior) breaks wkhtmltopdf rendering
* 'Cache-Control: no-store' breaks wkhtmltopdf rendering too
* 'Cache-Control: max-age=0' breaks wkhtmltopdf rendering too. It works
when increasing the delay to a few seconds, but no magic value will work
for very long documents, or it will stop serving its purpose, so it's not a
viable option.
* 'Cache-Control: must-revalidate' does not break wkhtmltopdf rendering (no
duplicate requests at all), but it is not clear from the RFC
(https://tools.ietf.org/html/rfc7234#section-5.2.2.1) that it
will have the intended effect for our middlewar
opw-2086708
Closes#38394closesodoo/odoo#39634
X-original-commit: 8cac60be37133cabef46dab016a5692876da9e5e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since a many2one_reference is simply an int, we can defer
_str_to_many2one_reference to _str_to_integer.
Note that to really validate the integer, we need the model_field of the
field, which should be stored in the record's values.
To get this information, _extract_records would have to be modified.
For the reported use-case, it does not matter as the create of the
message record checks for the existence of the related record,
so the validation works as expected.
Better support for this type of fields would be to allow for
import/export of xml_ids, which would avoid the need for the model.
opw 2087353
closesodoo/odoo#39601
X-original-commit: 77f616e9359272b2598d414672cffbc06cee2a33
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
After deleting records from model 'ir.model.fields', make sure to not
trigger recomputations based on those fields, as they have been removed
from the database schema.
Also shorten the deletion of 'ir.model.fields.selection' records: as
they are deleted after 'ir.model.fields', most of them have already been
deleted on cascade.
closesodoo/odoo#39607
X-original-commit: 6b048a8b86bb32955c165dfb31736e9df5828f7a
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
* walksymlinks is useless, os.walk got followlinks in 2.6
* tempdir is redundant with tempfile.TemporaryDirectory added in 3.2
* listdir(recursive=False) is just os.listdir (I guess recursive=True
is somewhat useful)
* zip_dir is *not* redundant with shutil.make_archive:
- zip_dir handles the archived root differently
- zip_dir sorts files, make_archive sorts directories
- make_archive explicitly adds entries for directories (including
empty), sorts directories, doesn't sort files; zip_dir sorts
files (including with a custom key function) but ignores directories
- zip_dir filters out a bunch of trash files
closesodoo/odoo#39573
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, console.error were catched by browser_js
in order to log them but only value was used on received object,
which is correct only when the received object is text.
With owl arrival, error object may be logged. This
commit add the ability to manage logged object, fallbacking on
a complete representation of object if object is not an error or
description is empty.
closesodoo/odoo#39592
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The two method valid valid_alternative_icon_text and valid_title_icon
represent ~13% of an install all. Rewriting them in master
with in #36373 is the main reason of the performance improvement.
Those two method logic were broken, because
`xpath += '[not(//*[' + valid_attrs_xpath + '])]'`
will actually search for valid_attrs_xpath from view root,
not from fa- node.
-since this check will only log a warning and so only impact
bugfix, no impact on user editing views,
-since a new check is added in master with the corresponding fix in views,
-since this check doesn't really test what it is suppose to check,
-since fa accessibility is great, but not critical
->removing those check will slightly speed up build without major impact
on views quality
closesodoo/odoo#39566
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Actually, the two class attributes are only set when calling the
routing_map method. As a consequence, when the url_for function in the
http_routing module tries to access the _rewrite_len attribute, it
may crashe.
This problem arrise in the TestQwebProcessAtt from the website module
when the test is run alone.
It was hidden on the runbot because some missconfigured HttpCase tests were run
at_install before TestQwebProcessAtt. In that particular case, the
routing_map method is called and sets the attribute.
With this commit, the _routing_map and _rewrite_len class attributes are
set on the class at class declaration time.
In some case, a browser_js test with login "None" following a browser_js
test with a defined login could result in the second test being executed
with the previous user.
This was caused by a race condition, a request response comming back
to chrome just after browser clear, restoring the old cookie.
(All odoo request have the set_cookie flag set in order to refresh
cookie timeout)
The solution here is to check one more time for cookie in authenticate,
but also to remove HTTPCase session from session_store. This will
only be effective when calling browser_js without login in the same
HTTPCase .
closesodoo/odoo#39525
X-original-commit: 218db53b9da1573dc18610678de3b7f763531c60
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The profiler was too optimistic. If the local variable self was not a
cursor, it assumed it was automatically an Odoo model.
Instead, only do the custom tracer methods when self is an instance of
BaseModel.
Full scenario to reproduce explained at odoo/odoo#39237
In case a method like the default_get of utm.mixing was profiled, the
tracer crashed when evaluating `__bool__(request)`.
The tracer considered self as an Odoo model while it was a werkzeug
instance with its custom __getattr__ that crashed while trying to
retrieve the content of `_name`.
Fixesodoo/odoo#39237closesodoo/odoo#39524
X-original-commit: c8fa8fb067dcfb15330acde35d66ac41a255f669
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
m2ms are internally represented as "6" commands, however in domains
it's possible to compare an m2m value to a list of ids (to
investigate: whether this is an artifact of internal webclient repr or
part of the real contract).
Add a workaround in SSF modifier computation to convert the m2m
command storage to a simple ids list.
A better fix would probably have been to represent the m2m as a list
of ids internally (and only convert on load / save) however it not
completely trivial as it has to be done recursively in order to
properly handle an m2m inside an o2m. So it's a complete change of the
internal data model (which should probably go alongide more
fundamental changes e.g. properly handling parent refs, etc...)
Also add very minor support for widgets (mostly so it's possible to
set widget=many2many on an o2m field).
closesodoo/odoo#39467
X-original-commit: 927979beff9e5d4f6c88078862779eaa88f4e07d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Have a parent template
Have a child, in extension inherit mode of the parent
The child has a xpath like
`<xpath expr="." position="replace" />`
Before this commit, there was a crash.
That was because the Comment
(which indicates which templates modified the parent)
was taken as the replacer node
instead of the actual content of the xpath
After this commit, there is no crash, and it works as expected
closesodoo/odoo#39453
X-original-commit: 02d790e1d21b78395e489f57bf30c82f728cbee6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The purpose of this patch is to avoid `filtered_domain` to crash with
domains on date/datetime fields when the fields are `False` on some
records:
records.filtered_domain([('date', '<', '2019-10-28')])
closesodoo/odoo#39449
X-original-commit: dae379adebedb3ed9bd38a2d6925ba6aefef1e7f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
res_name is made non-stored in 8fffe89b0481af057fd6908a52af775578b9fce1
but the groupby filter using the field is not. The filter has to be
removed as well because groupby only works with stored fields.
closesodoo/odoo#39396
X-original-commit: 495124497c733b4bb272fb0d65e132b024a99917
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, en_US was almost always the default in case of 'no language'.
Now, that should be superseded by lang=None;
yet still, en_US plays the role of source language.
In a multilanguage database where en_US was not installed,
writing a translation with lang=None would crash.
This could prevent module installation.
A test is added to cover that case.
In the case where we write a record with lang=None, the source is the
same as the record; in that case the cache contains the value for the
field.name under the context keys en_US and None, so we need to
invalidate the cache to avoid getting back the old value.
co-authored with mart-e
opw 2088487
opw 2083710
closesodoo/odoo#39130
X-original-commit: 1a5a999c2dd69c9a6a2dacb59e8bf45b09c6bc13
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Since https://github.com/odoo/odoo/commit/a5b6f31cf28e5381e1c85f66730bcdb55998e643,
the current companies of the user are saved in the context as "allowed_company_ids"
context key.
In case of invalid context content, the api was computing the intersection
between the context content and the user company(ies) and falling back on user
company_id(s) when catching an error.
A sanity check was done, but no feedback was given to the user,
saying that the context change was falsy.
This commits changes this behavior to :
* raise an AccessError when trying to access self.env.company(ies) when
invalid or unauthorized companies are defined in the context.
* take sudo mode into consideration, allowing inter-company impacts,
even when current user doesn't have access to a given company,
if the code is done in a sudoed environment.
Co-Authored-By: Raphael Collet <rco@odoo.com>
This is a preliminary work for task 2088171 that will
improve server action creation usability in marketing automation.
When creating a marketing automation activity, one can choose to trigger a server action.
This task aims at improving a the usability of this option for non-technical users
as well as cleaning the view a bit (because so far we display the standard server action form view).
closesodoo/odoo#38922
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The queries made by the method `_is_an_ordinary_table` represent about
8% of the time to do a full Odoo installation. Use a cached query for
all tables on the registry to reduce that time to some negligible
amount.
closesodoo/odoo#39262
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The nightly clickall runbot fail due to a crash of the underlying chrome
browser used to run the test suite. The problem is related to the
resources the browser is using. We leverage the problem by starting one
dedicated browser per app.
closesodoo/odoo#39190
X-original-commit: 228e57d980839bd2b4e9123bf26f8a64de2ae6ab
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The basic ORM methods should not silently discard unknown fields, as
they may be a sign of broken code.
X-original-commit: 9595dd06a1d349b2fb84969374d57c32a5faab74
This commits fixes user duplication.
Suppose there is a monetary field, with a currency_field that is a related.
When going through model's _create, we do:
`if field.type in ('one2many', 'many2many'):
self.env.cache.set(record, field, ())`
knowing that thse values are false, with the intent to clean them later:
`for record, field in cachetoclear`
However, when setting the scalar values, we go through:
`accessing cache_value = field.convert_to_cache(value, record)`
In the case of the monetary field, this depends on another field value
(the currency_field). If it is a related, we can access its value.
However, at this point, if we check any access rights, we might use the value
of a relational in cache for which the value is incorrectly set to False.
In the case of the user, this is what happens: it inherits its currency_id
from partner, as well as its debit_limit which depends on it.
When the access if checked, company_ids is set to False in cache.
So when going through the rule 'user rule', which checks that the company_ids
intersects with the env.companies.ids, the result is always False.
In some way this is essentially hiding the problem, but the true fix is
probably not feasible in stable.
opw 2086661closesodoo/odoo#39017
X-original-commit: aa05a9359b42317261c8e7ffcadbeb9fe74dcd58
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Start odoo-bin using a tier module (like `python3 -m pdb odoo-bin`), the
odoo/addons __path__ contains the relative link to the modules instead
of the absolute link like when directly started (`python3 odoo-bin`).
This cause trouble importing modules because it reuses the relative path
from within other directories.
closesodoo/odoo#39182
X-original-commit: 941e051fc6b33e7a90400c77d63d589049b027a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This fixes a regression introduced by 291a0e99d137142bd24addd1054c1357ddd7125a.
closesodoo/odoo#39178
X-original-commit: 852ee32e3419c210a3844b0f943af8dd2bbdae88
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Do not return a boolean but skip bad translations
Introduced at 19e50ea374Fixesodoo/odoo#39001
At least fix the error that is thrown, however, this does not solve
the initial error of trying to export the terms of a record that is no
longer present in the database.
As this issue is no longer reproducable, just log a warning as it was
expected.
closesodoo/odoo#39122
X-original-commit: 5c0677bf2fbf6d18978989f1ee70e4a0946da035
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Adrian Torres