The _message_post_helper() method historically allowed
passing a `sha_in` signature to let an unauthenticated
user post a message on a record.

This option is unused and an alternative is preferred:
passing a `token` value that matches the value of a
given field of the record.

In light of the increasingly grim future of SHA-1
as a cryptographic hash function, we consider it
better to entirely remove this specific option.

It has been unused for a while, and a simple
alternative exists.

The `object_shasign` method itself will be dropped
in master.

Before this commit, impossible to edit the master if no language switcher
was displayed on the web page.

Some previous links could still point to old register page and so display an
error 500 if product of ticket has been already archived.

A company should have at least a pricelist having the same currency, that's common sense.
This was causing problems in tests on 10.0-nightly, where the main pricelist was created
in EUR, then the localization module was setting the right currency on the company without
any reflection on the pricelist.
To avoid this problem, when we write the currency on a company, we reflect that change on
the main pricelist if it's the only company in the system. Otherwise as we can't decide
which pricelist modify, we just create a new one, which should be ok.

When get_price() is called during tests, a ValidationError was returned but not catched
correctly due to the unavailability of delivery service.
Because this method is called during the creation of new sale order, it leads to some
operational error (broken cursor).

Closes #15620

Done at #15620

yum-config-manager is not installed by default with CentOS from some VPS companies.

Closes #15631

Add Osvaldo Jorge Gentile and remove Cesar Rodriguez from Bacgroup Organization

Done at #15630

For installations with accents in the name

Closes #15597

Do you ever think about translators?
"Bankafschrift afsluitens" is not valid Dutch

opw-709657

When the function map_tax is called on the fiscal position in repair
lines to compute taxes, the partner and product are not passed to the
method which leads to mistakes when the module account_taxcloud tries to
get back the taxes for the specific partner and tic_category of the
product.

To fix the issue, we pass the product and partner that we already have
to the function map_tax.

When updating several moves for the same product, each time a write was done,
the move.product_id.standard_price was not updated due to "with_context(force_company=move.company_id.id)"
before write. Making a with_context before write changes the environment of the write, this why the cache
was not updated.

opw:709329

The email content was a tuple instead of a proper string.
Introduced at 0028c421

Fixes tw:jaynvora/status/834435897554710528

The `rating_last_value` field was a related on the One2many
field `rating_ids`, on which the domain
`[('res_model', '=', self._name)]` is applied.

The problem is that this domain is not taken into account
when retrieving the records for which this value must be recomputed

Therefore, when computing the `rating_last_value` of a record,
if there was a record with the same `res_id` but another
`res_model`, the `rating_last_value` of this other record
is recomputed as well.

And, if you did not have the write access rights on this other
record, it raised a security exception.

There is at the moment no way in the ORM to filter the
depends on a specific subset of records for which
a computed field must be recomputed. Therefore,
we have no other choices to make the recomputation
of the records value as sudo. It will
recompute the value of other records which have nothing
to do with the one on which this value must be recomputed
(nothing to do except the id of the records which is common),
but at least it will succeed.

opw-709349

To reproduce:
1. Set a product with 'Perpetual (automated)' valuation and 'Average
   Price' costing method.
2. Make a PO of 2 units, unit price 100, receive the delivery
   => Cost of product is 200 / 2 = 100
3. Make a SO of 1 unit, unit price 250. Confirm the SO, but do not
   deliver the product and do not create the invoice.
4. Make a PO of 1 unit, unit price 200, receive the delivery
   => Cost of product is 400 / 3 = 133.33
5. Deliver the product sold
   => A debit of 133.33 is created on the 'Stock Output Account'
6. Make a PO of 1 unit, unit price 250, receive the delivery
   => Cost of product is 516.66 / 3 = 172.22
7. Create the invoice of the SO
   => A credit of 100 is created on the 'Stock Output Account'

There is an inconsistency between entries created at steps 5 and 7. The
reason is that the price unit on the stock move is not updated when the
delivery is completed.

opw-709726

When uninstalling the module sale_margin, the view 'sale_report' was deleted
because this view was overwritten  in this module.

But the module sale still uses the 'sale_report' view so it raised an error
each time this view was required.

opw:709328

Due to these commits, it was impossible to make an uninstall_hook
just after an uninstallation.

In some case, it 's needed to make an uninstall_hook just after the uninstallation.

Look this commit for example: e03c919e9955c5d3f678c0580744d9ef8c483c74

When the internal category of a product is in costing method = "Average Price"
and Inventory Valuation = "Perpetual(automated)", a button with the label
"Compute from average price" was displayed. But when clicking on this button,
it just allows to set the standard price. So the label of this button must be
"Set standard price".

opw:709329

Instead of links to 9.0 branch

Closes #15588

Done at #15590

OPW 704684

- Create a partner with an invoicing and a delivery address.
- Connect to the website as this partner, create an order
- In the "Shipping & Billing" page, the delivery address is selected
  automatically. Change and set to "Ship to the same address", and
  confirm.

The "Ship To" address is still the delivery address, while it should be
the same than the "Bill To" address.

This reintroduces the v8 behavior:
`order_info.update(partner_shipping_id=checkout.get('shipping_id') or partner_id)`
https://github.com/odoo/odoo/blob/8.0/addons/website_sale/controllers/main.py#L623

Create the following
- Create a partner of type "Company" (Address 1)
- Add an "Invoicing" address to this partner (Address 2)
- Add a "Contact" address to this partner
- Authorize this contact as a portal user

Connect as the portal user created:
- Place an order from website, add a product to cart
- In "Shipping & Billing", confirm the order. The proposed billing
  address is "Address 1". Do not change the shipping address ("Ship to
  the same address"), and confirm.

The "Bill To" as well as the "Ship To" address are set to "Address 1".
This is a regression from v8. In v8, "Bill To" is set to "Address 2",
while "Ship To" is set to "Address 1".

opw-707283

Saudi Arabia uses Saudi Riyal, not Egyptian Pound
Introduced at 932748d9

Fixes #11741

The variable `st_line` was used outside of its scope,
in the line
`move.line_ids.filtered(lambda x:x.statement_id == st_line.statement_id).write({'statement_id': False})`

It leaded to issues when calling the method
on multiple `account.bank.statement.line`: Only
the items associated to the last line were unlinked

opw-709196

The current calculation of work days is inconsistent with the leaves of
the employee in several cases.

The core of the problem is the logic of the algorithm: for a given day,
if we can find one hr_holiday within this day, we consider it as a
leave. One can easily spot several issues with the existing logic:
- if an employee takes less than a day-off (e.g. a half day), the
  complete day is considered as a leave.
- the timezone (TZ) is not taken into account when searching for a
  leave, while it is when computing the number of working hours. A leave
  from 3:00 AM to 3:00 PM in the Los Angeles timezone would then be
  considered as two days-off since it spread on two days in UTC.

The logic is therefore completely modified. For each day of the period:
- compute the work intervals (TZ taken into account, converted in UTC)
- search for a hr.holiday which completely includes the work interval
- if a holiday is found, the work interval is considered as a leave.
  Otherwise, it is considered as a normal work period.

This is a first step in improving the logic. The first faulty use case
is partially solved, since we cover now complete work intervals.
However, a leave covering only partially a work interval will not be
taken into account.

The second faulty use case is solved.

opw-707897

The below revision:
9bea8a8b

Change the behavior on how are computed the children hours
according to their stage fold state, while it was not intended
to. The subject of the above revision was an issue
in the recomputation dependence for the field
`children_hours`, but not how the field was computed.

It's important to count the effective hours when the
sub task is in a final stage (e.g. done) rather
than the planned hours in this case.

opw-709008

The computation of the `children_hours` wasn't
reset at each compute, and they ended up
to be added at each recomputation involving
the method `_hours_get`

This is a regression during migration to the new api
in revision
e6ac7a7d

opw-709008

The task progress value depends on the stage of the task,
if it's a folded stage or not.

If the task was being changed of stage, from
a non-folded stage to a folded stage,
the recomputation of the progress was not done,
while it was needed as a task in a final
stage is considered to be done.

This is a regression during migration to the new api in
e6ac7a7d

Links containing HTML escaped characters,
such as the ampersand
`&` escaped `&`
were not shortened correctly:
Their redirecting URL contained the escaped value
(e.g. `&`) instead of the actual character,
leading to the wrong redirected URL.

e.g. creating a mass-mailing with a link
contains as query string
?test1=1&test2=2 were shortened
with as redirect link
?test1=1&test2=2

opw-708272

In a lead:
- Fill in contact information (phone, address, email...)
- Create a new contact

All information is copied to the new contact, except the email.

opw-706711

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

Fixes #15092

opw:707890

Without passing `active_test=False` in the context,
a one2many fields exludes the record with
`active` set to False.

For an archived product template, this means
`product_variant_ids` returned an empty array

opw-708828