Include libsass instead of node-less

Thank you to @d-fence for testing this.

The 'oe_link' class is not linked to any style. The class is
automatically converted to 'btn-link' for <button/> elements but this
will not be done on <a/> elements as they are (nearly) unprocessed
node during views rendering.

Also there is minor difference between a '.btn-link' element and a
<a/> element anyway (and maybe there should not be at all).

* test_main_flows

The style of a primary/link button is given by the
'btn-primary'/'btn-link' class. The old 'oe_highlight'/'oe_link'
class should still be supported in views but not rendered in the DOM.

Button rendering was most of the time wrong, incomplete or performed
with duplicated code. This led to:
- Both primary and default classes were put on some statusbar buttons
- Icons were not able to be put for statusbar buttons
- Stat buttons and list buttons code were duplicated
- Classes and style were added twice
- ...

This commits adds a field on bank statement that will be used to force the creation of the accounting entries at this date instead of the bank statement date (in the same way than on invoices). This is useful if the accounting period in which the entries should normally be booked is already closed.
This field is only visible in debug mode.

Was PR #22441
Was task 46892

Was PR #14820
Was task: 28716

Whenever we add or delete a channel in the bus/longpolling system, we
want the long poll to restart immediately, to be able to receive the
correct messages.

Before this commit, we had to wait for the longpoll timeout to finish
before receiving the correct messages.

We have a need to be able to abort a pending xmlhttprequest.  This is
necessary for the longpoll system so it can restart properly.

With this commit, we simply propagate the abort method from the jquery
deferred to the deferred returned by the session rpc method.

Note that this is not documented on purpose. The reason is that we do
not want to commit on maintaining this feature.

It is kind of awkward to have a deferred which can be aborted, but once
it is chained, the abort feature is lost. So, for now, this will stay a
lower level feature used exclusively for our needs.

This commit allow to filter easily on partners or partner categories in financial reports

Was PR #23364
Was task: 36626

Since 348c371e, the quantity is negative
for out moves. Ignore the sign when computing the amount_currency value.

The website sale wishlist tour checks if you are correctly redirected to the
cart.
To do so, it checks if the cart title 'Shopping Cart' appears on the screen.

But since there is a new checkout in saas-11.3 with 006ce9c8 that removed this
title, we need to trigger on something else.

Instead of:
1. testing the existance
2. creating the directory if not exists

(which would not work if a concurrent creation is done between step 1 and 2)

do:
1. try to create the directory
2. skip if it fails

Ask forgiveness, not permission

Closes #24210

As the company is not required on a sales order, this could lead to
errors when trying to compute the margin as _convert is expecting
a valid company.

This was introduced as a fix for grouped list views' headers while we
should have added the 'o_list_number' class instead... which is the
case now. So the oe_number rule became useless.

See https://github.com/odoo/enterprise/commit/a2ce226a2a085b26174cdfd32922517dff39658c
See https://github.com/odoo/odoo/commit/5d13a2f431e1c96e075b04d0eb07d98b912a6547
See https://github.com/odoo/odoo/pull/23966

Forward ports sucks...

Here is a scenario that could happen before this commit:
1. web client is started
2. it binds a callback on hashchange
3. it performs some async work (read initial action for user)
4. the user (or more likely, a tour) changes the url
5. the hashchange handler is called, and it starts a new action
6. the async work for the web client is over, it then executes the
default action and/or clicks on the first menu
7. we are now in the default action state, instead of the desired action
state (the one from the new url)

With this fix, we simply do nothing when there was an hashchange before
the initial action was done.

This reverts commit b8b0f947.

Oversight of previous forward-port

Was probably introduced during a forward-port as was correctly changed at 8df0a2a9

Closes #24238

Issue:
Currently, since "product_type" is not set readonly, it is triggering write() of product.product
model when saving a PO having PO line with product_id. And it is failing by throwing access error
for users belonging to purchase "User" group users due to the fact that write() is permissible to
purchase "Manager" group users only.

Solution:
Made the "product_type" related field readonly since it is used in purchase order views domain
with lone purpose to set "received_qty" field non-editable when order line product is of type
stockable/consumable.

task id 1818787

- Portal payement is not respecting the option to save tokens after payments.

When converting UoM, source and destiantion should be in the
same category. For timesheet, the product can be expressed in
Units if uoM is not activated. We don't want crash, but
interprete the timesheet duration in hours (which is has a different
uoM category). To avoid the error, we used the 'raise_if_failure'
parameter.

When converting UoM, the conversion can fail if the source and destination
uoM are not in the same category. By default, and error is raised, but using
a context key, we can receive the initial quantity.
To avoid the context key (which is not used anymore), we prefer use a dedicated
parameter to be more explicit.

Closes #24237

In the calendar view there is some mixing of moment with:

- a local date with given timezone
- a UTC date with added timezone manually applied

The setDate function of calendar model sometimes received either of the
two types, and always transforms them to UTC date with added timezone.

This cause eg. the following issues:

- in the minicalendar, if we click on a day (eg. 12) the day highlighed
  will be the one of 12th at midnight with timezone applied. So with a
  negative timezone the 11th would be highlighted in the mini calendar
  (but the 12th would still be the day shown).

- if we change scale (week/day/month) or open calendar or use next or
  previous button: we call `setDate` with a UTC+timezone moment. So each
  time this is done, we get an additional timezone

  eg. when opening the calendar view on the 12th at 5:00 with GMT-0200:
      -> the target date is 12th at 1:00
      -> if we set the day mode: target date is 11th at 23:00
      -> if we set the week mode: target date is 11th at 21:00

With this change we keep target_date and highlight_date as local date so
setDate always receives a local date and jquery-ui DatePicker gets the
date in the expected format.

opw-1831368
closes #24188

Do not allow to change the product on a serial/lot number for a product
which has existing stock moves. Doing so would screw up the traceability
report.

opw-1832452

Odoo 11 is python 3 but the xmlrpc interface works with python 2 too.
The example should probably be migrated to use python 3.
In the meantime specify exactly these examples are python 2 to avoid the
confusion.

Fixes #24232

When creating an invoice with 'Down payment' option for an SO, it should
first consider income account of the 'Deposit Product'. if it does not
have one then it should consider that product category's income account.

Fixes #23100
Task# 1819531

Remove the valuation stat button as we say that from now on, to
understand the current value of a product, you should go through the
valuation ation and its stat button.

We add the valuation at date wizard by re-using the quantity at date
wizard and adding a context key to separate the both.

The same view/action is used when openning the current or at date
valuation, only the `to_date` context key is changed.

For the standard and average cost method, we use `qty_available` at date
and the `product.price.history` table.

For FIFO, the normal way would have been to get the `qty_available` at
date and value this quantity with the more recent IN moves at this date.

But there's two main obstacles preventing to use this solution:
- when editing a done move to change the quantity, the change is
  reflected at the date, the `qty_available` at date will be incremented
- in the same usecase, the remaining_qty and remaining_value is
  incremented in place, which mean that even if the layer was already
  consumed, it's now appearing again at the bottom of the fifo layer

Fixing this issue by adding a stock move at the date of today instead of
editing in place in v11 and adding a proper "cost layer" model in master
was deemed too complex as well as unnecessary by our bosses

So we now say we continue to update in place, and when looking at the
quantity at date
- if periodic, we sum the value of the move since the beginning of times
- if perpetual, we sum the balance of the account move lines since the
  beginning of times. Also, in this case, the quantity at date is
  computed across account move lines too, via the "quantity" field on
  aml.

This commit adds three non stored computed field:
- qty_at_date: will be computed across stock moves if fifo periodic and
  across account move line if fifo perpetual to reflect the design
  choice: if periodic, we *really* edit in the past ; if perpetual, no,
  the change is done at today's date
- stock_fifo_real_time_aml_ids: the used aml to compute qty_at_date
- stock_fifo_manual_move_ids: the used move to compute qty_at_date