The field is defined but never user. It could be useful to indicate
to the delivery guy that the product is 'fragile' or whatever.

opw-728874

- Create a SO with a product that is a service and will be invoiced
  based in delivery quantities and will be tracked on timesheets and
  contract.
- Confirm
- Use a simple user that only has for rights: "Employee"
- Create a timesheet as the employee for the contract created by the sale
- Log some time
- Save it
- Check the SO: ok the number of hours should be "to be invoiced"
- Edit the timesheet and set one day to 0 hours => Access Error

In case of a zero value, the timesheet widget sends an unlink command
for the corresponding entry. In this case, the `sudo` is not set at the
appropropriate moment since the context key `force_so_lines` will resue
lines which are not defined in the `sudo` environment.

opw-728453

Issue: when a field is computed on a new record, the record is not marked as
"being computed", and it could therefore be invalidated.  The fix consists in
using the standard method that marks records before calling the compute method.

- Create 2 stockable products (A & B).
- Sell these products in the POS, but leave the qty of Product A to
  zero.
- Validate and pay
- In the backend, return the products and register payment

Two pickings are created, and one of them is empty.

Products with a quantity of zero are not included in a picking.
Therefore, we should ignore them when the pickings are created.

Fixes #16292
opw-728101

This is a backport of rev 3481f0fa.

Steps to reproduce:
-Create a product P  with a standard price = 0 and its internal category
is in perpetual valuation
-Create a SO with an analytic account and a line with one product P
-Confirm the SO
-Create and validate the invoice

Bug: The delivered qty on the SO was equal to 2 instead of 1 because two
analytic lines are created by function create_analytic_lines with amount=0.
So in function _compute_analytic, the domain was [('so_line', 'in', self.ids), ('amount', '<=', 0.0)]
and it summed the two analytic lines for these two lines. Now analytic lines with amount=0 and linked
to a move line are summed if the they are linked to entries for an account of type "Expenses"(user_type_id).

opw:727302

Step to reproduce the bug:
1.Create a product with a customer tax(15%) for a price=100
2.Create a customer invoice with this product
3.Change the amount of the tax to 10(instead of 15)
4.Validate the invoice
5.Click on "Refund invoice"
6.Select the refund method "Modify: create refund, reconcile
and create a new draft invoice"

Bug the new draft invoice has 15 as amount of tax

Now all the taxes from the invoice when preparing the refund in function
_prepare_refund, in this it keeps all the modified taxes.

opw:726491

When the scheduler is run, the reordering rules of archived products are
selected.

opw-728316

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.

Both group by filters are the same
Closes #16338

Done at #16337

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 1a0e9063

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" dbe3d803

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 3451ac52

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

When changing the quantity of a product in Optional Products modal
in the shop, the price was not updated according to the pricelist.

opw:726686

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.

Part of #16282

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

Based on v9 fix: f6b6eb90

Closes #16217

This allows the reservation in sub-locations before forcing the
availability.

opw-726060

Done at #16240

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