It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
backport of 74a89bcf5c656a0a64f2a699444d39739ff7f1d2
As a consequence of rev. 76cd8d2558d2a1fc11681dbc4a134ba06fb698c0,
imported modules were unable to access their resource files during
import.
Rather than further modifying the file_open API to whitelist paths
(the whole thing needs a redesign in master), we temporarily
whitelist the temporary directory by including it in the global
addons_paths, making sure to undo it afterwards.
This gives all lower level function access the resource files via
file_open, without having to pass around whitelisted paths
through many different calls.
We need to ensure the account move lines we search for in case of partial reconciliation are within the period boundaries
Before this commit, when a partial reconciliation has been made long after others, the date used would have been this former move's
because of the MAX() function introduced by commit 3128e84243
Hence for one period, if that date were to be outside the period boundaries, the entire reconciliation would have been discarded, leaving the period due amount to 0, but a non-null total
This commit still uses the MAX() function, but specifies the aml date must be within the period boundaries
OPW 740793
OPW 725890
Closes#17098
For an unknown reason, in some case, urllib doesn't work while with urllib2 it works.
Since we don't have the opposite case until now (work in urllib and not urllib2), we
considere that it fixes the issue.
this commit closes#14636
Don't pass default code to child accounts to avoid raising wrongly the constraint: duplicate key value violates unique constraint "account_account_code_company_uniq"
Courtesy of Stefan Rijnhart (Opener). Was PR #16804
Description of the issue/feature this PR addresses:
The production routing is ignored when creating previous movements
Current behavior before PR:
When you create a production that does not have a routing established in the BOM, and you set a route manually, it is ignored when creating the previous movements
Closes#16366
Steps to reproduce the problem:
- create 2 company
- create 2 different sequences 'payment line', one for company
- create a payment order for company A and insert a line
- create a payment order for company B and insert a line
Get SQL error saying The payment line name must be unique
The '/point_of_sale/display' controller is added in the hw_screen module.
This module is not loaded if the init scripts are not modified.
This means that updating a posbox with the internal update feature will not work.
This adds the link only in hw_screen and display an information message for old
versions.
If an exception during the merges (such as a file descriptor overrun), we
would otherwise depend on the next garbage collection to close the
files. But the next GC may never come.
For example if we ran out of OS file descriptors during merge, all future
requests will crash for the same reason, and the process will never recover
because the GC will never run.
Much easier to explicitly close the files all the time.
In some email templates of Odoo, the From: field is generated from the
company name. If this name contains an "&" character, this will lead in
an escaping eg; &
Sender header will look like:
From: Machin & Brol <machinbrol@toto.com>
This case is not well handled by email providers like Gmail, that
splits the line on the ";" and considers there are 2 senders, and then
discards the email.
We then fix the templates, waiting for a better fix in master.
To reproduce, see issue #16611.
In the mentioned use case, a line with a quantity of zero is created,
which generates a traceback at invoice validation.
Fixes#16611
opw-741055
Don't check ids with "id is None" statements, as it won't match if id is False. This caused some bugs with MRP when confirming a MO with no calendar defined, if mrp_operations was installed.
On IE (from 9.0 up to at least IE EDGE 14) we have this behavior
for the method serializeToString of XMLSerializer:
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0])
'<b xmlns="http://www.w3.org/1999/xhtml">"</b>'
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0].firstChild)
'"'
Whilst browser such as chromium or firefox have:
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0])
'<b xmlns="http://www.w3.org/1999/xhtml">"</b>'
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0].firstChild)
'"'
Hence for IE9 and over, if in a `<t t-extend/>` a `t-jquery`
sub-directive (without `t-operation`) is available, we can have
broken javascript if a " is transformed into an " at a unfortunate
location.
This commit favour node.data over XMLSerializer serializeToString to
avoid the possibility of this issue when a text node is processed.
opw-727283
When deduplicating contacts, the function _process_query doesn't use
the orm to fetch the partners to merge according to the criteria.
So there were some access error in multi company when trying to merge
contacts from a not allowed company.
Now a check is made with the orm before merging the contacts.
opw:708457
When a user belongs to multiple groups, and an ir.rule is applicable for some of
them, the rule is added multiple times in the domain. Just do it once. This
makes the query shorter and easier to debug.
Searching on a domain like `[('m2m.sub', operator, value)]` currently does
something like:
right_ids = comodel.search([('sub', operator, value)]).ids
table_ids = model.search([('m2m', 'in', right_ids)]).ids
and reduces the domain triple to `('id', 'in', table_ids)`.
The domain triple can actually be reduced to `('m2m', 'in', right_ids)`. With
this reduction, the search on the field `m2m` will be done as part of the main
query. And this will also enable the optimization of the former fix!
Avoid pathological performance issue caused by injecting ids retrieved with
another query.
Consider a domain like `[('m2m', 'in', ids)]` on a many2many field. The
current implementation will perform the subquery:
SELECT m2m_id1 FROM m2m_table WHERE m2m_id2 IN (ids)
and inject its result into the main query as:
SELECT id FROM ... WHERE id IN (result_ids)
The latter may be very slow if `result_ids` is a huge list of ids.
The fix injects the first query into the main query as:
SELECT id FROM ... WHERE id IN (
SELECT m2m_id1 FROM m2m_table WHERE m2m_id2 IN (ids)
)
As a result, the database will typically JOIN both tables, and avoid generating
the whole list from the subquery.
- Create an invoice of 10000 at date 2016-11-30, due 2017-02-28
- Make a partial payment of 1500 at date 2016-11-09
- Make a partial payment of 1000 at date 2016-11-30
- Make a partial payment of 2000 at date 2017-01-30
At current date (e.g. 2017-04-04), run the Aged Partner Balance. 5500 is
still due, but set to the +120 days period instead of 30-60.
opw-725890
When expanding a textarea of an editable list,
by putting a long description for instnace,
with multiple lines,
some elements were put above the textarea,
making the content partially hidden
opw-709894
Closes#16083
On large databases, the orderpoint calculation can fail due to the huge
cache used diring the process.
Instead of using one cursor for the transaction, we create a new cursor
every 100 orderpoints, to limit the cache size and speed up the
performances.
opw-726711
Closes#16158
In case you don't have 'field', the first 'if' will raise a warning.
In this case the second 'if' will crash with:
"'NoneType' object has no attribute 'store'"
This commit closes#16146
Courtesy of @kmetaxas
A rounding issue was resolved in
ee33593351. It however introduced
another issue.
Rounding functions (both round_precision in web.utils and float_round
in openerp.tools) are not perfect due to IEEE floating point
limitations. However both should produce the same output given the
same input. An example: rounding 13.95 to 2 digits yields
13.950000000000001.
The additional rounding introduced in
ee33593351 on price lead to issues in
certain cases. One example occurs when applying a 90% discount on a
product costing 13.95. The POS will do the following:
> 13.950000000000001 * 0.09999999999999998
1.3949999999999998
> round_pr(1.3949999999999998, .01)
1.4000000000000001
whereas the backend will do (as eg. in sale.order.line)
>>> 13.95 * 0.09999999999999998
1.3949999999999996
>>> round(1.3949999999999996, 2)
1.3900000000000001
Causing a difference of 0.01.
The core of the issue is that in the backend 13.95 is rounded
differently. When a Float gets written to the database doesn't just
pass through the regular float_round. It passes through
_symbol_set_float which truncates characters exceeding the precision.
This implements the same approach in the POS.
opw-715506
Closes#16119
Before this patch, #15920 was happening. The problem was that calling `render_cell` produced a call to [`record.set(column.id + '__display', value)`][1], which triggers the `change` event, which called `render_record` the first time, which called again `render_cell` and produced the 2nd data fetch.
After this patch, `render_record` is only called if there is some place where to put the result, which does not happen in those situations.
There is still the problem that there is one call to name_get for each many2many widget found in a list view (instead of one per full view rendering), but at least they are not two calls!
[1]: 5d17749ff4/addons/web/static/src/js/view_list.js (L1125)
- Activate the MTO route on SO lines
- Activate the route "Buy" on a Product A without quantity on hand, add
a supplier
- Create a SO with 2 lines. First line is Product A, second line is
Product A with route MTO
- Confirm the SO, run the procurement if necessary
- Confirm the PO, receive the products
- On the picking generated from the SO, you should have one line
"Waiting Availability" (the line not MTO) and one line "Available"
(the line MTO).
- Click "Recheck Availability". One reserved quant from line 2 is moved
to line 1.
A trick is to assign first the move with ancestors, so we don't "steal"
the reservation on the other move.
Fixes#15950
opw-725373
xmo-odoo
Olivier Dony
Raphael Collet
Lucas Perais (lpe)
Odoo Translation Bot
Jeremy Kersten
Stefan Rijnhart (Opener)
jesusVMayor
Yenthe V.G
eLBati
Martin Trigaux
Jerome Boisvert-Chouinard
Kevin Graveman
Jérome Maes
Dainius Kaniava
Richard Mathot
Nicolas Martinelli
Christophe Simonis
Olivier Colson
Nicolas Lempereur
Goffin Simon
Ronald Portier
SEINLET Nicolas
Jerther
Denis Ledoux
Cédric Pigeon
Jeremy Kersten
Joren Van Onder
Jairo Llopis
Wolfgang Taferner