Current behavior:
-
Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks. However, when this delivery is validated, the delivered quantities are not updated on the SO. This is problematic as these quantities are therefore not taken into account on the associated invoice.

Expected behavior:
-
The delivered quantities should be updated negatively on the SO to enable the invoicing of these lines.
This is already the behavior in the POS application and when you create an SO with positive quantities followed by a return for a larger quantity than the one delivered.

Steps to reproduce:
-
Create a storable product with an invoicing policy of type "delivered quantities".

Create an SO with 2 lines:
   - a line with positive quantities for any other product.
   - a line with negative quantities for the product you created.

Confirm and validate the corresponding deliveries. Return to the SO. The quantities for the second line are not updated.

Create an invoice. The second line is not taken into account.

Cause of the issue:
-
The to_refund field of the stock.move model defined in the stock_account module enables a decrease of the delivered quantities in the associated Sale Order. This field is set to True for "classic" returns but not for the stock.move generated from sale.order.line with negative quantities.

Fix:
-
We rely on the _get_custom_move_fields method to add the to_refund field in the procurement 'values' arguments in case the stock_account module is not installed. It is then available to use in the _get_stock_move_values method where we set its value to True if the quantity is negative (so that the move should be considered as a refund).

opw-3676045
-

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

Forward-Port-Of: odoo/odoo#154496
Forward-Port-Of: odoo/odoo#152466

This commit fixes a pretty specific issue within autocomplete behavior where the change event after clearing the value is prevented. Steps to reproduce:
- go to an empty autocomplete and click on it
- start typing a search with results
- click on the first result
- without focusing out, clear the input and finally click out 

No change event is triggered on click out in this case so the cleared value is not updated in the end and saving the record will keep the non cleared value.
The t-on-mousedown.prevent in the dropdown was mainly used to keep the focus on the input after selecting a value for the autocomplete. This introduces a side effect: when one starts typing on the initially empty autocomplete, the browser keeps the initial value of the input in memory until it is focused out (and therefore blurred). When the input is focused out, it will compare the current value of the input with the stored initial value and decide to trigger a change event based on the comparison between the two values: if these are different, the change will trigger. In our case, since the mousedown event on a search result is prevented, no focus out will happen and therefore the browser will still wait for the next focus out to trigger the eventual change event. But since we clear the input before focusing out, the two values are empty and no change event is triggered which introduces the issue. To fix it, we remove the t-on-mousedown.prevent of the template and manually avoid triggering the onInputBlur method with a flag to keep the previous behavior and we finally focus on the input programatically after selecting a value.

task-3734818

Forward-Port-Of: odoo/odoo#154448
Forward-Port-Of: odoo/odoo#154203

### Steps to reproduce issue:

1. Create Draft invoice with no Invoice Date
2. Set payment terms with multiple due dates (e.g.: "30% Now, Balance 60 Days)
3. Make sure "Show installment dates" is ticked in the payment terms form
4. Print invoice
5. Receive traceback with main message:

>     odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
>     ValueError: The value send to monetary field is not a number.
>     Template: account.report_invoice_document
>     Path: /t/t/div[2]/div/div[3]/div[2]/t/div/div/t[1]/td/span[1]
>     Node: <span t-options="{&quot;widget&quot;: &quot;monetary&quot;, &quot;display_currency&quot;: o.currency_id}" t-out="o.invoice_payment_term_id._get_amount_due_after_discount(o.amount_total, o.amount_tax)"/>

### Explanation:

`_is_eligible_for_early_payment_discount` will normally return `True` only if every condition is fulfilled. In previous fix odoo@9b20af823d3d2d8c3c70fd016d71448caa039958, we bypassed all of them if `reference_date` had no value.
https://github.com/odoo/odoo/blob/4b744c82c3f902448a5c89c4711eccfeb1b548b8/addons/account/models/account_move.py#L1910-L1918
The method is called here, leading to the field that triggers the traceback.
https://github.com/odoo/odoo/blob/8f3c0b218eb9ea725995d716e97999556ce74578/addons/account/views/report_invoice.xml#L230-L236
The reason it only blocks with multiple due dates is because of the first line: `payment_term_details` is true when there are multiple due dates or an early discount, the latter being the concern of the previous fix.
The second one is true if "Show installment dates" is ticked.

### Suggested fix:

`reference_date` should not take priority. Therefore, we will only override its own condition when it has no value.

opw-3726968

Forward-Port-Of: odoo/odoo#153401

Purpose
=======

Calling copy in a list comprehension or a loop does break the batch definition of many stuffs (create, message_subscribe, followers management, ...) leading to a large amount of unnecessary requests while duplicating many records.

The copy method is actually the only method left from the old API that does not handle recordsets.

This commit is making the copy and copy_data methods work in batch improving the execution of the computed fields, and the whole records creation process.

Now, copy works mainly like this:

@api.returns('self')
def copy(self, default=None):
    vals_list = self.copy_data(default)  # this one returns a list of vals
    return self.create(vals_list)

And if you want specific vals for each record in the output, simply use copy_data() and modify its output accordingly, like in:

@api.returns('self')
def copy_data(self, default):
    vals_list = super().copy_data(default)
    return [dict(vals, name=_("%s (copy)", product.name)) for product, vals in zip(self, vals_list)]

For the record, duplicating 400 project.tasks (with lot of postprocess on copy about milestones, task dependencies, SOL mapping) divides the number of sql request by 2.4 (11000 -> 4500) and divides the execution time by 3 (15 -> 5 seconds).

TaskID: 3742289

REAL TAX CASES TO COVER

INDIAN CASE:
6% incl + 6% incl + 3% excl

Both 6% incl must always have the same tax amounts (not working in master but fixed as well in this task). The 3% must be based on 12% (working thanks to the is_base_affected checkbox). BELGIUM CASE:
fixed tax + 21% incl (recupel case)

That's for this case we allow to mix price-excluded with price-included taxes.

BRAZILIAN CASE:
5 taxes having the 'division' type: 5% 3%, 0.65%, 9% and 15%.

This case is tricky because it's based on the price-included amount and the whole computation was made only from the price-excluded amount. With a base of 48.0, the base amount of the 15% tax is computed as 48.0 * (1 - 0.15) = 40.8 so a tax amount of 48.0 - 40.8 = 7.2.

So the respective <base, tax_amount> of each taxes are: 45.6, 2.4 46.56, 1.44
47.69, 0.31
43.68, 4.32
40.8, 7.2
...and the price-excluded amount is 40.8.

PROBLEMS TO SOLVE

INDIAN CASE:
Suppose a base of 100 with 2 x 6% incl taxes.

The behavior in master:
a - Find the price-excluded base: 100 / 1.12 ~= 89.29 b - Compute the first 6% incl tax amount: 89.29 * 0.06 = 5.36 c - Compute the second 6% incl tax amount. Since it's the last one before the "cached base amount of 100", it's computed as 100 - 89.29 - 5.36 = 5.35

=> 5.35 != 5.36

The behavior in the current task:
a - Compute the base amount for the computation of the 2 x 6% incl taxes: 100 / 1.12 = 89.2857 b - Compute the tax amount for the 2 taxes: 89.2857 * 0.06 = 5.357142 ~= 5.36 c - Compute the base amount of the 2 x 6% incl taxes: 100 - 5.36 - 5.36 = 89.28. => Problem solved

BELGIUM CASE:
Suppose a base of 120.90 with 0.10 fixed tax (must be include_base_amount), then 21% incl tax.

The behavior in master:
a - Find the price-excluded base: 120.90 / 1.21 = 99.92 b - Compute the percentage tax: (99.92 + 0.10) * 0.21 = 21.0 => total tax is 21.0 + 0.10 = 21.10 but the base is 99.92 so the total of the invoice will be 121.02.

The results is supposed to be the same as 2 lines: line1: 120.90 with 21% incl tax line2: 0.10 with 21% incl tax
...giving a price total of 121, a price subtotal of 100 and a tax amount of 21.

The behavior in the current task:
a - First ascending computation: Compute first the tax amounts of the fixed taxes: 0.10. b - Descending computation: Compute the base and tax amounts for the 21% tax: (120.90 + 0.10) / 1.21 = 100 then 100 * 0.21 = 21.0. c - Second ascending computation: Compute the base of 0.10 being 120.90.

BRAZILIAN CASE:
As said before, from 40.8, it's impossible to recompute the correct tax amounts. Suppose a base of 48.0 with 5% 3%, 0.65%, 9% and 15%, all division price included taxes.

The behavior in master:
a - Find the price-excluded base: 48.0 * (1 - 0.3265) ~= 32.33 b - Wrongly compute the tax amounts price-excluded for 5%, 3%, 0.65%, 9%:

tax of 5%: 32.33 / 0.95 - 32.33 = 1.7
tax of 3%: 32.33 / 0.97 - 32.33 = 1.0
tax of 0.65%: 32.33 / 0.9935 - 32.33 = 0.21
tax of 9%: 32.33 / 0.91 - 32.33 = 3.2

c - the tax of 15% takes the remaining amount: 48.0 - 32.33 - 1.7 - 1.0 - 0.21 - 3.2 = 9.56 => Nothing works at all...

The behavior in the current task:
a - Descending computation: Compute the base and tax amounts for all taxes:

48.0 * 0.95 = 45.6; 48.0 - 45.6 = 2.4
48.0 * 0.97 = 46.56; 48.0 - 46.56 = 1.44
48.0 * 0.65 = 47.69; 48.0 - 47.69 = 0.31
48.0 * 0.91 = 43.68; 48.0 - 43.68 = 4.32
48.0 * 0.85 = 40.8; 48.0 - 40.8 = 7.2

REMAINING PROBLEMS

Even the taxes computation will be fixed by this commit, some issues remain:

-rounding issues on POS global discount/loyalties
-bad computation of combo product with complex taxes -python taxes not working on the POS
-perf of the tax details queries
-round globally not working due to the accounting grouping key -...
For all those reasons, this commit also adds new cool features:

The taxes computation is splitted in 2 parts:
a - prepare_taxes_computation that gives a formula to compute each tax independently. b - evaluate the taxes computation given by (a). This will help a lot to change the tax details query later by: a - pre-compile the taxes combinations first python-side. b - compute the tax details in SQL.

The taxes computation is now completely reversible if you don't have any rounding in the process and thus, would help to solve the global discount/loyalties/product combo taxes computation. Also, the fiscal position mapping is now more accurate and is able to manage division taxes as well.

The method are splitted in a way is will be quite easy to fix the round globally: Instead of:

For each line, create a tax detail per repartition line Sum the tax details per repartition line and create tax lines => It gives a sum of rounded amounts that could be far from the expected amount: round(base * percentage). Do: For each line, create a tax detail per tax.
Sum the tax details per tax and round them if round_per_line. Spread the amounts onto the repartition lines. => It will give exactly the tax amount expected by the user: round(base * percentage).

opw: 3443703

**Performance Improvement on Referral Link Generation**
---------------------------------------------------------------------------------------

Current State
-------------------

Currently in the `hr.referral` module when you want to generate a new referral link for a user it takes more or less a second.

State After this commit
---------------------------------

The generation of the link is in average way under the 10ms mark

Tests ordered by performance uplift ascending
-------------------------------------------------------------------
Note: All the tests have been made 3times and I took the less advantageous one for this commit every time.
Note2: As explained after the result are probably underestimated since with the current behavior we litterally make a request and get the full web page of the job position when generating a referral link which is extremely dependent on the load of the server and the db. (We can even have timeout) The time it takes currently is also directly dependant of the size of the job page so it could be theoretically speaking arbitrary long to get the job page.
Note3: All the tests are realized on 15.0

**Full response (+- 18x)**
**On runbot including the time of response before**
![Screenshot_20240208_195721](https://github.com/odoo/enterprise/assets/63317845/feb8b624-1ba6-47f6-8f41-411e08772179)

**On runbot including the time of response after**
![Screenshot_20240208_200459](https://github.com/odoo/enterprise/assets/63317845/761f5cc0-9037-4121-8c0a-4187facf4cfc)
We are in the golden bracket of 50-150ms latency

**Create  (+-  100x)**
**On runbot before**
Note:  Don't hesitate to click on the photos to zoom in it
cropped
![slow](https://github.com/odoo/enterprise/assets/63317845/6b3f4419-a21a-4025-b566-09168c9e313f)
full
![Screenshot_20240208_202809](https://github.com/odoo/enterprise/assets/63317845/2ffb8c58-ab94-4b01-a310-c518ace7d6a2)

**On runbot after**
cropped
![fast](https://github.com/odoo/enterprise/assets/63317845/312fa017-cce2-49c9-9185-5ff3cda562ac)
full
![Screenshot_20240208_202650](https://github.com/odoo/enterprise/assets/63317845/c6ef8c34-07c8-4fff-adc1-b40ab2680407)

**Note for master**
In master the `create` method is taking most of the time 3.8ms to execute with no real changes for the `search_or_create` so you'll get an uplift of arround 250x with this commit

Explaination
------------------
Currently when you generate a referral link in the referral app you'll call the the `search_or_create` method of the `link.tracker` model.

``` python
    @api.model
    def search_or_create(self, vals):
        if 'url' not in vals:
            raise ValueError(_('Creating a Link Tracker without URL is not possible'))
        if vals['url'].startswith(('?', '#')):
            raise UserError(_("%r is not a valid link, links cannot redirect to the current page.", vals['url']))
        vals['url'] = tools.validate_url(vals['url'])

        search_domain = [
            (fname, '=', value)
            for fname, value in vals.items()
            if fname in ['url', 'campaign_id', 'medium_id', 'source_id']
        ]
        result = self.search(search_domain, limit=1)

        if result:
            return result

        return self.create(vals)

```

And if we don't have a hit during the search we will create the `link.tracker` record that is created this way:

```python
    @api.model_create_multi
    def create(self, vals_list):
        vals_list = [vals.copy() for vals in vals_list]
        for vals in vals_list:
            if 'url' not in vals:
                raise ValueError(_('Creating a Link Tracker without URL is not possible'))

            if vals['url'].startswith(('?', '#')):
                raise UserError(_("%r is not a valid link, links cannot redirect to the current page.", vals['url']))
            vals['url'] = tools.validate_url(vals['url'])

            if not vals.get('title'):
                vals['title'] = self._get_title_from_url(vals['url'])

            # Prevent the UTMs to be set by the values of UTM cookies
            for (__, fname, __) in self.env['utm.mixin'].tracking_fields():
                if fname not in vals:
                    vals[fname] = False
```
 As we can see here if no **title** is given to the `search_or_create` method we will call the `_get_title_from_url` method of `link.tracker`

```python

    @api.model
    @api.depends('url')
    def _get_title_from_url(self, url):
        preview = link_preview.get_link_preview_from_url(url)
        if preview and preview.get('og_title'):
            return preview['og_title']
        return url
```

If you time this method it takes around .9 seconds to do it's job. (In local it represent more than 99 percent of the time that take the `create` method)

On the runbot
![very slow](https://github.com/odoo/enterprise/assets/63317845/41cc31eb-b2d3-42cb-a4a8-ee2e371bbb1a)

If we go to `odoo.addons.mail.tools.link_preview` we can clearly see why it takes time

```python
def get_link_preview_from_url(url, request_session=None):
    # Some websites are blocking non browser user agent.
    user_agent = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0'}
    try:
        if request_session:
            response = request_session.get(url, timeout=3, headers=user_agent, allow_redirects=True, stream=True)
        else:
            response = requests.get(url, timeout=3, headers=user_agent, allow_redirects=True, stream=True)
    except requests.exceptions.RequestException:
        return False
    if not response.ok or not response.headers.get('Content-Type'):
        return False
    # Content-Type header can return a charset, but we just need the
    # mimetype (eg: image/jpeg;charset=ISO-8859-1)
    content_type = response.headers['Content-Type'].split(';')
    if response.headers['Content-Type'].startswith('image/'):
        return {
            'image_mimetype': content_type[0],
            'og_image': url, # If the url mimetype is already an image type, set url as preview image
            'source_url': url,
        }
    elif response.headers['Content-Type'].startswith('text/html'):
        return get_link_preview_from_html(url, response)
    return False

def get_link_preview_from_html(url, response):
    content = b""
    for chunk in response.iter_content(chunk_size=8192):
        content += chunk
        pos = content.find(b'</head>', -8196 * 2)
        # Stop reading once all the <head> data is found
        if pos != -1:
            content = content[:pos + 7]
            break

    if not content:
        return False
    tree = html.fromstring(content)
    og_title = tree.xpath('//meta[@property="og:title"]/@content')
    if og_title:
        og_title = og_title[0]
    elif tree.find('.//title') is not None:
        # Fallback on the <title> tag if it exists
        og_title = tree.find('.//title').text
    else:
        return False
    og_description = tree.xpath('//meta[@property="og:description"]/@content')
    og_type = tree.xpath('//meta[@property="og:type"]/@content')
    og_site_name = tree.xpath('//meta[@property="og:site_name"]/@content')
    og_image = tree.xpath('//meta[@property="og:image"]/@content')
    og_mimetype = tree.xpath('//meta[@property="og:image:type"]/@content')
    return {
        'og_description': og_description[0] if og_description else None,
        'og_image': og_image[0] if og_image else None,
        'og_mimetype': og_mimetype[0] if og_mimetype else None,
        'og_title': og_title,
        'og_type': og_type[0] if og_type else None,
        'og_site_name': og_site_name[0] if og_site_name else None,
        'source_url': url,
    }
```
As we can see it clearly makes a request to the server (in this case itself) that will take in most cases something like a second. (It can be longer and **timeout after 3 seconds and thus not even giving us a title at all and then give you the url as a title**)
[BTW In this case, doing that is probably sub optimal because we could probably just used some internal methods to accelerate the process instead of using `get`]

So we make a request to the server that will need to actually render the view with all the fields and then analyzing it to retrieve infos.


**In conclusion**
By giving a title to the link that we want to generate it will be way faster and since the title is not taken into account during the search part of the `search_or_create`, we basically have no change in behavior and even getting more consistency in the titles that will be displayed on base_url/r.

Other benefits
----------------------
1. Before the links title where generated using the meta of the web page. This can lead to basically random titles because if no one has visited the page before, the title will be the link (same if the request timeout) and if it has been visited it will be the title that you can see in your tabs.
2. You can basically reduce the number of requests to the server which in this case is even better because the more user you have the more likely you will overload it and increase the probability of a request timeout.
3. Before the multi db on read mode all the activity on website are tracked and since you literally visit the web page of the job title you'll get some bias on the website activity. This commit solve this issue as well because we'll not visit the job url anymore.
4. Consistency in the time needed to generated a link.

Performance impact for big companies like odoo
----------------------------------------------------------------------
**Today**
we have 35 different jobs opened for referral
We are 4k employees
if you want to generate all referral links even when taking advantage of batch it will take you more or less 35hours of computations
(in the near future we will include the possibility to generate all the links and send them to all employees and with this it's possible to do it in less than a minute by taking advantage of the batch create)

For the near future
----------------------------
2 tasks are including to generate a bunch of referral links at the same time (with a company of the size of odoo)
- 3418434 (more than a minute just to open the jobs page)
- 3607159 (with current state more than 2hours to send the mails)

task-3707478

Forward-Port-Of: odoo/enterprise#56907
Forward-Port-Of: odoo/enterprise#55349

This commit fixes a bug where the Comments would only load one of the different Components present inside of the view, meaning that only one thread would show their messages. This leads to possible losses of comments and the main chatter being unable to show messages.

The issue was that both the comments and the form view shared a singular chatter object in the environment. This object enables the Thread component to know if it needs to either load more data or messages via two booleans: `fetchData` and `fetchMessages` that would be set to false when the Thread finished fetching either messages or data.

To fix this, the chatter in the environment below the Comment level was set to false, as the condition to fetch data and messages is `!this.env.chatter || this.env.chatter?.fetchData`. This way when OWL mounts each Comment Component it will fetch the necessary data without impacting each other and the Form view's main chatter.

task-3714345

Forward-Port-Of: odoo/enterprise#55517

**Performance Improvement on Referral Link Generation**
---------------------------------------------------------------------------------------

Current State
-------------------

Currently in the `hr.referral` module when you want to generate a new referral link for a user it takes more or less a second.

State After this commit
---------------------------------

The generation of the link is in average way under the 10ms mark

Tests ordered by performance uplift ascending
-------------------------------------------------------------------
Note: All the tests have been made 3times and I took the less advantageous one for this commit every time.
Note2: As explained after the result are probably underestimated since with the current behavior we litterally make a request and get the full web page of the job position when generating a referral link which is extremely dependent on the load of the server and the db. (We can even have timeout) The time it takes currently is also directly dependant of the size of the job page so it could be theoretically speaking arbitrary long to get the job page.
Note3: All the tests are realized on 15.0

**Full response (+- 18x)**
**On runbot including the time of response before**
![Screenshot_20240208_195721](https://github.com/odoo/enterprise/assets/63317845/feb8b624-1ba6-47f6-8f41-411e08772179)

**On runbot including the time of response after**
![Screenshot_20240208_200459](https://github.com/odoo/enterprise/assets/63317845/761f5cc0-9037-4121-8c0a-4187facf4cfc)
We are in the golden bracket of 50-150ms latency

**Create  (+-  100x)**
**On runbot before**
Note:  Don't hesitate to click on the photos to zoom in it
cropped
![slow](https://github.com/odoo/enterprise/assets/63317845/6b3f4419-a21a-4025-b566-09168c9e313f)
full
![Screenshot_20240208_202809](https://github.com/odoo/enterprise/assets/63317845/2ffb8c58-ab94-4b01-a310-c518ace7d6a2)

**On runbot after**
cropped
![fast](https://github.com/odoo/enterprise/assets/63317845/312fa017-cce2-49c9-9185-5ff3cda562ac)
full
![Screenshot_20240208_202650](https://github.com/odoo/enterprise/assets/63317845/c6ef8c34-07c8-4fff-adc1-b40ab2680407)

**Note for master**
In master the `create` method is taking most of the time 3.8ms to execute with no real changes for the `search_or_create` so you'll get an uplift of arround 250x with this commit

Explaination
------------------
Currently when you generate a referral link in the referral app you'll call the the `search_or_create` method of the `link.tracker` model.

``` python
    @api.model
    def search_or_create(self, vals):
        if 'url' not in vals:
            raise ValueError(_('Creating a Link Tracker without URL is not possible'))
        if vals['url'].startswith(('?', '#')):
            raise UserError(_("%r is not a valid link, links cannot redirect to the current page.", vals['url']))
        vals['url'] = tools.validate_url(vals['url'])

        search_domain = [
            (fname, '=', value)
            for fname, value in vals.items()
            if fname in ['url', 'campaign_id', 'medium_id', 'source_id']
        ]
        result = self.search(search_domain, limit=1)

        if result:
            return result

        return self.create(vals)

```

And if we don't have a hit during the search we will create the `link.tracker` record that is created this way:

```python
    @api.model_create_multi
    def create(self, vals_list):
        vals_list = [vals.copy() for vals in vals_list]
        for vals in vals_list:
            if 'url' not in vals:
                raise ValueError(_('Creating a Link Tracker without URL is not possible'))

            if vals['url'].startswith(('?', '#')):
                raise UserError(_("%r is not a valid link, links cannot redirect to the current page.", vals['url']))
            vals['url'] = tools.validate_url(vals['url'])

            if not vals.get('title'):
                vals['title'] = self._get_title_from_url(vals['url'])

            # Prevent the UTMs to be set by the values of UTM cookies
            for (__, fname, __) in self.env['utm.mixin'].tracking_fields():
                if fname not in vals:
                    vals[fname] = False
```
 As we can see here if no **title** is given to the `search_or_create` method we will call the `_get_title_from_url` method of `link.tracker`

```python

    @api.model
    @api.depends('url')
    def _get_title_from_url(self, url):
        preview = link_preview.get_link_preview_from_url(url)
        if preview and preview.get('og_title'):
            return preview['og_title']
        return url
```

If you time this method it takes around .9 seconds to do it's job. (In local it represent more than 99 percent of the time that take the `create` method)

On the runbot
![very slow](https://github.com/odoo/enterprise/assets/63317845/41cc31eb-b2d3-42cb-a4a8-ee2e371bbb1a)

If we go to `odoo.addons.mail.tools.link_preview` we can clearly see why it takes time

```python
def get_link_preview_from_url(url, request_session=None):
    # Some websites are blocking non browser user agent.
    user_agent = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0'}
    try:
        if request_session:
            response = request_session.get(url, timeout=3, headers=user_agent, allow_redirects=True, stream=True)
        else:
            response = requests.get(url, timeout=3, headers=user_agent, allow_redirects=True, stream=True)
    except requests.exceptions.RequestException:
        return False
    if not response.ok or not response.headers.get('Content-Type'):
        return False
    # Content-Type header can return a charset, but we just need the
    # mimetype (eg: image/jpeg;charset=ISO-8859-1)
    content_type = response.headers['Content-Type'].split(';')
    if response.headers['Content-Type'].startswith('image/'):
        return {
            'image_mimetype': content_type[0],
            'og_image': url, # If the url mimetype is already an image type, set url as preview image
            'source_url': url,
        }
    elif response.headers['Content-Type'].startswith('text/html'):
        return get_link_preview_from_html(url, response)
    return False

def get_link_preview_from_html(url, response):
    content = b""
    for chunk in response.iter_content(chunk_size=8192):
        content += chunk
        pos = content.find(b'</head>', -8196 * 2)
        # Stop reading once all the <head> data is found
        if pos != -1:
            content = content[:pos + 7]
            break

    if not content:
        return False
    tree = html.fromstring(content)
    og_title = tree.xpath('//meta[@property="og:title"]/@content')
    if og_title:
        og_title = og_title[0]
    elif tree.find('.//title') is not None:
        # Fallback on the <title> tag if it exists
        og_title = tree.find('.//title').text
    else:
        return False
    og_description = tree.xpath('//meta[@property="og:description"]/@content')
    og_type = tree.xpath('//meta[@property="og:type"]/@content')
    og_site_name = tree.xpath('//meta[@property="og:site_name"]/@content')
    og_image = tree.xpath('//meta[@property="og:image"]/@content')
    og_mimetype = tree.xpath('//meta[@property="og:image:type"]/@content')
    return {
        'og_description': og_description[0] if og_description else None,
        'og_image': og_image[0] if og_image else None,
        'og_mimetype': og_mimetype[0] if og_mimetype else None,
        'og_title': og_title,
        'og_type': og_type[0] if og_type else None,
        'og_site_name': og_site_name[0] if og_site_name else None,
        'source_url': url,
    }
```
As we can see it clearly makes a request to the server (in this case itself) that will take in most cases something like a second. (It can be longer and **timeout after 3 seconds and thus not even giving us a title at all and then give you the url as a title**)
[BTW In this case, doing that is probably sub optimal because we could probably just used some internal methods to accelerate the process instead of using `get`]

So we make a request to the server that will need to actually render the view with all the fields and then analyzing it to retrieve infos.


**In conclusion**
By giving a title to the link that we want to generate it will be way faster and since the title is not taken into account during the search part of the `search_or_create`, we basically have no change in behavior and even getting more consistency in the titles that will be displayed on base_url/r.

Other benefits
----------------------
1. Before the links title where generated using the meta of the web page. This can lead to basically random titles because if no one has visited the page before, the title will be the link (same if the request timeout) and if it has been visited it will be the title that you can see in your tabs.
2. You can basically reduce the number of requests to the server which in this case is even better because the more user you have the more likely you will overload it and increase the probability of a request timeout.
3. Before the multi db on read mode all the activity on website are tracked and since you literally visit the web page of the job title you'll get some bias on the website activity. This commit solve this issue as well because we'll not visit the job url anymore.
4. Consistency in the time needed to generated a link.

Performance impact for big companies like odoo
----------------------------------------------------------------------
**Today**
we have 35 different jobs opened for referral
We are 4k employees
if you want to generate all referral links even when taking advantage of batch it will take you more or less 35hours of computations
(in the near future we will include the possibility to generate all the links and send them to all employees and with this it's possible to do it in less than a minute by taking advantage of the batch create)

For the near future
----------------------------
2 tasks are including to generate a bunch of referral links at the same time (with a company of the size of odoo)
- 3418434 (more than a minute just to open the jobs page)
- 3607159 (with current state more than 2hours to send the mails)

task-3707478

Forward-Port-Of: odoo/enterprise#56907
Forward-Port-Of: odoo/enterprise#55349

With this commit, list data is loaded using `web_search_read` instead of `search_read`.

The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request, instead of 2 RPCs.

Pros:
- less code
- one evaluation saved
- one network request saved
- easier future refactoring (see below)

Cons:
- overhead of data transferred over network (from 4.5MB to 6.5MB, unzipped, to fetch a list of 20K crm leads).

Before this commit, here is what it looked like:

1. the list data is fetch (with the currency_field)
2. the cells are evaluated with the new data
3. we realize we want to format a currency amount. We already have the currency name but not the symbol, etc. So we fetch the currency data
4. evaluate the cells again with the new currency format

Now:
1. fetch the list data with everything we need for the currency
2. evaluate the cells

This commit also serves another goal for a future refactoring: in the hope of avoiding throwing "loading errors", I'd like to have an easy way to know if a data source is fully loaded or not (the data and the format). With this commit, everything is centralized in the list data source with a single RPC. The goal is therefore achieved with this commit.

Task: 3730232

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Add a bunch of QOL improvements in the results page design:

- Display the survey results page in half page size to prevent having too much blank space between the tables columns
- The filter buttons are now displayed under the survey title
- Show the leaderboard bar on the print preview
- Changing the eye dropdown icon to a caret for fold/unfold
- Align questions to the left to be on the same level as the sections
- Add an horizontal scroll to the matrix and simple/multiple choices tables when the screen is not wide enough to display all the data
- Reduce vertical spacing between elements to gain space
- Reduce simple/multiple choices tables line height
- Reduce survey title, section title and KPIs font size
- Display the "Correct", "Partial", "Responded" and "Skipped" badges on a single line and set a rounded border around.
- Removing the "Result Overview" title
- Removing survey description, section description and question description

Task-3707687

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

Adds a bunch of extra steps in the tour to avoid race errors.
Also, make some minor changes in the code:

- `action_add_byproduct` and `action_add_component` for `mrp.production` call `ensure_one` to be sure those methods are called with an existing record, and the ones from `mrp.workorder` call the `mrp.production` method to avoid duplicate;

- For the `mrp_workorder.additional.product` wizard, the `production_id` is now got from the context. Before, it was `workorder_id` who was took from the context, but it does not make sense since the tablet view was dropped for the Shop Floor (where the MO is now the main model). Also, the `company_id` is now related from the MO.

- Regarding the previous point, we pass the key `'production_id'` instead of `'default_production_id'` in the context to avoid the propagation to the creation of the move (otherwise, a component move will have the `production_id` field set and the move will also be count as a by-product move.)

Run build error: 56688

[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods`

The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method, preventing overriding modules from controlling which payment method should be available depending on the kwargs.

task-3640488

---

[FIX] payment: archive tokens of payment methods blocking tokenization 

When a payment method was updated in a way that prevented creating
tokens with it, that is, by either disabling it, unchecking the
"Tokenization Supported" field, or unlinking it from providers, only the
latter would automatically archive the related tokens after showing a
warning to the user. The two first actions prevented the creation of
future tokens with that payment method, but existing tokens could still
be used.

This commit fixes that behavior by adding the warning and the automatic
archiving of related tokens where they were missing. Preventing further
tokenization with a payment method now consistently blocks payments
through existing tokens, too.

---

See also:
- https://github.com/odoo/enterprise/pull/54700

This commit resolves a bug related to zero-width spaces within the inner
content of a link. The bug led to a systematic test failure in 17.0
link_tools when comparing the input value with the expected value.
The bug originated from [1] that manipulates zero-width
spaces to allow users to select the edges of the link.

Steps to reproduce:
- Navigate to the Project app and open a random task (create one if none
  exists).
- Select the "Description" tab.
- Enter "/link" and press "Enter" to activate the link tools dialog box.
- In the link label field, input "The Website".
- In the URL or email field, input "localhost:8069".
- Save the changes.
- A new div is generated with the class "note-editable".
- Click on the newly created link.
- Edit the link by clicking on the edit icon in the popover.
- Direct the focus to the link label field at the end of the string "The
  Website".
- Press the "Backspace" key — observe that nothing happens.

It's maybe just a complement to this [PR]
The test added in [2] eliminates zero-width-spaces prior to
asserting the equality of values. This was appropriately addresses and
handled in this commit.

[PR]: https://github.com/odoo/odoo/pull/142135
[1]: https://github.com/odoo/odoo/commit/ab40f48
[2]: https://github.com/odoo/odoo/commit/a56586119845969e9d867a220f5330a6c7daa5c2
runbot-44779

Forward-Port-Of: odoo/odoo#153911
Forward-Port-Of: odoo/odoo#144321

### Steps to reproduce issue:

1. Create Draft invoice with no Invoice Date
2. Set payment terms with multiple due dates (e.g.: "30% Now, Balance 60 Days)
3. Make sure "Show installment dates" is ticked in the payment terms form
4. Print invoice
5. Receive traceback with main message:

>     odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
>     ValueError: The value send to monetary field is not a number.
>     Template: account.report_invoice_document
>     Path: /t/t/div[2]/div/div[3]/div[2]/t/div/div/t[1]/td/span[1]
>     Node: <span t-options="{&quot;widget&quot;: &quot;monetary&quot;, &quot;display_currency&quot;: o.currency_id}" t-out="o.invoice_payment_term_id._get_amount_due_after_discount(o.amount_total, o.amount_tax)"/>

### Explanation:

`_is_eligible_for_early_payment_discount` will normally return `True` only if every condition is fulfilled. In previous fix odoo@9b20af823d3d2d8c3c70fd016d71448caa039958, we bypassed all of them if `reference_date` had no value.
https://github.com/odoo/odoo/blob/4b744c82c3f902448a5c89c4711eccfeb1b548b8/addons/account/models/account_move.py#L1910-L1918
The method is called here, leading to the field that triggers the traceback.
https://github.com/odoo/odoo/blob/8f3c0b218eb9ea725995d716e97999556ce74578/addons/account/views/report_invoice.xml#L230-L236
The reason it only blocks with multiple due dates is because of the first line: `payment_term_details` is true when there are multiple due dates or an early discount, the latter being the concern of the previous fix.
The second one is true if "Show installment dates" is ticked.

### Suggested fix:

`reference_date` should not take priority. Therefore, we will only override its own condition when it has no value.

opw-3726968

Forward-Port-Of: odoo/odoo#153401