## Pull Request HOOT (PRHOOT) - part 25

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767
Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895
Part 21: https://github.com/odoo/odoo/pull/174337
Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721
Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728
Part 24: https://github.com/odoo/odoo/pull/181971

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Description of the issue/feature this PR addresses:
In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed:

>  Error: Invalid ids list: 
>     Error: Invalid ids list: 
>         at validatePrimitiveList (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28515:15) (/web/static/src/core/orm_service.js:73)
>         at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28596:9) (/web/static/src/core/orm_service.js:154)
>         at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:39288:41) (/web/static/src/core/utils/hooks.js:101)
>         at Object.callback (https://www.stesi.consulting/web/assets/debug/web_editor.backend_assets_wysiwyg.js:25785:51) (/web_editor/static/src/js/wysiwyg/wysiwyg.js:2463)
>         at Powerbox._pickCommand (https://www.stesi.consulting/web/assets/debug/web_editor.backend_assets_wysiwyg.js:14811:27) (/web_editor/static/src/js/editor/odoo-editor/src/powerbox/Powerbox.js:232)  

### Current behavior before PR:
The error above appears because the web_editor get the session_user_id from session_info that is set by auth_totp or in a frontend session. 
Using uid it works on both 

### Desired behavior after PR is merged:
No error should appear



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#179378

Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear.

Steps to reproduce:
-------------------
* Use an Ipad (or simulate one)
* Go to the **Point of sale** App
* Select **Configuration** > **Settings**
* Enable QR code on receipt
* Open shop session
* Make an order and pay it
* Print the receipt
> Observation: QR code does not appear, big white space where it should be

* Print it again
> Observation: QR code is printed

Why the fix:
------------
```js
function createImage(url) {
    return new Promise((resolve, reject) => {
        const img = new Image();
        img.onload = () => resolve(img);
        img.decode = () => resolve(img);
        img.onerror = reject;
        img.crossOrigin = "anonymous";
        img.decoding = "async";
        img.src = url;
    });
}
```

In this piece of code, `img.decode = () => resolve(img);` is supposed to ensure that the image is fully processed but is misused. Decode is not a setter, it's a method that returns a promise when the image is fully decoded. While this code wait for the image to load it does not wait for it to be fully ready (processed).

`img.decode()` ensures that the image has been fully decoded before continuing.

We go one step further with `requestAnimationFrame`. This defers the execution and will ensure that the resolved image is rendered in the next frame. It's more important in devices like Ipad because the broswers tend to handle image operations differently, thus creating rendering and timing issues.

With this fix, we now wait longer to make sure that the image is not only loaded but also fully processed and ready to be shown.

opw-4144049

Forward-Port-Of: odoo/odoo#182803

## Description
After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow.
The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results.
This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper timezone and localize the date.

## Benchmark

| len(results_dict) | Before | After | Speedup |
|-------------------|--------|-------|---------|
| Timings (10k)     | 250ms  | 50ms  | 5x      |
| Timings (50k)     | 1.2s   | 300ms | 4x      |
| Timings (100k)    | 2.7s   | 820ms | 3.3x    |
| Timings (250k)    | 6.7s   | 1.7s  | 3.9x    |
| Timings (~600k)   | 13s    | 4s    | 3.25x   |

## Reference
opw-4235252

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#183342

To reproduce the issue:
(Need website_sale)
1. Set up a website shop for ES company
   - With demo payment method
2. In Settings:
   - Website > Automatic Invoice: enabled
3. With a portal user, add a product to the cart
4. Open the cart
5. Pay with Demo

Error: The client is redirected to a page "Internal server error:
The partner needs a set tax identification number or VAT number"

When post-processing the payment, and because of step 2, it leads to
https://github.com/odoo/odoo/blob/20365bcab548c4a2d93194c8c2b8b2577d14d3ce/addons/l10n_es_edi_facturae/wizard/account_move_send.py#L86-L88
Where we will generate the data for the Facturae XML. There, we
check few things, like the vat number of the partner:
https://github.com/odoo/odoo/blob/e157cb2d8640fac1365beb135763cb25cff554f5/addons/l10n_es_edi_facturae/models/account_move.py#L312-L313
And since the portal user does not have any vat number, the error is
raised.

The Facturae feature should only be enabled for B2B flows

OPW-4121724

Forward-Port-Of: odoo/odoo#181653

Steps to reproduce the error
1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll
2.create a leave with existing leave type from l10n_be_hr_payroll module 
3.upgrade db to 16.0 the below mentioned traceback will raise

traceback
```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root
    f(rec)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record
    record = model._load_records([data], self.mode == 'update')
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4393, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4324, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3806, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1365, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/16.0/addons/hr_holidays/models/hr_leave_type.py", line 188, in check_allocation_requirement_edit_validity
    raise UserError(_("The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead."))
odoo.exceptions.UserError: The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1310, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 484, in load_modules
    processed_modules += load_marked_modules(cr, graph,
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 372, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 231, in load_module_graph
    load_data(cr, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 71, in load_data
    tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 763, in convert_file
    convert_xml_import(cr, module, fp, idref, mode, noupdate)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 829, in convert_xml_import
    obj.parse(doc.getroot())
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 749, in parse
    self._tag_root(de)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 711, in _tag_root
    raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/16.0/l10n_be_hr_payroll/data/hr_leave_type_data.xml:14, somewhere inside
<record id="holiday_type_maternity" model="hr.leave.type">
        <field name="name">Maternity Time Off</field>
        <field name="requires_allocation">no</field>
        <field name="leave_validation_type">no_validation</field>
        <field name="request_unit">half_day</field>
        <field name="color_name">lavender</field>
        <field name="leave_notif_subtype_id" ref="hr_holidays.mt_leave"/>
        <field name="work_entry_type_id" ref="work_entry_type_maternity"/>
        <field name="icon_id" ref="hr_holidays.icon_11"/>
        <field name="company_id" eval="False"/>
    </record>
```

why this traceback is raised because while loading ``l10n_be_hr_payroll`` moduel this data file will load during that if record is noupdate false then it will go for write call so in that requires_allocation will also go for write call even the value is same. So, the newly introduced [``constraints``](https://github.com/odoo/odoo/commit/33da34b842f2fe700efaf55915d4cb9828e139d7) will trigger and check if any record
of leave is present with the that leavetype constraint will trigger .For fixing this issue pop the value of ``requires_allocation`` if the values are same otherwise record is modified by user.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182533

## Description of the issue/feature this PR addresses:

Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable.

In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password.

Including the optional db_server_status arg will allow integrating the postgresql server state without breaking any eventual existing overrides.

## Current behavior before PR:

When the postgresql database is not up / not reachable the route is returning a 200 code.

## Desired behavior after PR is merged:

When the postgresql database is not up / not reachable the route is returning a 500 code. As we are in stable, an optional argument has been added to the route in order not to break any potential existing overrides.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182840
Forward-Port-Of: odoo/odoo#182537

Commit 1
========

Steps to reproduce the issue:
- add comment to a Facebook/youtube post.
- keeping the `Comments` dialog box open, try replying the same comment.
- we get a traceback.

Reason:
- due to the missing comments data structure, we get an error when trying to add the new comment.
- LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311

Fix:
- since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists.

Commit 2
========

[FIX] social: fix various issues
1. social_instagram:

ISSUES:
- create a post on the instagram platform with commenting turned off.
- try commenting on it from Odoo. We get a traceback.
- also, if we delete the post from the platform and then try to comment from Odoo,
  we get a traceback.

REASON:
- there is no existing implementation to check if commenting is enabled/disabled
  on the post.

FIX:
- we now check if commenting is enabled or not while trying to add comment on the post

TECHNICAL NOTE:
- the correct way to check if commenting on a post is enabled or not is to request
  a field named `is_comment_enabled`.
- more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media
- but to save us from making an extra request, we simply catch the error received to
  when trying to add a comment.

================================================================================

2. social_linkedin

ISSUE:
- delete an existing post from the linkedIn platform.
- now try commenting on it from Odoo. We get a traceback.

REASON:
- The response received from the request to fetch the comments is not validated.

FIX:
- validating the response before further execution.

Task-3759530

Forward-Port-Of: odoo/enterprise#71750
Forward-Port-Of: odoo/enterprise#67079

### Steps to reproduce the issue:

1. Activate Mexican localization
2. Create multiple Invoices in USD with different amounts (add the Invoice Date)
3. Send and Print them for the CFDI
4. Register a grouped Payment in MXN for those invoices
5. Go to one of the Invoices and click on Update Payments
6. Go to the CFDI tab and, on the Payment line, click on Force CFDI
7. On the Payment line, you should now be able to Download an XML document
8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case

### Explanation:

When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions.

### Fix reasoning:

While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong.

opw-4090269

Forward-Port-Of: odoo/enterprise#71767
Forward-Port-Of: odoo/enterprise#70083

### Steps to reproduce:
- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create an associated repair order and add a line for an other product in the part tabs
- Go back to the return picking

#### > the product added to the repair was also added to the return picking

### Cause of the issue:

A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view.

### Fix:

Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context.

opw-4159779

Forward-Port-Of: odoo/enterprise#71704
Forward-Port-Of: odoo/enterprise#71337

**Steps to reproduce:**
- Install Accounting and l10n_cl_edi_boletas
- Switch to a Chilean company (e.g. CL Company)
- Create a branch company for it
- Create a product with a tax from "ILA" group
- Switch to the branch company
- Create an invoice with the created product
- Confirm it

**Issue:**
A traceback is raised while trying to fetch some tax groups:
- self.env.ref(f'account.{cid}_tax_group_ila')
- self.env.ref(f'account.{cid}_tax_group_retenciones') where {cid} is the id of the branch company.

**Cause:**
There is no tax group defined in the branch company. The taxes and the tax groups are defined in the parent company.

**Solution:**
Do not raise an error if the XMLID cannot be found and also check tax groups from parent companies as the taxes could come from them.
Use the "ref" method defined in "account.chart.template" model that is doing it.

opw-4227241


Related comminity PR: https://github.com/odoo/odoo/pull/182798

Forward-Port-Of: odoo/enterprise#71708
Forward-Port-Of: odoo/enterprise#71476

**Steps to reproduce:**
- Install Accounting and l10n_de_reports
- Switch to a German company
- Create a 19% included tax
- Create an invoice with the following line:
  * Product: [any]
  * Quantity: 1.00
  * Price: 19.95
  * Taxes: [the 19% included tax]
- Confirm the invoice
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv"

**Issue:**
The line for the created invoice has an amount of 19.94 instead of 19.95.

**Cause:**
As the tax is included, the balance on the line is computed and rounded. When the report is generated, "compute_all" is executed with the rounded balance to retrieve the total price with the taxes. Because the balance used in "compute_all" has been rounded and therefore is not exactly the same than the original computed value, there can be a 0.01 difference.

**Solution:**
Use directly "price_total" field when available.

opw-4191876

Forward-Port-Of: odoo/enterprise#71787
Forward-Port-Of: odoo/enterprise#70801

**Current behavior:**
Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders.

**Expected behavior:**
Transfer quantity should match sale order line quantity.

**Steps to reproduce:**
1. Enable 2-step delivery in the warehouse

2. In the 2-step delivery route, change the src location of the pick action (pull rule) to be a sub-location of WH/STOCK

3. Enable rental transfers in settings

4. Create a new rental order, add a product, confirm the order

5. Add some quantity to the order line and save

6. Look at the generated out-going picking's moves -> the demand is wrong

**Cause of the issue:**
The original move created when confirming the order, before editing the order line quantity, is not found when the additional move is created for the modified quantity.

Existing outgoing moves are expected to have a location_id (source location) of WH/STOCK (warehouse.lot_stock_id), ours will have a location_id of some sub-location.

**Fix:**
Check all child locations of lot_stock (which includes lot_stock itself) when aggregating outgoing moves.

opw-4178446

Forward-Port-Of: odoo/enterprise#71559

Description of the issue this commit addresses:

Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals.

---

Steps to reproduce:

1. Install account
2. Create new Vendor Bill with a split payment term ("30% now, Balance 60 Days" for example) on today's date for Bill Date.
3. Go to the dashboard, click the <[X] To Pay> button.
4. the amount of moves in the view that is opened with the button is one above the value of "X" in the button.

This is due to using a split payment term that creates two installment for a single vendor bill hence counting one more aml than there are moves.

---

Desired behavior after this commit is merged:

The right amount of To Pay and Late moves is shown at all times.

---

Enterprise PR: https://github.com/odoo/enterprise/pull/70725
No task

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Description of the issue this commit addresses:

Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals.

---

Steps to reproduce:

1. Install account
2. Create new Vendor Bill with a split payment term ("30% now, Balance 60 Days" for example) on today's date for Bill Date.
3. Go to the dashboard, click the <[X] To Pay> button.
4. the amount of moves in the view that is opened with the button is one above the value of "X" in the button.

This is due to using a split payment term that creates two installment for a single vendor bill hence counting one more aml than there are moves.

---

Desired behavior after this commit is merged:

The right amount of To Pay and Late moves is shown at all times.

---

Note on the fix:

The fix for this issue is in the community PR of the bundle, the fix modifies a method which was overriden in enterprise and this PR addresses the override to match with the new version of the method.

---

Community PR: https://github.com/odoo/odoo/pull/181535
No task

Since [1], when using a website boxed layout, the Bootstrap $body-bg variable was used as the color of the *box* instead of the body itself. Indeed, it made sense as default Bootstrap components started to use that $body-bg value themselves, supposing those components would be placed in the body by default, and not a colored main box.

The color of the body itself was then forced to the user-chosen Odoo color, by setting the --body-bg CSS variable Bootstrap sets up and which at the time, was only used for that.

However, since [2], the new Bootstrap version started to use that CSS variable instead of the $body-bg SCSS variable to style components. Therefore, in boxed layout, this was broken: the components used the "color behind the box" instead of the "color of the box".

Commit [3] solved a specific consequence of this issue: the tables, in boxed layouts, would use the "color behind the box" (for instance, on the shop page) breaking the design. It fixed the issue by restoring the table transparent background color as wanted (not only in those boxed layouts). But other components that use var(--body-bg) would still be broken... (un)fortunately, it seems to not be the case as we force those variables ourselves to $body-bg instead of var(--body-bg) (which will be changed in master to follow Bootstrap conventions).

[1]: https://github.com/odoo/odoo/commit/977868f5e0f50937499c89efacadf1d30ed19b5d
[2]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935
[3]: https://github.com/odoo/odoo/commit/17592b131001647cc4c8028db8c1dacb05797c0b

Related to opw-4203976

Forward-Port-Of: odoo/odoo#183132

Recent changes and refactorings in the addresses management of the ecommerce checkout have restricted the ability of customers to use and update sibling/parent addresses in their own company.

Those changes have also increased the checks on addresses to make sure that the necessary information is available to ensure proper delivery and invoicing to the customer.

Nevertheless, some address, either from the past, or from other flows might still be incomplete, and be the default delivery/billing address of a given customer, despite belonging to siblings or to their parent company.

In those situations, the customer could be constantly requested to fill the incomplete address and be automatically redirected on the /shop/address page to fill the missing information, where he would face a Forbidden (403) error as they cannot update an address that doesn't belong to them.

This commit makes sure to consider a default address as complete if the current customer is unable to edit it.

opw-4202528

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182143

## Description
After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow.
The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results.
This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper timezone and localize the date.

## Benchmark

| len(results_dict) | Before | After | Speedup |
|-------------------|--------|-------|---------|
| Timings (10k)     | 250ms  | 50ms  | 5x      |
| Timings (50k)     | 1.2s   | 300ms | 4x      |
| Timings (100k)    | 2.7s   | 820ms | 3.3x    |
| Timings (250k)    | 6.7s   | 1.7s  | 3.9x    |
| Timings (~600k)   | 13s    | 4s    | 3.25x   |

## Reference
opw-4235252

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#183438
Forward-Port-Of: odoo/odoo#183342

## Description of the issue/feature this PR addresses:

Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable.

In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password.

Including the optional db_server_status arg will allow integrating the postgresql server state without breaking any eventual existing overrides.

## Current behavior before PR:

When the postgresql database is not up / not reachable the route is returning a 200 code.

## Desired behavior after PR is merged:

When the postgresql database is not up / not reachable the route is returning a 500 code. As we are in stable, an optional argument has been added to the route in order not to break any potential existing overrides.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182840
Forward-Port-Of: odoo/odoo#182537

Steps to reproduce the error
1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll
2.create a leave with existing leave type from l10n_be_hr_payroll module 
3.upgrade db to 16.0 the below mentioned traceback will raise

traceback
```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root
    f(rec)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record
    record = model._load_records([data], self.mode == 'update')
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4393, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4324, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3806, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1365, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/16.0/addons/hr_holidays/models/hr_leave_type.py", line 188, in check_allocation_requirement_edit_validity
    raise UserError(_("The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead."))
odoo.exceptions.UserError: The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1310, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 484, in load_modules
    processed_modules += load_marked_modules(cr, graph,
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 372, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 231, in load_module_graph
    load_data(cr, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 71, in load_data
    tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 763, in convert_file
    convert_xml_import(cr, module, fp, idref, mode, noupdate)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 829, in convert_xml_import
    obj.parse(doc.getroot())
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 749, in parse
    self._tag_root(de)
  File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 711, in _tag_root
    raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/16.0/l10n_be_hr_payroll/data/hr_leave_type_data.xml:14, somewhere inside
<record id="holiday_type_maternity" model="hr.leave.type">
        <field name="name">Maternity Time Off</field>
        <field name="requires_allocation">no</field>
        <field name="leave_validation_type">no_validation</field>
        <field name="request_unit">half_day</field>
        <field name="color_name">lavender</field>
        <field name="leave_notif_subtype_id" ref="hr_holidays.mt_leave"/>
        <field name="work_entry_type_id" ref="work_entry_type_maternity"/>
        <field name="icon_id" ref="hr_holidays.icon_11"/>
        <field name="company_id" eval="False"/>
    </record>
```

why this traceback is raised because while loading ``l10n_be_hr_payroll`` moduel this data file will load during that if record is noupdate false then it will go for write call so in that requires_allocation will also go for write call even the value is same. So, the newly introduced [``constraints``](https://github.com/odoo/odoo/commit/33da34b842f2fe700efaf55915d4cb9828e139d7) will trigger and check if any record
of leave is present with the that leavetype constraint will trigger .For fixing this issue pop the value of ``requires_allocation`` if the values are same otherwise record is modified by user.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182533

To reproduce the issue:
(Need website_sale)
1. Set up a website shop for ES company
   - With demo payment method
2. In Settings:
   - Website > Automatic Invoice: enabled
3. With a portal user, add a product to the cart
4. Open the cart
5. Pay with Demo

Error: The client is redirected to a page "Internal server error:
The partner needs a set tax identification number or VAT number"

When post-processing the payment, and because of step 2, it leads to
https://github.com/odoo/odoo/blob/20365bcab548c4a2d93194c8c2b8b2577d14d3ce/addons/l10n_es_edi_facturae/wizard/account_move_send.py#L86-L88
Where we will generate the data for the Facturae XML. There, we
check few things, like the vat number of the partner:
https://github.com/odoo/odoo/blob/e157cb2d8640fac1365beb135763cb25cff554f5/addons/l10n_es_edi_facturae/models/account_move.py#L312-L313
And since the portal user does not have any vat number, the error is
raised.

The Facturae feature should only be enabled for B2B flows

OPW-4121724

Forward-Port-Of: odoo/odoo#181653

Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear.

Steps to reproduce:
-------------------
* Use an Ipad (or simulate one)
* Go to the **Point of sale** App
* Select **Configuration** > **Settings**
* Enable QR code on receipt
* Open shop session
* Make an order and pay it
* Print the receipt
> Observation: QR code does not appear, big white space where it should be

* Print it again
> Observation: QR code is printed

Why the fix:
------------
```js
function createImage(url) {
    return new Promise((resolve, reject) => {
        const img = new Image();
        img.onload = () => resolve(img);
        img.decode = () => resolve(img);
        img.onerror = reject;
        img.crossOrigin = "anonymous";
        img.decoding = "async";
        img.src = url;
    });
}
```

In this piece of code, `img.decode = () => resolve(img);` is supposed to ensure that the image is fully processed but is misused. Decode is not a setter, it's a method that returns a promise when the image is fully decoded. While this code wait for the image to load it does not wait for it to be fully ready (processed).

`img.decode()` ensures that the image has been fully decoded before continuing.

We go one step further with `requestAnimationFrame`. This defers the execution and will ensure that the resolved image is rendered in the next frame. It's more important in devices like Ipad because the broswers tend to handle image operations differently, thus creating rendering and timing issues.

With this fix, we now wait longer to make sure that the image is not only loaded but also fully processed and ready to be shown.

opw-4144049

Forward-Port-Of: odoo/odoo#182803

Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:

``py
  File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
    thread._message_auto_subscribe(create_values, followers_existing_policy='update')
  File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
    res = self._message_auto_subscribe_followers(updated_values, def_ids)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
    if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
                                  ^^^^^^^^^^^^^^
  File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```

Forward-Port-Of: odoo/enterprise#71188

### Steps to reproduce:
- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create an associated repair order and add a line for an other product in the part tabs
- Go back to the return picking

#### > the product added to the repair was also added to the return picking

### Cause of the issue:

A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view.

### Fix:

Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context.

opw-4159779

Forward-Port-Of: odoo/enterprise#71704
Forward-Port-Of: odoo/enterprise#71337

Commit 1
========

Steps to reproduce the issue:
- add comment to a Facebook/youtube post.
- keeping the `Comments` dialog box open, try replying the same comment.
- we get a traceback.

Reason:
- due to the missing comments data structure, we get an error when trying to add the new comment.
- LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311

Fix:
- since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists.

Commit 2
========

[FIX] social: fix various issues
1. social_instagram:

ISSUES:
- create a post on the instagram platform with commenting turned off.
- try commenting on it from Odoo. We get a traceback.
- also, if we delete the post from the platform and then try to comment from Odoo,
  we get a traceback.

REASON:
- there is no existing implementation to check if commenting is enabled/disabled
  on the post.

FIX:
- we now check if commenting is enabled or not while trying to add comment on the post

TECHNICAL NOTE:
- the correct way to check if commenting on a post is enabled or not is to request
  a field named `is_comment_enabled`.
- more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media
- but to save us from making an extra request, we simply catch the error received to
  when trying to add a comment.

================================================================================

2. social_linkedin

ISSUE:
- delete an existing post from the linkedIn platform.
- now try commenting on it from Odoo. We get a traceback.

REASON:
- The response received from the request to fetch the comments is not validated.

FIX:
- validating the response before further execution.

Task-3759530

Forward-Port-Of: odoo/enterprise#71534
Forward-Port-Of: odoo/enterprise#67079

### Steps to reproduce the issue:

1. Activate Mexican localization
2. Create multiple Invoices in USD with different amounts (add the Invoice Date)
3. Send and Print them for the CFDI
4. Register a grouped Payment in MXN for those invoices
5. Go to one of the Invoices and click on Update Payments
6. Go to the CFDI tab and, on the Payment line, click on Force CFDI
7. On the Payment line, you should now be able to Download an XML document
8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case

### Explanation:

When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions.

### Fix reasoning:

While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong.

opw-4090269

Forward-Port-Of: odoo/enterprise#70083

**Current behavior:**
Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders.

**Expected behavior:**
Transfer quantity should match sale order line quantity.

**Steps to reproduce:**
1. Enable 2-step delivery in the warehouse

2. In the 2-step delivery route, change the src location of the pick action (pull rule) to be a sub-location of WH/STOCK

3. Enable rental transfers in settings

4. Create a new rental order, add a product, confirm the order

5. Add some quantity to the order line and save

6. Look at the generated out-going picking's moves -> the demand is wrong

**Cause of the issue:**
The original move created when confirming the order, before editing the order line quantity, is not found when the additional move is created for the modified quantity.

Existing outgoing moves are expected to have a location_id (source location) of WH/STOCK (warehouse.lot_stock_id), ours will have a location_id of some sub-location.

**Fix:**
Check all child locations of lot_stock (which includes lot_stock itself) when aggregating outgoing moves.

opw-4178446

Forward-Port-Of: odoo/enterprise#71559