In installation script or documentation

Fixes #10052

task 21446

The default group_by for 'Date Invoice' in 'account.invoice.select'
view must group the 'account.invoice' with the field 'date_invoice'.

opw:660033

Context was a new one instead of updating the existing one. This was
preventing a correct context propagation.

When a product is linked to several "supplier.info" records with
the same name or same product_name, the name or product must only
appear once.

opw:660107

By default, users can only create/edit/unlink
personal `ir.values`, the values with themself as
`user_id`.

Setting the default `deposit_product_id` should
therefore be done as sudo in case if the `deposit_product_id`
default value has already been created before by another user
but is no longer valid.

opw-660180

To be consistent with the needaction icon
already used in the tasks/issues kanban view

Timesheet lines are meant to have no product, and instead rely
on an implicit "Service" product. The UoM used is the company's
project UOM (project_time_mode_id), and the nominal cost of this
product is set on each employee.

Forcefully using the SO product as was done before is useless
and actually caused inconsistencies. The `unit_amount` value
would be expected in the UoM of the SO product, while still
being computed/set in the company's project UoM.

When no nominal cost can be found for an employee, the cost is
assumed to be 0, so the `amount` value is 0 too.

In addition, the product field is not supposed to be visible on
any form where timesheet lines are recorded.

This patch fixes various bits of logic related to this, including
parts which expected the `amount` value to be non-zero, or
the product to be set.

Zip range and state filtering were added at
377a6eca, but the
precedence between country, group, vat_required,
and not required were not correct.

This commit fixes the precedence as follows and adds
the corresponding tests:

 0. Explict position on partner
 1. Direct match on all criterions
 2. Match on country+zip before country+state
 3. Match on country before country group
 4. Match on `vat_required` criterion on all
    the above before trying them all again without

Where do you come from?

And reexport some missign terms

Before this revision, the button "Pay now" on the quotation
in the frond-end was display only if the sale order
was in the state `manual` and that there was not
yet any payment transaction.

The thing is, since the release of 9.0,
the `manual`state no longer exists in `sale.order`,
and the pay now button was therefore never displayed.

From this revision, the condition to display the button
is based on the `invoice_status`, which need to be `to_invoice`,
meaning there is something to pay:
 - The sale.order needs to be in states `sale` or `done`
 - At least one line has to be invoiced:
   - If the product has the `invoice_policy` set to `order`
   - or if the product has the 'invoice_policy` set to `delivery`,
     and at least one quantity has been delivered.

opw-659931

As the stat button "Quotes(s)" counts Quotations only (draft SO),
and the stat button "Orders" sum the total of Sales orders only (confirmed SO),
clicking on the buttons should open the SO list with the according filters
set.

Closes #9715
opw-660041

Regression introduced with 3e8727e2
opw-654063

This revision is related to 5257721b

`record._columns` doesn't contain all record fields,
computed non-stored fields are not included in `_columns`,

Therefore, when a computed non-stored field was used in the QWeb xml,
this crashed with a Keyerror exception.

Using `_fields` solves this issue. Nevertheless, translate
is not always set, but is set when the fields is indeed translatable,
so the use of `getattr` was required.

opw-660072

The "user_id" linked to the employee_id set on the sheet must be used
when editing a sheet.

opw:659647

Copy-paste error...

Before this rev., no notification was sent on the bus when the user presence
changed. Thus, the bullets displayed in Discuss were never updated and stayed
as they were on the initialilization of the chat_manager (on webclient launch).

This rev. makes the bus.presence notifications work, and handles them client
side.

Moreover, the disconnections detection is now performed at each poll (with a
maximum of 1 per minute), instead of randomly (1/100 chance) at each poll, as
it scales better than the former solution. We also added a cron that performs
this check every 5 minutes. It is needed to detect that the last connected user
just disconnected (useful for visitors in the website, trying to talk with a
livechat operator).

Also, the 'away' status is now handled client side, as it makes more sense
that way (being away at each poll, e.g. every 50seconds, during 10 minutes
doesn't mean that we didn't come back between two polls).

Finaly, in bus.js, CrossTabBus, we moved the code writing in/reading the local
storage after the tab registration as this code depends on the fact that the
tab is the master tab or not (and this is known only once the tab is
registered).

This rev. was necessary in stable because the livechat uses the user status to
detect if there is an operator available, and this was often inaccurate.
Moreover, it improves the user experience of the chat in the backend.

The traceback ocurred when the operator closed a livechat channel chat window,
and then unpinned it from the sidebar in Discuss. Then, if the visitor sent
him a message, the channel was automatically re-pinned to the operator, who
received two notifications: the first one being the new channel info and the
second one the message itself.

The channel fold_state being 'closed', the window manager was trying to close
it again, which produces the traceback as the channel didn't exist in the JS
cache anymore (it was re-added to the cache when processing the message
notification, so just after).

Anyway, closing this channel was useless as, even if it was in the cache, it
would already been closed. So this rev. simply checks whether or not the
channel is in the cache before trying to close it.

The problem was that, when calling 'match_rules()' from the loader template,
we compared the wrong url with the url regexp defined in rules. Indeed, we used
the url of the page we were leaving, not the one we were going to.

We thus need to know if we are coming from the controller, or from the loader
template directly as the way to get the correct url differs.

Courtesy of JEM

- use channel configuration for the auto_popup
- clear auto_popup timeout when chat open to prevent opening the chat twice
  if the user opens it himself before the end of the timeout
- don't send message when no feedback given

The problem was that users couldn't write characters like <, > in their
messages because the messages are html (e.g. '3 < 5' resulted in '3' because
this wasn't html valid so the second part was trimmed).

Because of mentions, we can't force messages to be plaintext (mentions are
processed and replaced by html links before the message is stored in DB).

The solution is to escape them just before processing the mentions. In the case
of chat windows, we must be careful because chat windows are also used for the
livechat, for which messages are plaintext. So the escaping should be done for
chat windows in the backend, but not in the livechat.

Clicking on a channel link should open that channel in Discuss, not the channel
form view.

humanreadble arg comes as a string, so bool(0) was True. Cast it to int before.

[FIX] account: when doing a reconciliation from journal items, amount was rounded with incorrect precision

Currently, the m2m tags widget would only display the name present in
the "name" field. This prevent them from being used with custom
fields/models and other niceties.

opw-658490

Before this revision, in the ecommerce,
a new payment transaction was created only
when the transaction reference was different than
the order number, meaning that the transaction id
in the user session no longer refers to the current order,
that the user created a new order which has nothing
to do with the transaction he has in his session
variable `sale_transaction_id`

This made sense when the transaction reference
strictly matched the order number, but,
since f89e8f9d,
this is possible that a payment transaction reference
number no longer strictly matches its order number,
as the transaction reference can contain `-1`, `-2`
at the end of its reference, meaning there was
already another transaction existing with the sale
order number as reference. But the transaction
is still about this order.

Therefore, from this revision, the condition on
which a new transaction has to be created
should no longer be based on the transaction
reference, but to which `sale_order_id` the transaction belongs.

In addition, we add two more conditions for which a new transaction
should be created:
 - The transaction has been cancelled or in error
 - The acquirer has changed.

For the second case, this is to handle a corner case:
 - The user selects one payment acquirer (Ogone), then click
   on "Pay now", and is therefore redirected to the payment provider website (Ogone)
 - Then, the user opens a new browser tab on the ecommerce, on his cart,
   choose another payment provider (Paypal), then click "Pay now" and is
   redirected to this second payment provider website  (Paypal),
 - Then, the user comes back on the first tab, on which he is on the first
   provider website (ogone), and pays/validate the payment
 - Then, we receive the payment feedback (either from the user/DPN, either from
   the server to server call/IPN)

Before this revision, this use case would have lead to the feedback from the first
provider (`/payment/ogone/accept`) while the transaction is set with the second
payment provider (`Paypal`), therefore breaking the payment validation.

Creating a new transaction when the user changes of payment provider solves this issue.
He will nevertheless be able to pay twice, on each provider, but it was
already the case before.

opw-659294

Reverted because it causes issue #10083 when serializing
nexted x2many values, and produces invalid x2many commands,
such as:

    `[[6, false, [[5, false, false], [6, false, [8]]]]]`

Pending a proper fix for the oririginal issue.

This reverts commit 7e2628ae.

Closes #10083

In 9.0, we created a simplified form view for mail templates, in
which the model_id field is retricted to show only the models for
which mass mailing makes sense. However, two of those models were
forgotten. There should have been some sort of override in their
respective modules, but considering the nature of the domain
attributes, there is no easy way to write such overrides, which is
probably why there wasn't any override to begin with. We decided
with tde and al to just add these models in mass_mailing, thus
breaking module abstraction, but avoiding a very complex override
mechanism for a rather simple case like this.

The function "_default_picking_type" must return a browse record.

User can't edit the first and last chars of a link (same issue for a lot of editors), and users don't want to click on edit link button in the editor bar.
When the user click (not if the user use arrow) on a link the link is activate with a content editable true and can edit the first and last chars.

opw: 654280

fixes #10074

* chat windows:
  - input was kicked out of the window on chrome 43
  - don't animate if folded by default (e.g. after a refresh)
  - width and height 100% like in the frontend
  - z-index to make sure that they are over bootstrap active btn,
    but below notifications, and modals

* chatter:
  - internal note: send button renammed to 'Log'
  - send button is the first button again
  - remove annoying form view widget's tooltip

* client action: focus on composer on channel change

- Don't display livechat button if no operator available
- Livechat windows persistence through website pages
- Auto popup feature re-introduced (inadvertently removed at rev. f23f57cc)
- Operators that are 'away' are available, as 'away' means that the focus isn't
  on the Odoo tab for at least 10 minutes, but the user is still connected.
- Avoid duplicated messages when the visitor is a connected user
- Unfold livechat window on first 'close' click as the event is intercepted to
  ask the user feedback before actually closing the window

When the partner already had a user,
checking `in_portal` of this partner and applying
the wizard raised the fact there was already a duplicated
user for this email, even if there wasn't.

This is because the system relied on the fact
the field `user_id` of the `portal.wizard.user`
was automatically filled with the partner user if
there was one, but it was not the case:
This `user_id` field is a simple many2one field,
not computed, and the assignation was done nowhere
when the partner already had a user.

The assignation should be done in the `onchange_portal_id` method
of the `portal.wizard` model, like the other fields
`partner_id`, `email` and `in_portal`,
but if we do it know, as the `user_id` field is not
in the view (not even in `invisible`), the
web client will ignore it even if returned by
this `onchange_portal_id` method. It was therefore pointless
to solve this issue by adding the correct `user_id`
in the `user_ids` returned by this onchange method.

We could add `user_id` in invisible in the view,
but existing databases with the current view
will not benefit of the bug fix without updating the according view.

This revision therefore replaces `wizard.user_id` by
`wizard.partner_ids.user_ids[0]` everywhere where it's needed to
know if the partner already has a user or not.

Besides, it takes care about the fact his user could
be disabled (`active` False).

opw-659339

Otherwise Micheline ratings will be overridden by Raoul ones.

Delegate the whole default sales team computation to the _get_default_team_id
of sales team to ease the overriding and understanding. Otherwise part of the
behavior is implemented in crm, part in sales team, leading to a difficult
overriding.

Order

 - team the user is member of
 - team in context
 - Direct Sales