- Create 2 SO, one with a down payment
- Validate the down payment invoice
- Select both SO, and choose "Invoice Orders"
- Create the invoice

The down payment is not deduced from the invoice.

It is more logical to take it into account at this point of the process.
However, changing this in stable is a major change of behavior.

opw-779954

Closes #20907

Added options to reverse entries automatically based on a cron job.

Was PR #18626. Was task 35012.

Currently composer is inherited in those four modules to add a specific
behavior when sending the invoice / quotation by email. Purpose is to
mark it as sent, using a magic context key.

This commit keeps the feature but changes the implementation. It is now
done by overriding message_post which should be the entry point for all
message-related features.

According to FP: It should be possible to edit the billing address, and
delivery address on the SO, even if it's confirmed. (Not if locked)

(defined as the one with the lowest sequence in the chart template)

In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget.  As a result, the environment was not properly
restored at the end.

In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)

get_dsn_parameters may return in some edges cases (like on runbot)
and empty value for the user.
So it should not be used here, instead, a SQL query is able to provide
the currently connected user.
Also, get_dsn_parameters is new in psycopg 2.7.

This rev. introduces a new test suite meant to test the webclient
components on mobile devices. The key 'config.device.isMobile' is
forced to true in this test suite, so that mobile specific JS files
are properly executed, which isn't the case in the classic JS test
suite (setting isMobile to true in the test definition is too late,
as the JS files are already processed).

For now, this new test suite contains a single test, which was
skipped until this rev. as it couldn't be executed in the classical
JS test suite.

Both suites are executed at each build of the runbot, and they
can be manually executed from the webclient as well (via the debug
manager).

* Fiscal positions: add stat button for 'Active' (instead of checkbox )
* Customer Invoice line form view no need for purchase order remove(or hide in customer invoice) and put Anallytic tag field in form view
* Currencies sorted based on active field (so we can see all active currency first)
* Improve graph for bank and cash journals on dashboard: based on ending balance and statement lines.

Was PR #14833. Was task 29541

list_price is the base price of a product which does not include
price_extra.

Note that in the backend the pricelist computation uses

product.price_compute('list_price')

to compute the base price on which to apply the pricelist. For
product.product this seems to be equivalent to the lst_price computed
field.

The original list_price field is unused but has not been removed to
avoid breaking any 3rd party code that is using this field.

opw-781629

When `rating` is installed, a few more queries are executed...

Recent changes in tracking fields add a new query. Adapt tests.

Closes #20801

The groups were set only on the view which does not prevent abuses.
The fact that users can bypass the groups on the view is not critical as the
changes are logged but this should be improved nevertheless.

In master, proper record rules should be set.

Closes #20427

Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
  B which modifies A

In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work

The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields.  However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.

Note: the test system had to be adapted to more closely simulate what
actually happens.  In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code.  This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.

When Odoo is started with a db_user using 'postgres', the process
exits with a status 1. However, this can be bypassed when the
PGUSER environment variable is used.
This commit will prevent the usage of the 'postgres' for the
environment variable too.
Also, when trying to list db's, various methods where used to find a
suitable postgres user to get this list.
In fact, as the db cursor is available, a user is already at work.
So, in order to avoid code duplication (e.g. verify user from
environment variables), this commit removes those various method
and get the db user from the cursor.

Commit[1] tried to improve the usability of the pick + pack + ship + a
fixed procurement group scenario by erasing the origin value on the
groupped ship that refered wrongly to only the first downstream document
(and in fact refered to multiple).

We forgot the scenario into which we add a sale order line. In this
scenario, we also go through `_assign_picking` and, if an existing open
picking is found, we also wiped its partner and origin value, which was
indeed wrong.

We fix this scenario by being more precise on the erasing condition.

[1] 4a5f0765

Before this commit, an issue occured when you tried to
create a new record in a editable grouped list view.
A new line was created with an undefined group.

Editable grouped list views are not supported.
So now, we have to switch on the form view when
you click on create. This behavior is already implemented
when you open an existing record.

In 11.0, this part of the code has been removed.

When choosing the shipping address in the cart, if a tax has been mapped
by a fiscal position, the subtotal was not correctly computed.

opw:778405

Closes #20782

Since 3d04e448, the reports must start with a `article` class, not `page`.
The report was not adapted.

Fixes #20066

adapting #20279 to v10

Before this commit, when starting a livechat session as a public user and continuing as a portal user, the livechat crashed
(the poral user couldn't see the channel created before as Admin)

After this commit, the conversation is kept and security insured by the uuid in the cookie

OPW 775568

closes #20281

* web_editor, website_twitter

- There can now be multiple animation widget on the same element
- Animation are destroyed before saving the editor (allows to not be
  forced to do that destruction / code duplication in many cleanForSave)
- .data('snippet-view') is definitely dead

Was PR #18931

Snippet options were not receiving proper data parameter on
instantiantion due to a websitepocalypse wrong adaptation. Those
data are parameters to tweak an option behavior, directly defined
on the option's <div/> in the XML. By mistake, they were now taken
on the child <li/> element (main DOM element of the option).

A visual example of the bug is the overlay colorpicker displaying
"Background Color" as a title instead of "Overlay Color".

Before this revision, only the FormView allowed to reuse the same datapoint.
This was only used when opening a FormViewDialog when opening the form view
of record in a one2many field.

However, this could be useful in other places for other views. In Studio for
example, we need to instantiate a x2m view without the parent view ; we thus
need to be able to reuse the same model for all basic views.

A domain could contain the key `parent` (in an embedded subview), like:

    domain="[('display_name', '=', parent.display_name)]")

This is currently not handled by the DomainSelector.

This will probably be handled in a future version but for this stable version,
this case that triggered an error is now catched and an error message is
displayed in the widget.

This was causing a traceback when opening a domain with `parent` in the edition
of a subview with Studio.

The method `_process_jobs` provides an alternative API to process the cron
jobs, that does not catch exceptions and log them.  This makes the processing
of cron jobs easier for scripting.