Empty merge as 7bdd4de8 has already
been forward-ported with 33167a1e.

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.

The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).

This is a forward-port/cherry-pick of 7bdd4de8

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.

The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)

When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.

For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.

Since commit 2ab68047, the Paypal link can be sent in an invoice as it
was the case before. However, in order to be able to save the Paypal
account in the accounting settings, the Paypal account must be
website-published. If the module `website_payments` is not installed,
this is not possible.

We remove this condition, since it should be possible tu use the Paypal
payment method without installing the whole website.

opw-686216

This reverts commit a57b10db. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.

The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)

When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. On some status
bars, clicking doesn't work anymore.

The reason is because, in some mysterious cases, the event is propagated
to the parent. The `currentTarget` is not the `li` element, but the
parent `ul`. By setting the `immediate` argument to `true` (execute the
first function instead of the last), this solves the issue.

When a product is returned after receiving, the return picking doesn't
appear in the corresponding PO.

opw-686895

When removing the "Save as Attachment Prefix" field
of the Invoice report (`account.report_invoice`),
it was no longer possible to reset the invoice to draft

opw-687130

Since 85bcd6fd, the field `paypal_account`
has been removed. The field `paypal_url` cannot be computed correctly
anymore. Convert it to a dummy field.

When a database is created, we are not auto-logged in to the new
database anymore because the login passed to the authentication request
is 'admin' instead of the one set in the creation form.

To fix this issue, we used the login parameter from the creation form
in the authentication request. We also set the login field to
required in the create database form view.

This bug comes from rev https://github.com/odoo/odoo/commit/903733a32

When anglo-saxon accounting is enabled and the valuation of a product is
'real_time', rounding errors might occur in the price difference between
the invoice price and the product price. It occurs when the product
price precision is larger than the accounting precision.

To avoid these rounding errors, we calculate the difference as the
difference between the price before update and the price after update.

opw-686730

- Activate the option "Track Lots or Serial Numbers".
- Set the outgoing process as 3-step one.
- Create a stockable product for which the tracking is "By Unique Serial
  Number".
- Go to Sales > Sales > Sales Orders.
- Create a Quotation for the created product and confirm it. A picking
  is generated but it is waiting availability.
- You are sure to have this product in stock so you force the
  availability and assign the serial number (001) you want to transfer
  in the operation lot details.
- Validate the picking. By doing this, it creates a negative quant in
  the origin location (WH/Stock) and it creates a positive quant in the
  destination location (WH/Packing Zone). The two quants are linked to
  each other.
- Go to Inventory > Inventory Control > Inventory Adjustments.
- Create an inventory in WH/Stock  for all products and set it in
  progress.
- You want to correct the negative quantity you have so set the real
  quantity of product B to 0.
- Validate the inventory and you get the following warning: "The serial
  number 001 is already in stock.Otherwise make sure the right
  stock/owner is set".

We should allow a quantity larger than 1.0 temporary, so it allows the
system to reconcile the quants.

opw-685825

category was changed to "Website" so it'd appear under the website
category in the store, but it needs to be "Theme" otherwise it doesn't
appear in the "Choose your theme" menu after installing website.

And correct a few errors.

Closes #13350

opw-687243

Since 5a9e1af6 our guess_mimetype accepted a `default` named argument.

This commit fix the use of library used instead of our implementation, so
we don't get an error from an unexpected argument when having python-magic
installed on a given server.

Since python-magic functions always return a default mimetype:

- empty content: application/x-empty
- text content: text/plain
- binary content: application/octet-stream

the guess_mimetype default argument is not used with python-magic
implementations.

closes #13343
opw-687354

When an owner is defined on a quant, the current behavior is to to allow
only the owner to use it. This is restrictive for internal transfers:
when a quant is owned by Partner A, only a picking with owner Partner A
can select it.

The fix is to make things a bit less restrictive: when a quant is owned
by Partner A, a picking without owner or with Partner A as owner can
select it.

opw-687207

In the new API, default calls are supposed to return recordset
(even empty recordset), not bool values for relationnal fields.

If the table for this model was already present and if no l10n_x
was installed, no default value could be computed correctly for
existing entries. This caused a crash on install.

opw-683470

An entry with EXTXVAL=0 should not be included in the Intrastat
declaration, otherwise it is rejected.

opw-686201

If you create an issue when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.

Also, the stage_id was not correctly cleared if you remove the project.

If you create an issue directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created issue. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the issue, the found stage
that was not in your project is now a part of it.

The fix is to return no result if the `default_project_id` is not set
in the context.

If you create a task when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.

Also, the stage_id was not correctly cleared if you remove the project.

The less code that was resizing the login and sign up form container
in v9 was moved to the login form, but not to the sign up form.
Adding the sign up form class to the less code fixed the size.

It has been done in rev https://github.com/odoo/odoo/commit/5b65befcd889139152c590490fb8965c9f4b5279

Number of columns may have not been equal to the number of columns
headers which would cause an column mismatching since saas-11' 977d1acc.

opw-687147

If you create a task directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created task. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the task, the found stage
that was not in your project is now a part of it.

The fix is to return no result if the `default_project_id` is not set
in the context.

Before this commit, the focus point the user can move on the image in
the background position configuration dialog was only following the
mouse as we want if the image original width was larger than the dialog
one. This is because the javascript relies on the fact the image takes
100% width of its container. To fix this, the container now does not
take 100% of modal width but the size of its internal image (with a
max-width of 100%).

It might happen that a price is strike through in the shopping cart
although it has the same value than the discounted price. This can be
due to differences in decimals smaller than 0.01.

The fix is to apply the same logic than in other places: strike through
if the difference is larger than 0.1.

opw-685109

[FIX] stock: action_assign(reserve) should have a check to see if the move id is in the keys of the main_domain as was done in the previous loop

This is needed to avoid the scheduler to stop suddenly as the scheduler
takes a bunch of moves to reserve without looking if all moves of
a picking are taken.  That way, it is possible that a certain key
is not there in this dictionary and the solution is to simply
filter them out.

Closes #13286

In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order
will generate unexpected behaviour.

Eg:
> id   id_dept  name
> -------------------
> 1    1        Tom
> 2    1        Mike
> 3    2        Meggie
> 4    2        Marge
> 5    3        Bart
> 6    3        Lisa

> using LIMITed selects like:

>    SELECT * FROM employee ORDER BY id_dept LIMIT 3
>    SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3
>    SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6

> You can have some result missings from the 3 requests, and others duplicated.
> Because id_dept is not a uniq order.

opw-686639

note: backport of saas-12 4dce8616

using the --uses-first parameter on msgmerge this time

The field `processed_boolean` has been renamed to `is_done`.

opw-686941