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.
link_tracker use a regex to determine the content of
a 'href' tag, taking the 'mailto:xxxx@yyyy.zz' case
into account. mass_mailing use another regex that simply
don't.
So when sending a mass mailing containing email link,
the email will be appended by url path of tracking
url '/m/<stat_id>'.
This commit makes mass_mailing use the same regex as
link_tracker (which is in the dependencies of mass_mailing).
opw-727779
In v8, it was not allowed to create a DB with a name containing a space.
This should still be the case from v9 since it causes issuesfor backup
scripts, for example.
Reintroduces 1a0e9063d4
opw-727613
The group by on state in this search view cannot be used due to a typo
in the 'state' field's attribute "stored=True" dbe3d8035f
It can't be fixed in 9.0 as it would change the schema, hence the only
option is to disable this filter in 9.0
This should not to be forward ported to 10.0 as it is already fixed for
this version in 3451ac5254
Mobile browsers attempt to scroll invisible input elements into
view (eg. when they end up hidden behind the on-screen keyboard). The
browser does not always correctly undo this. This is problematic
because the main window in the client list is not actually scrollable
for the user, so you ended up with part of the widget cut off. This
implements a workaround that scrolls to top when input elements are
blurred. Removing the blur handlers is not necessary because the input
elements get removed.
opw-706781
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.
The type of account Vorsteuer 2500 is Non-current Assets(like in l10n_be).
In this way, the amount due will include the taxes Vorsteuer 10%
and Vorsteuer 20% when computing the amount due with _compute_residual
because the account is not receivable or payable.
opw:725619
- 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
In 9.0 in some particular instances with embedded views, if:
- an x2many list view is editable,
- we go from a form view of an existing record to creating a record,
- the timings of deferred resolving are in a certain order
the x2many list view could be tought as loaded whilst in reality it is
the 'editable list view' row editing 'form view' that has been loaded.
This could cause sometimes issues after bc031379 because the onchange
computation would happen before the list view is really loaded.
This is probably an issue with the deferred system in one of the views,
but it would be rather hard and dangerous to change it.
So this fix introduce an additional test which ignore relational views
if there is an embedded view.
opw-726701
opw-726768
note: only needed for 9.0, the relational views have been changed as of
saas-11 and this issue is not present.
Currently line was incorrect as the purpose is to ensure all lines of
the scheduler are sent. Currently not send lines are filetered and therefore
not taken into account. This commits fixes it.
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
Both tree and form view have the same sequence, which haas, at best no effect,
at worst, shows the form before the tree view.
In the second case, making that clicking on the bank journal name drives you to
a new bank statement instead of the list of existing ones.
Closes#16187
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
Before this commit, in dev mode, the view was read from xml with the dummy
template. Set arch_fs to False will force to use the view in database and so
the automatically computed view.
This commit closes#16179
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
On a form view the attribute `use_contacts` will:
- when set to True: enable us to add contacts which will be available on
any time in the calendar,
- when unset: the list of contact is only the contact currently beeing
seen directly in the calendar.
The feature for adding contact is thus not necessary when
`use_contacts` is unset. But it still appeared without having any effect
(which is unexpected).
This commit remove the contact adding feature when it has no necessity.
opw-715932
- Activate multi-currency
- Create an invoice in a currency different from the company currency
- Go to Accounting > Reporting > Management > Partner Ledger
- Activate the option "With Currency"
The report printed doesn't contain the amount currency.
opw-726440
When there is no move line linked to the picking, the customer address must
be the address of the partner linked to the stock.pick
Backport of this commit: 79d8849
opw:725721
There was an issue when selecting a video tag:
- a tag inside the video tag would be selected instead of the video tag
so video could not be removed or modified (modifying it would add a
video or image inside the video itself and so on).
- the selection was not conveyed to the editor so it would be lost
consequently due to some code who restored it to what was saved on
the editor.
This fix solves this by changing how the video tag was selected and
saving the selected range on the editor.
opw-724701
- Create an asset category with a journal of type "Purchase" or
"Miscellaneous".
- Create an asset in a currency different from the company currency
- Validate and post the first entry.
The error "The amount expressed in the secondary currency must be
positive..." is raised.
The sign is determined by the journal type. However, in case of an asset
depreciation or a deferred revenue, the amount is always positive. The
amount is negative in case of an asset created from a refund invoice
(see commit c844534f8a).
There is actually no need of a `sign` variable. In case amount is
positive:
- first move is a credit, therefore `amount_currency` is negative
- second move is a debit, therefore `amount_currency` is positive
In case amoutn is negative:
- first move is a debit, therefore `amount_currency` is positive
- second move is a credit, therefore `amount_currency` is negative
opw-725358
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
- Have a contact in language A
- Be connected in language B
- Go to repair and create a repair order for contact with language A
When printing repair order report (quotation), it is printed in language
B.
opw-725060
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]: https://github.com/odoo/odoo/blob/5d17749ff47c02294d5ff2ae56bbcef9d082562e/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
SEINLET Nicolas