In Python 2, hasattr swallows *any* exception raised during the
access. In Python 3, it only swallows AttributeError.
Accessing an attribute on an unbound threadlocal proxy raises
RuntimeError, while running test_ir_http_mimetype ``request`` is
unbound, in Python 2 ``hasattr`` would return ``False`` on an unbound
threadlocal, in Python 3 it lets ``RuntimeError`` pass through blowing
up the test.
Fix this by just checking if the threadlocal is bound by using it as a
boolean…
In Python 3 round:
* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
None)
* discards the negative sign when rounding to 0
Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.
Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.
This is hinted at but maybe not clearly spelled out by the official
documentation:
> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.
Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.
When deciding to prefetch records (getting records from the cache with
no value for the field being fetched), if the field was computed
`determine_value` would just get all records, not limited by the normal
prefetch limit; for large recordsets this would generate gigantic
prefetch lists for records we may not need at all.
Fix by applying the `PREFETCH_MAX` limit to records from the cache as is
done in `_prefetch_field`.
Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.
Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.
Fixes#18511
In the main_flow_tour, we edit a related record of a many2one in a
one2many. A modal is displayed and we make some changes. We
then click on 'Save' in the dialog. The next step is to add a new record
in the one2many, so we click on 'Add an item'. However, we didn't
wait for the modal to be closed before clicking, which is actually not
possible in practice (because of the modal backdrop).
This made the tour fail when run from the browser, since commit
c300e5e, which produces a redraw of the line containing the
many2one that has been edited.
This rev. ensures that we wait for the modal to be closed before
adding a second record.
This patch modifies Root#dispatch() in order to keep the httprequest url
in the current thread's attribute and use if for dumpstacks and the
phantomjs tests remaining requests handling.
Also added a counter in order to avoid looping forever when trying to join unclosed http requests
in phantomjs test suite after a phantomjs failure + added a log.warning in such a case so it's easier to troubleshoot runbot's ir.logging.
- Activate multi-company
- Company B is parent of Company A
- Admin is in Company A
- Demo is in Company B
- Create a rate with Demo
The rate is recorded on Company A, not Company B as expected.
This is because we call: `self.env.user._get_company()` which would be
equivalent to `self.env.user.env.user.company_id`. Since the user is
browsed as `sudo`, it returns the company of the Admin.
opw-753139
Bug introduced in https://github.com/odoo/odoo/commit/c8601f4384e0c95abc92d1f0b3092cfe2cb2a79d
Purpose
=======
If a module installation is supposed to load an action (example: a wizard like in l10n_eu_service) and if the related action is defined in this module (example: l10n_eu_service.wizard), currently we're using the environment defined on self, which is not updated after the module install, and the key is not defined in the registry.
Specification
=============
Instead of using the environment on self, let's use the new environment created after the cursor commit.
UserError uses a retrocompatibility function 'except_orm' which one can take a
second parameters. The default value of this second param is None, so if we
don't force an empty string, we will see a None on each raise UserError as last line.
In case Postresgl access rights prevents the pguser to access
`pg_database`, the server should not crash when trying to create the
database because the pguser does not have the right to check if the
database exists and he won't be able to create a new database anyway.
However the database might exists and in such a case the flow should
continue. This patch allows the flow to be resumed in such a case, and
in case the database did not actually exists, a warning will tell the
user that it was not possible to check if the db existed and the
registry for this database will fail to be loaded afterward.
In previous versions, readonly used to prevent sending the values
of the fields to the server. However, it was not working properly
for fields which have their own sub-arch in the view, as the value
used to be sent regardless of the readonly value.
In the new views, the readonly modifier is never overlooked, which
created a bug in the stock_picking_return wizard which was not
able to return products received from a po anymore. Basically the
value of the product_id field was not sent so the create crashed.
This commit introduces a new "force_save" modifier which is used
to express that we want to save the value of the field even though
it is readonly from a user interface point of view.
This module defines tours meant to test some cross-app workflows in Odoo.
At this time, it contains a 'tour' that do some important tasks like:
- product creation
- sale order creation
- reordering rule
- invoicing
- reconciliation
- ...
Xavier Morel