When creating translations (click on blue flag) of a duplicated record, it used
to have the module information of the duplicated record.
It is also not useful to check the module when trying to find if a translation
exists on this record as the res_id is present in the query.

Fixes #9480

Some time new background image, which I set via "Change cover" button don't saved. Because super is called before the jsonRpc and don't wait that the background is saved.

Add support email.
Closes #9803

When a make to order product is sold, a purchase order is created or added to an
existing one. In the second case, the origin of the sale order was lost.
It is now added to the existing source.

opw 656688

Load record use values as dataset and change object value (for eg: add virtual id in the default value object).

The user timezone wasn't respected in the events name.

e.g. for a user with timezone UTC+1,
for an event
from 12/01/2015 00:00:00
to   12/02/2015 00:00:00
The dates in the event name were set to
(2015-11-30 - 2015-12-01)
while it must be
(2015-12-01 - 2015-12-02)

opw-657962

It was impossible to make a partial reconciliation with several lines.
Each time a new line is proposed for the reconciliation, the previous
partial reconcialtion is canceled. The partial reconciliation can just
be proposed on the last selected line when:
self.get("balance") * (last_line.debit - last_line.credit)<0

When a translated term is modified (e.g. content of an email.template),
reloading the translations of the module (e.g. when updating the module) used to
recreate a new, duplicare translation for the modified term (instead of ignoring
the existing one).

This was due to the fact the matching expression (find_expr), when loading
translations, used the field 'src' (source term) as criteria for (almost) all
ir.translation records.

While this is true for type 'code' or 'selection', this is not true for 'model'
where the source content may have been changed.
In case of translation of type 'model', matching on the name and res_id should be
enough for the matching expression and then, avoid creating duplicated
translations.

Note: this patch must NOT be present in 9.0 due to the xml_translate
attribute that splits an xml content into small parts.

opw 654031

When creating missing translations on an object (e.g. using blue flag icon on a
field), the value of the module was not set.
This was problematic as could create a duplicated translation when the module
was updated or the translation reloaded (as the module is used in find_expr).

opw 654036

This revision is related to 93d4db9d.

Usually, for models with an image, the original `image` is stored
in the field `image`, and then the resized value are in the fields
`image_medium` & `image_small`.

In the specific case of the product variant, this is not the case,
the original image is stored in the field `image_variant`,
and the `image` field uses as well the method `_get_image_variant`.

The `image_get_resized_images` must therefore return the "big image"
as well, which is returned with the key `image`, by default.
This is done using the method argument `return_big`.

res.users form contains virtual fields in_group_ID to be added in res.groups.
Groups with boolean share=True (added by share module) must not be displayed in
the form and should not be modifiable through the user interface.
However, if a module adding/modifying a res.group is earlier in the dependency
graph than 'share' (e.g. only depends from 'base'), the update of the user view
is done before share is loaded and the overrride of 'get_application_groups' is
never executed.

As we can not guarantee that the module is share loaded, put the logic of
hidding the module in base instead of share.

This workaround is quite hacky but is necessary in stable version.
Better fix in 9.0 at cf63d4d2

Fixes #6324
Fixes #5820

This is possible to set an image for a specific variant
When this was the case, the image displayed was always the
image within its original size, it wasn't resized
to small and medium sizes.

opw-657055

When creating an invoice on delivery, the right 'account_id' was not
set on the invoice line according to the fiscal position.

opw:657542

opw-653468

ff note: no need after saas-6

This revision is related to 5a10903e.

The above revision makes so the decimal separator from the language
is used to display the prices.

This revision makes so this decimal separator is used as well
for quantities, to be coherent.

opw-657591

In the pos interface,
when adding a product to the order,
the quantity was set to `1`,
but, when adding the same product again,
the quantity was set to `2.000`.

We use `set_quantity` to not
copy/paste what is already done
in this method to display
correctly the quantity within
the product unit of measure rounding.

The password reset email is in the language of the user clicking on the button,
not in the one of the targeted user.

Fixes #9194
Closes ##9195

This revision is related to 1b8c9aed

As `manual` is now the default value of the `state`,
if `state` is not given in the values when passed to
`create` or `write` of `ir.model` and `ir.model.fields`,
we must assume the value is `manual`, so the columns and tables
are instanciated in database

opw-657750

Hardcoding the state to `open` is useless as it is the
default state, and forces the state to reset upon every
update, which is annoying.

As stated in the comment:
```
all notified_partner_ids of the mail.message
have to be notified for the parented messages
```

Record rules are applied when browsing one2many fields.
Therefore, when browsing `message.notified_partner_ids`
with a user other than the SUPERUSER, the multi-company
rules are applied, and a regular user could therefore not see
all partners of the thread, according to which
company the partners are associated with.
Nevertheless, all partners of the thread have to be notified,
including the ones the regular user cannot see.

To reproduce the issue:
 - Create a second company 'Second company'
 - Create a third user, associated to the first company 'YourCompany'
 - Set the demo user as in the 'Second company'
 - Create a project 'test' in the first company, 'YourCompany'
 - In the followers of the project, add the Demo user,
   with as subtypes "Stages changes" only
 - As the third user, create a new task in this project
 - Change the stage of this task, as the third user [this is important]
 - Sign in as the demo user, and see that you cannot access
   your messages inbox, due to an access rights error.

opw-650563

When creating an invoice from a DO,
if there is no analytical account defined on the SO,
then use the default analytical account for that product.

Closes #9725
opw-657492

This was possible to create custom fields `x_*`
but seen as base fields.

For instance,
 - Go to Settings > Technical > Database Structure > Fields
 - Select a field (any)
 - Click on the model link, to be redirected to the model form
 - Edit & add a custom field from there.
 - Save
 - Notice that the field you just added is saved as a base field.

We solve this issue by assuming that all created fields and models
are customs, except the ones created by the ORM, by the database
initialization, the fields coming from the modules in python.

We therefore remove the mechanism on which a field was set
as custom according to the fact `manual` was set to True within
the context: This is now the case by default.

No change was required for the base fields: The `state` `base`
was already forced for those fields, that are created using
direct SQL requests `INSERT INTO`.

opw-657312

Locations were search & read each time you changed
the quantity of a product in a picking.

Once the locations loaded the firs time, this is unlikely
the locations will change during the operation. It shoudln't,
at least.

Therefore, for performances, we avoid to load the locations
each time the picking is reloaded.

opw-648529
Fixes #8344

`categ_sequence` are stored related fields, to `sale_layout_cat_id.sequence`.
Setting a default value for them has as side effect to rewrite
the value on the related field.

To reproduce the issue:
 - Create a sale layout category, with 10 as sequence
 - Create an invoice with one line, with this sale layout category
 - Come back to the sale layout category,
   notice that the sequence has been changed to 0.

Besides, as the sequence was rewritten on the sale layout category,
the sequence was rewritten on all sale order lines and invoice lines
having this sale layout category.
If you have a bunch of them, this could take a while.

The `categ_sequence` default value is supposed
to come from the sale layout category.

opw-651937

As atexit function are inherited by subprocess, the pidfile was always
deleted when the first worker (http or cron) died. Now, only the
process that created the pidfile will delete it.

Unsetting the URL of the menu `Home`,
in Settings > Configuration > Website Settings > Configure Website,
leaded to the unavailability of the website.

opw-657572

This applies the commits 503820ac and f26b94fd (and their subsequent
corrections) to the calculation of the discount. Indeed, the calculation
of the discount must take into account the corrected price, otherwise
the discount is wrongly computed.

opw-656604

The time_display is present in a translatable email template but was not
translated. Added the missing term.

Updated .pot file for a few missing terms.
Removed base_calendar.pot that has no reason to be in 8.0

Fixes #9573

`stock.move` & `stock.product` have multi-company rules.
There is therefore no reason why `stock.quant` could not have one.

Besides, this could lead to access rights issues,
when a user went to the `Quants` list,
in Warehouse > Traceability > Quants,
while there were quants for products in a company different
than the user company.

opw-653188

Add the possibility in the decorator to specify the `upgrade` and `downgrade`
functions that convert values between APIs.  Both function have the same API:

    upgrade(self, value, *args, **kwargs)
    downgrade(self, value, *args, **kwargs)

The arguments ``self``, ``*args`` and ``**kwargs`` are the ones passed to the
method, following its new-API signature.

Fixes #4944, #7830.

opw-657169

[FIX] account: when a payment is processed in the bank interface, it will complete the partner automatically if a single invoice is found with the same reference. As expected for a structured communication for example. Fixes opw 653452

project.task: use an onchange to update date_start when changing user_id.
Indeed date_start is automatically updated in the create / write. Without
the onchange, this may lead to errors related to date_start being greater
then date_end.

project.issue: code in create and write now takes into account date_open
values given to the method and avoid erasing them.
In issue however the onchange is not added. Indeed the date_open and
date_closed fields are not visible in the view. They are automatically
computed and used to compute statistics.

This is a backport of a fix in 9, revision 890f1302.
In this revision a context key is added wshen evaluating server actions.
Notification emails created during a server action will be set in the queue
and not send directly.

Some fixes coming from V9 revision 2be1dfc1. The
purpose is to avoid to send emails in batch and to limitate automatic
subscription.

 - add a context key to use the email queue for notifications linked
   to allocations created in batch. This way emails will be send asynchronously
   and will not create a deadlock when having a lot of allocations to process.
 - also fixed a missing context in a browse

The attribute `data-oe-*` (`data-oe-id`, `data-oe-model`, ...)
must not be added when rendering the assets, to avoid
having different assets content,
e.g. a different content for the assets_common,
according if the user is signed in or not,
if the user can edit the website or not.

A different content for an assets according to the
users rights or the user being signed in or not means
that the assets are permanently re-written in the filestore,
which is against the point of the assets.

The content of the assets (assets_common) must not be
different from time to time, it must always be the same
(except when installing a new module, obviously).
Adding the `data-oe` attributes was pointless for the assets
anyway, and prevented having an identical content all
the time, therefore rewritting the assets all the time
in the filestore.

opw-657046