Before this commit, a pricelist discount based on the product qty could
be created and the user may believe that it will work also for event
tickets.

Now: when configuring a pricelist discount based on the product qty a
warning message is show to alert that this kind of discount don't work
in event tickets.

opw-1940368

closes odoo/odoo#31459

Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>

Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.

Before this commit, when you change the product, to another product that
is also an event, the event, the ticket and the price stayed the ones of
the first product.

Now, the event, the ticket and the price are updated when the product is
modified.

opw-1940368

Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).

However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).

Fix by using proper version parsing and comparing the result of that.

See also: odoo/odoo#28116

closes odoo/odoo#31553

Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>

The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).

But the feature was broken at a point, and has been solved in 11.0 with
7c7b0992.

This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.

This changeset is only for 10.0 up to saas-15 to implement the fix
differently.

opw-1945417
closes #31475

Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.

Before this commit, when you change the tickets qty in the SO the price
change from 600 to 1500.

Now, the unit price stays the one of the ticket.

opw-1940368

Remove the corporate CLA (only cantecim has contributed in the past) and signs
an individual CLA file instead

closes odoo/odoo#31495

Part of https://github.com/odoo/odoo/pull/31440
opw-1929133

closes odoo/odoo#31440

Commit https://github.com/odoo/odoo/commit/c2b8d2a3017256e4ea60a3710bdaab6d1f693d81
made the mistake of considering each dropdown-menu individually while
all are considered to be the same when enabling a class. From saas-11.x,
commit https://github.com/odoo/odoo/commit/8ca92330b367d54fddf1c02089ee9d0bc3edbfdc
will group by dropdown menu but that will be another fix to make.

Part of https://github.com/odoo/odoo/pull/31440
opw-1929133

Include commit 572d628 again, as it was lost with a forward port.

closes odoo/odoo#31479

Since 934c0016, fasly domains are
correctly OR'ed.
Models without group binded rules were then wrongly reduced to an
`AND FALSE` condition.

In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.

This introduced an issue on the column group by:

- before reload, if we set manually a column group by (+ icon in the
  header) it would be saved and not lost (unless a context or filter
  in the search view override it)

- after reload, the following manually set column group by are not saved
  anymore on subsequent reload (the column group by at the first reload
  are set back)

This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.

The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).

Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").

Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.

opw-1941095
closes #31407

It does not make sense to be able to write on mail.activity.type using
the related fields defined on mail.activity.

closes odoo/odoo#31469

[FIX] models: do not erase master version

For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.

Before this patch:

>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>"  # lost English version

After this patch:

>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>"  # write had no effect
>>> record.arch
"<h1>Title</h1>"

When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.

To update translations, the supported way is to go to the list of translations
and update them there.

Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True

If a field is callable, it should also be ignored, the same way than
translate=True fields

opw-1887162

closes odoo/odoo#31451

This reverts commit 5f5bb5e2.

Not really a fix as this was never implemented, to be done in master...

Closes #31466

As signed at opw-1944366

closes odoo/odoo#31413

Before this commit:
        -> Debug mode
        -> Settings
        -> Database structure
        -> Fields
        -> Any selection field
=> The field `selection` of the ir.model.fields form view does not
display the selection options of the field being viewed, this is because
the selection field is not registered at `_reflect_field_params` of
`ir.model.fields`.

After this commit:

The field is properly registered; for Selection fields with static
options, these are shown as-is, for fields with a lambda function as
options, the string 'function' is displayed, and for fields using a
function name as a string, the same string will be displayed.

Fixes #28360

closes odoo/odoo#31207

Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.

closes odoo/odoo#30545

On some devices and chromium with printing option "Background graphics",
a printed receipt on the point of sale could have a black bottom below
the receipt content.

This is caused by the point of sale black background and happen rarely
because most frequently browser printing remove backgrounds.

opw-1940434
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
closes #31472

Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.

The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().

See tests for a clearer view of the use cases.

Fixes #30113, #26540

closes odoo/odoo#31202

The admin can decide to publish/unpublish messages in the comments
of a product from the website. The button is also shown for notes
even if they are never published.

opw-1935337

closes odoo/odoo#31420

When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.

At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.

We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)

opw-1925547

closes odoo/odoo#30154

closes odoo/odoo#31373

- Switch to French language
- Go to Inventory > Inventory Adjustment
- Launch an adjustment

The field 'Real Quantity' doesn't follow the float formatting.

This is because the widget is set as `field_float_scannable`, which is
not recognized by the formatting function.

Since the widget descriptor has priority over the type descriptor, we
must explicitly take this widget into account, on top of adding the
`format_value` method.

opw-1940884

closes odoo/odoo#31366

Apply e1767490 to SO count in order to
take into account all children, and not only direct children.

opw-1941335

closes odoo/odoo#31329

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

Partially revert f221936f (#30952)

closes odoo/odoo#31121

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

In some case, when the user enter by mistake an account move line
 with an amount of 0,the reverse operation does not works properly.
The issue happenned during the reverse operation because it tries to
reconcile a 0 account move line with no matches (credit or debit).

See opw-1931961

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