Before this patch, any exception raised by a constraint method that
were not of type `ValidationError` were hard to debug, because the
origin line was never logged.

Explicitly logging the error (with traceback) when we catch it
ensures proper contextual info, even in the absence of exception
chaining.

closes odoo/odoo#28612

There is no `company_id` field on `stock.picking.type`.

Partially revert f221936f (#30952)

closes odoo/odoo#31121

closes odoo/odoo#30813

In Odoo, create a user John@example.com (the cap is on purpose)
In Google Calendar, create an event and invite john@example.com

Sync your Google calendar.

Before this revision,
the event created in Odoo did not add John@example.com,
but created a new attendee, john@example.com, because
of the sensitive casing.

Besides, give the priority to partners having
users, so if there are two partners with the same email,
one of them having a user,
e.g. John@example.com (with user) & john@example.com (without user),
set the partner having the user as attendee,
as its the one with the user who use the Odoo calendar,
and potentially the Google sync as well.

opw-1925592

closes odoo/odoo#31111

Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.

closes odoo/odoo#30356

This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.

With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.

Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property.  After this commit, he can.

OPW 1923345

openerp-italia.org or odoo-italia.org are not valid websites

changing it to odoo.com

OPW 1940848

closes odoo/odoo#31110

When an inline editor is eg. in a form view, the focus is always stolen
by it.

This is because we trigger a mouseup on the editor to update its
toolbars values and informations.

note: backport of 11.0's 7a453b0b

In 10.0 this trigger could cause a "blur" which in some instance is not
wanted (eg. inside a newline of a list view).

opw-1906581
closes #31078

The html widget automatically replace an empty field value by
`<p><br></p>` to be able to add content.

But this may cause unintended "onchange", since the value has "changed"
and the onchange themself could cause error when triggered at the wrong
time (eg. inside a list view with required fields).

With this changeset, the onchange is averted when the value was false
and is now `<p><br></p>`.

opw-1906581
closes #31078

Revert commit 296c5a21
which was half-right: the accounting logic is correct but it overlooked
that it broke the reconciliation of cash returns
i.e. the client gives more money, and you return the change

Given that this latter use case may occur more frequently we focus on that
while we break freight returns
i.e. the client returns a product, and you give the money back

It is not possible to support both use cases because
ultimately we don't know from which order an account.move.line comes

the related PR #23356 should support both use cases
but adds a field on account.move.line

OPW 1925607

closes odoo/odoo#31037

This commits adds a message to the module import wizard to make it more
clear what kind of modules can be imported through the front end.

project : RD feedback
task : [base_import_module] what it is not for.
opw-1939967

closes odoo/odoo#31057

Calling `search` on `product.product` without specifying an order
will sort the products by name.

As the product name is a translatable field,
it requires to make a join on the translation table to sort
the product by their translated name.

This join is costly, and in this case it was completely
irelevant to do it, as the goal was simply to compute
a domain with only a list of product ids, for which
the order simply did not matter.

By forcing the order on the id,
we avoid the sort on the product name,
and therefore the join on the translation.
The performance is therefore improved.

opw-1930010

closes odoo/odoo#31066

Force the location and destination location's company to match with the
picking and picking type company. This is to prevent users to move
products between companies without using a transit location, since stock
valuation is not supported.

The record rule `stock_location_comp_rule` gives access to children
companies. The domain added in the view is more restrictive, and allows,
for a company A, transfers from locations:
Company A -> Company A
Company A -> No Company
No Company -> Company A

opw-1893276

closes odoo/odoo#30952

closes odoo/odoo#30978

When dropping a snippet into a page, it is dropped in the drop-zone
which is the nearest of the user cursor. When moving a snippet, that
condition did not apply and the user was required to put the cursor at
the exact location of the drop-zone.

Also, for both drag and drop features, the drop zones which appeared
were not displayed correctly for full width columns, which made dropping
sometimes impossible when multiple col-*-12 were below each other.

task-1937758

closes odoo/odoo#30899

If fleet.vehicle_state_active is not found in the system then the method
will raise an error, hence it won't allow creating any fleet.vehicle

closes odoo/odoo#30925

- Create a product and set a contact as the vendor (for instance, Arthur
  Gomez from Asustek in the runbot)
- Set a specific name and code for the supplier
- Create a RFQ for this vendor (Arthur Gomez - the contact person)
- Add the product, confirm the RFQ

On the product, the company (Asustek) is automatically added as vendor,
but there is no vendor name and code.

opw-1929745

closes odoo/odoo#30891

- Activate:
  'Track lots or serial numbers'
  'Manage several Warehouses, each one composed by several stock locations'
  'Advanced routing of products using rules'
- In the main warehouse, activate Pick + Ship
- In Stock Locations, create 'WH/Stock/Shelf 3' and 'WH/Stock/Shelf 4'
  (1 and 2 already exist, use the same config)
- Create a new product 'Foo', activate Tracking By Lots
- On Foo, use 4 times the "Update Qty on Hand" (order is important):
  Add 1 on Shelf 2, create a lot
  Add 1 on Shelf 1, use the same lot
  Add 3 on Shelf 4, use the same lot
  Add 1 on Shelf 3, use the same lot
- Create a SO, set a partner
- Ensure that YourCompany is used as warehouse
- Add several SO lines (order is important)
  a line with 1 product Foo
  a second line with 1 product Foo
  a third line with 4 products Foo
- Confirm the SO, you now have 2 deliveries, 1 Pick, 1 Out
- Open the Pick, all moves should be available, you should have:
  4 operations:
    Shelf 2, quantity 1
    Shelf 4, quantity 3
    Shelf 1, quantity 1
    Shelf 3, quantity 1
  3 moves:
    A, quantity 1
    B, quantity 1
    C, quantity 4
- On each operation, select the lot created before and set the quantity
  to be fully done
- Validate the Pick

The moves end up like this:
- Move A with qty 1: is done and linked with a quant of 1
- Move B with qty 1: is done and linked with no quant
- Move C with qty 4: is done and linked with a quant of 1, a quant of 3,
  a quant of 1 (sum is 5)

In the Out picking, the move linked with the source move (B) with no
quant stays in "Waiting another move" even if the source move is done.
This outgoing move will never be available.

In the method `recompute_remaining_qty`, we loop on operations, and
match them wih the moves. However, the operation with the largest
quantity (Shelf 4, quantity 3) is processed before the move with the
highest quantity (C, quantity 4). Therefore, when we later loop on move
C, `qty_assign_cmp` is larger than zero, which sets `need_rereserve` and
ultimately triggers `rereserve_quants` in `do_transfer`.

A first part of the fix is to check for the location of the quants when
matching moves and operations. This fixes the original issue, but
inconsistencies can still arise since a quant which is taken partially.
therefore, we make sure to never take more than the quantity on the
link.

opw-1932624f

closes odoo/odoo#30857

- Set a cost of 12.34 for product P
- Create manually a new analytic entry
- Choose product P
- Set desired quantity

The analytic amount is set to 12.00.

This is because `move_id` is empty, therefore `currency_id` is empty as
well and `decimal_places` is zero

opw-1924184

closes odoo/odoo#30869

Before this commit, the customer is allowed to change picking type after the
stock.picking record is moved from draft.
But it doesn't make the changes in the stock moves and operations as the
procurements are already created for initial demand.

To avoid confusing the user, it can now only be modified in draft state.

Authored by SodexisTeam

opw 1848252
opw-1934814

closes odoo/odoo#30865

- Create a product P with:
  Costing Method       Average Price
  Inventory Valuation  Perpetual (automated)
- Create a component C with, costing 10.
- Create a BOM for P:
  1 Unit of C
- Create a MO for P, validate
  => a journal entry of 10 is created
- Modify the BOM for P:
  2 Units of C
- Create a MO for P, validate
  => a journal entry of 15 is created

The journal entry should be 20.

opw-1928342

closes odoo/odoo#30766

closes odoo/odoo#30768

Before that, having a payment with amount_residual=0, but amount_residual_currency!=0 did not display it.

Also, 'outstanding credits/debits' label was displayed in case amount_residual was != 0 with an amount_currency=0 (and of course, a currency_id value was set on the aml). This could for example happen in case of partial reconciliation, were the amount_residual field is used to keep track of what will have to be written in the exchange rate difference entry when the reconciliation becomes full.

closes odoo/odoo#30362

back port of commit 9820191d33f773ae21ca405da0e1226b6657ef5b
(made for v11)

project : Performance Issues
task : Geostaff : Success Pack 5 (100h) (opw-1912303)

closes odoo/odoo#29689

back port of commit 961a171341dabf428d5e86753b520481fd194558
(made for v11)

project : Performance Issues
task : Geostaff : Success Pack 5 (100h) (opw-1912303)

This commit simplifies the code and improves the performance
of _compute_sale_order_count.

execution time from O(n^2) to pretty close to O(n)

Project : Performance Issues
Task : Geostaff : Success Pack 5 (100h)  (opw-1912303)

With https://github.com/odoo/odoo/commit/ac8b0fcfc5299b5ea62543b8382cb419fed4868e,
the 'country_events' class was renamed to 'oe_country_events'. This was
done correctly for JS animations and snippets but not for the 'Country
Events' option in the customize menu. This made the option useless.

This commit solves the problem by supporting the two classes (as it
is a stable fix).

closes odoo/odoo#30662

In a pos session:
OFFLINE
make an order with invoicing , try to validate
    The order stays there because it needs to be validated by the server
make another non invoiced order, validate

ONLINE
make another order
    At validation, all orders will be pushed to the server

Before this commit, when trying to validate the invoiced order
the report download couldn't find the order id, and crashed
This was because the order in question was already pushed
but treated as a non invoiced order

After this commit, an "warning" message is displayed to the customer
saying he/she has to print the invoice from the backend.
In most cases it is enough and acceptable, since a customer would actually leave the premises
and come back later for the invoice
It is also safer in terms of data consistency to keep pushing all orders once the connection is back

OPW 1918044

closes odoo/odoo#30485

Before this commit, the web client had a naive strategy to handle lost
connections: it tried to poll the server every 2 seconds until a rpc
succeeds.

This works quite well from the perspective of the user, but may be a problem
from the perspective of the server.  If a server is down for a longish period,
then each users active tabs will then perform a request every 2 seconds. This
means that the server will be progressively hammered by many requests, which
will clutter the logs, and make it more difficult to gracefully recover.

With this commit, we simply exponentially increase the delay each time, and add
a little jitter to give a better distribution.

Cherry-pick of 4a3f04bc

closes odoo/odoo#30136

closes odoo/odoo#30596

Have a tax that has a different account for refunds
make an invoice and its refund

Before this commit, the refund's tax is still in the old account

After this commit, the refund's tax is in the account for refund defined on the tax

OPW 1907950

closes odoo/odoo#30325

In case the discount product is misconfigured and therefore not loaded
by the POS, a traceback appears when applying a discount.

Add a comprehensive error message instead.

Closes #30574
opw-817527

closes odoo/odoo#30582

Task #1930691

Purpose
=======

If the download security is set to 'Authenticated users', the route should prevent public users
from downloading the slides.

closes #30281

closes odoo/odoo#30399

Fixes odoo/odoo#30483

closes odoo/odoo#30488

Before this commit, the menu to go into the backend from the website was
not possible to open on iOS without opening the right menu first. This
was because position: fixed is not able to counter overflow: hidden in
iOS. This is the fix for stable versions, the proper solution will be
done in master.

Closes https://github.com/odoo/odoo/issues/29390
task-1923151

closes odoo/odoo#30507

Previous to this commit, if one were to create an ir.model.field with a
poorly constructed domain (read: SyntaxError), the server would properly
send an error message stating that an Error occurred, however this would
be too late as the registry with the bad code would have already been
reloaded, this meant that the registry would be left in an unstable
state (read: crashed).

With this commit, a constraint on the domain is added so that we confirm
that the code in the domain field is properly constructed, thus no need
to reload the registry and therefore no crash.

closes odoo/odoo#30157

For editing many2one fields (and partially many2many) most widget show
an autocompleting list of targeted records.

They thus have `autocomplete="off"` to prevent browser completion.

But chromium has an history of breaking `autocomplete="off"`, see:

- https://caniuse.com/#search=autocomplete
- https://crbug.com/468153
- https://crbug.com/587466
- https://crbug.com/914451
- https://crbug.com/923895

It seems that since chromium 71, the heuristic to ignore
`autocomplete="off"` has become more aggressive and for example if there
is at least 3 fields like an address in a page, chromium will ignore
`autocomplete="off"` for the fields like an address.

So for example the eidting the many2One field with placeholder "Country"
in a contact page now has a browser autocomplete menu that is:

- hidding the many2one autocomplete
- going to save empty country it appeared visually filled if the
  autocomplete result was selected.

With this changeset, the placeholder in the many2one instance is
interspersed with U+FEFF charcters (ZERO WIDTH NO-BREAK SPACE) so the
browser does enable the autocomplete feature by force.

This should thus remove the issue (until it is fixed by chromium) in the
case of field named "Country" or matching other regexes in this file:

https://github.com/chromium/chromium/blob/cdb1b2073f12/components/autofill/core/common/autofill_regex_constants.cc

U+FEFF has been chosen instead of more recommended characters because
other have been shown erroneous for printing in some windows
configuration (see cb2a3afa).

10.0 version of #30439
opw-1930588
closes #30439
closes #30449

closes odoo/odoo#30455

Some views have the primary mode while having an inherit_id view
In such views, if the user wants to change the inherit_id,
the mode must remain primary.

The use case behind this is a user who want to change
the inherit_id view of the view
product.product.form (product.product_normal_form_view)
to another view.
This view is in primary mode while having an inherit_id
(product.product_template_form_view).
In such a case, the primary mode must remain,
otherwise the view will no longer be opened by default
when opening a product.
Indeed, when searching the default form view of a model,
it only searches for primary mode views for this model.

The `all` is there because this is an `api.multi` method.
We could consider adding a `self.ensure_one`,
but it breaks the API if someones calls this method with multiple records.
This is likely to happen, as this method is used
in `write` which is likely to be called with multiple records.

In my opinion, in master, this should be replaced by an
onchange so the user can see the change of mode
when he adds or remove an inherit_id for a view.

opw-1916324

closes odoo/odoo#30241

This is essentially a backport of module l10n_be_intrastat_2019 made for
Enterprise v12 + the refactoring needed on the original v10 module to
allow the changes to apply where needed.

Was requested by opw-1887019

closes odoo/odoo#30400