Have a model A with a o2m to B.
In the list have a field  B > m2o > C

Also have a sequence field (widget handle) on B

Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty

Resequence those two B lines with the handle

Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get

After this commit, there is no traceback, the name_get is avoided when no data is to be fetched

OPW 1853088
closes #24988

Introduced at 01e35141
.code was on the previous urllib2 version but on requests, the code is accessed
through status_code

opw-1855471

To compute the week number, the fullcalendar.js library uses the locale.
It depends on the day on which the week starts (usually Sunday in the Americas,
Monday in Europe), as well as which week is considered the first of the year.
In commit:
https://github.com/odoo/odoo/commit/717b472ef9ad6d2998cbefb4aafe2d1199e6235d
the starting day was explicitly added, however it was computed as isoWeekday.
The ISO first day of the week is always on Monday.
It resulted that if the locale used Sunday as first day of the week, the
calendar would consider it to be of the previous week, and thus displayed
(weeknumber - 1).
The fix does the same thing as was done in v10, taking the locale into account:
https://github.com/odoo/odoo/commit/df124080b624a8bdb86fec352fe690725ed36bac

opw 1853745

Let's consider a Sales user U with no access to Purhcase

Steps to reproduce the bug:
- Create a SO with one line with the drop shipping route
- Validate the SO

Bug:

 A access error was raised because the user has no access right on
Purchase.

opw:1851301

Before this commit:

* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other

If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.

This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.

To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.

Fixes #24958

When archiving a product template P with one SO linked to it,

- Going to P by Accounting > Configuration > Products > P shows 1 sale
in smart button

- Going to P by Accounting > Sellable products > P showed 0 sale in smart
button

Now it shows 1 sale in these two cases.

opw:1852948

Backporting bed33e1c and 472c5a4f from v10.0

OPW 1853150
closes #25043

Make one Payment
Reverse the entry of this payment.

Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports

After this commit, the four lines are reconciled two by two, even in the liquidity
account

OPW 1816641
closes #25026

- Create a picking, set as 'Carrier': 'Free delivery charges'
- Enter a 'Tracking Reference'
- Validate the picking

The tracking reference is removed.

opw-1849279

If the `web.base.url` contains a trailing `/`, the replacement of the
`/unsubscribe_from_list` link won't work since the string to replace
will be `my_url//unsubscribe_from_list` instead of
`my_url/unsubscribe_from_list`.

Fixes #24731
opw-1848572

In the portal module,
the `index` method from the `web` module controllers
is overriden to redirect `/`
to the portal `/my` for the portal users,
instead of the regular backend `/web`.

However, when `website` is installed,
this behavior should not happen,
as you would like the signed in portal users to
be able to see the website homepage,
and not to be redirected to `my` when
they try to access `/` root path of the website.

Because the override in the website module was done on the
`index` method coming from the `web` module instead of the `portal`,
according in which way the Python module were loaded,
it sometimes redirected to `/my`, sometimes it correctly
displayed the homepage. This is because the modules are not
loaded in a determinist order.

To summarize, on runbot, if you logged as portal/portal,
one time on two you were redirected to `/my`, and the other
time you saw the homepage correctly.

As `website` depends on `portal`,
we have the possibility to override the `index` method
of `portal` instead of the one of `web`,
to force the determinist order,
and therefore the determinist behavior of the homepage for
portal users.

The original issue was fixed at 2f5e44d4

This reverts commit 0b1b860d.

opw-1854613

When installing the `account` module, some of its master data is
installed as `l10n_generic_coa` data.

During the uninstallation of `account`, `l10n_generic_coa` is
uninstalled first since its a dependency of `account`, but some of its
master data cannot be uninstalled yet as its still being referenced in
some `account` et al tables.

When `account` is being reinstalled, the datas will be updated instead
of created since they were left intact in the database, this proves
troublesome as the code YAML interpreter adds some context variables
when creating records but not when updating records, these context
variables are necessary in order to trigger some onchanges and defaults
for fields that are required, since this does not happen we get a `NOT
NULL CONSTRAINT` error when re-installing the `account` module.

This patch solves this issue by adding an uninstall_hook that will
delete all ir_model_data that belongs to the module `l10n_generic_coa`
upon its uninstallation.

Fixes #25005

Avoid "expected singleton" when writing on multiple pos_config

closes #24953

- Create the following BOM for Product A:
  Comp 1: 1 Unit(s)
  Comp 2: 5 Unit(s)
- Update on-hand quantity:
  Comp 1: 10 Unit(s)
  Comp 2: 30 Unit(s)
- Create a MO for 10 Unit(s) of A
- Check the Quantity on report 'Stock Level Forecast':
  Comp 1:   0 Unit(s)
  Comp 2: -20 Unit(s)
- 'Check Availability' on the MO
- Check the Quantity on report 'Stock Level Forecast':
  Comp 1:  0 Unit(s)
  Comp 2: 30 Unit(s)

The `partially_available` state has been added with Inventory
refactoring in v11, and needs to be taken into account.

opw-1849556

In 11.0, this change e9454e79 solved the use case of:

- opening the registration of a ticket
- discard

=> the page must be reloaded to register a ticket

A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.

This commit backports e9454e79 and solves the 0 ticket registration.

10.0 version of 9.0's #24966
opw-1851622
closes #24991

Before this commit, some values of res.config.settings were saved
(e.g case of website settings were some fields are related)

After this commit, they are not saved

OPW 1853230
closes #24972
closes #25028

- Create a BOM for Product A, using Component B
  1 Unit of a is built with 1 Unit of B
- Update on hand quantity for B to 3.0
- Create a MO for 5 Units of A
- Update the quantity to produce to 3.0

The button 'Check Availability' never disappears.

The core of the problem is that the move remains "Partially Available".
Indeed, if there is no product available (`available_quantity <= 0`),
the stock move is skipped and its availability status is not updated.

We slightly change the logic by first checking if we need any quantity.
If not, the move can be considered as assigned.

opw-1850499

The website_event_questions override EventRegistrationForm's method
on_click and expects the returns is a deferred.

This commit provides a deferred in all instances avoiding an error.

Also what was done in e9454e79 and enables back the Register Now
button if no ticket was selected.

opw-1850527

In 11.0, this change e9454e79 solved the use case of:

- opening the registration of a ticket
- discard

=> the page must be reloaded to register a ticket

A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.

This commit backports e9454e79 and solves the 0 ticket registration.
Also if website_event_questions was installed there was an error
preventing an error message to be displayed.

saas-15 version of 9.0's #24966
opw-1851622
closes #24967

formataddr (from the email python library) writes email_from as '"name" <email>'
in the email_from field of the mail.compose.message record.
When the mail is rendered, onchange_template_id is triggered.
This then overwrites the values of email_from among other fields.
What happens is that it uses the email_from field from the template to render
the email_from, bypassing what was put by formataddr before.
What happens in some cases is that it is rendered as 'name <email>'
(note the quotes have been stripped away).
If name contains arbitrary symbols, e.g. name = 'pépé [company] <pdg>, ohlala',
then getaddresses which is supposed to parse the (name, email) pairs gets thrown
off (in particular, <pdg> will be interpreted as an email address, and many
other problems with the various special symbols).
It then gives these wrong elements as email addresses, which will usually crash
when getting non-ascii symbols (i.e. these strings don't respect the relevant
RFC for email addresses).

Closes:
https://github.com/odoo/odoo/issues/23502
https://github.com/odoo/odoo/pull/2311823118

opw 815202
opw 1824243

Before this commit:

* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other

If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.

This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.

To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.

Fixes #24958

In 11.0, this change e9454e79 solved the use case of:

- opening the registration of a ticket
- discard

=> the page must be reloaded to register a ticket

A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.

This commit backports e9454e79 and solves the 0 ticket registration.

opw-1851622
closes #24966

When the carousel is activated, the following will load all variant ids
in the cache (cf. `_in_cache_without`):
```
<t t-set="variant_img" t-value="any(product.mapped('product_variant_ids.image_variant'))"/>
```

When accessing the `image` field at:
```
<div t-if="variant_img" class="..." itemprop="image" t-field="product.product_variant_id.image" t-options="..."/>
```
All variants in cache will have their image resized by the method
`_compute_images` on `product.product`. In case of a product with
hundreds of variants with images, this will take a major amount of time.

If we replace by `product[:1]`, the system uses another cache, and
doesn't fetch the image of all variants.

opw-1844783

Commit https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf changed the dependancies of l10n_fr_certification which is not acceptable on stable. Instead, the method to check is now moved in account module (to avoid duplicated) and it is called by l10n_fr_certification and account_lock module.

Module account_lock has been introduced by:
https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf

A new constrains appears on the lock dates: their must not be set
after the last day of the previous month.
Then, it breaks the test on closed period that set the lock date 'yesterday'.

Was task: https://www.odoo.com/web#id=38178&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #22094

Commit 5439e72a introduces the automatic creation of a journal
for a payment provider. However, the journal created doesn't have a
default payment method, to avoid showing it in the backend.

In the case of the eCommerce with automatic invoice creation, this
set-up returns a 500 error after an online payment. Solving the problem
is not obvious for the end-user.

The error comes from the fact that the 'Manual' payment method is not
available on the journal. We can remove this check.

opw-1853011

Have a mrp.production that you cancel, and delete the finished products lines

Before this commit, the computation of the sale_name crashed because we did
an index selection on an empty recordset

After this commit, there is no crash

opw 1851217
closes #24923

(1) Before this commit, the input barcode was removed from the dom
after each scan but now we want to keep it focused to avoid to
automatically open the virtual keyboard in mobile.
This behavior will be useful in enterprise only.
Another commit will follow in this repository.

As the input is not removed anymore, we had to disable autocomplete
to hide previous entries as suggestions.

(2) We also add z-index property to avoid to click on the hidden input
located in the middle of the page.

Have a XMLReceipt with the line:
<barcode encoding="CODE39">123456789</barcode>

Print the receipt.

Before this commit, jibbrish characters were printed and also kinda 'broke'
the spacing between commands
e.g. If you add an EAN13 barcode below the code39 it would have failed to print correctly too

After this commit, everything prints correctly

OPW 1849284
ref: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=128
closes #24965

[FIX] base: set vat number field as readonly on children partners; as it is a commercial field, it should always have the value defined on the parent partner.

(this is a manual forward port from https://github.com/odoo/odoo/commit/98b1fffd4e99cc8ad2862c56fbd727979c38c48b , as a new view is defined in 11.0, needing this correction too)