Steps to reproduce the bug:
- Create a subcontracted product “P1”:
    - the valuation: AVCO automated
    - BoM:
        - component: C1 ($15)
- Go back to the product form for “P1.”
- Click on "Compute from BoM" -> Result: P1 = $15.
- Create a Purchase order:
    - 1 unit of P1
- Confirm the PO and receive P1
- Return the received quantity:
    - Location: “Partner/lcoation”

**Problem:**
A traceback is triggered:
```
File "/home/odoo/src/odoo/addons/mrp_subcontracting_purchase/models/stock_valuation_layer.py", line 21, in _get_layer_price_unit
 return super()._get_layer_price_unit() + components_price
 File "/home/odoo/src/odoo/addons/purchase_stock/models/stock_valuation_layer.py", line 12, in _get_layer_price_unit
 return self.value / self.quantity
ZeroDivisionError: float division by zero

```

When validating the return, the `_account_entry_move` function is called to verify if the returned value of the product is different from the purchased one. In this case, we need to clear the `stock_in` account with the difference. To do this, we retrieve the layer associated with the origin move of the return. However, since this move is an internal one (from the subcontracting location to WH/stock), the `_should_be_valued` function returns `False`, and no layer is created for this move:

https://github.com/odoo/odoo/blob/7afd9294338dd18c3351afd2017648931fdb9ee3/addons/stock_account/models/stock_location.py#L25-L30

Because we do not check if a layer exists for this move and directly call the `_get_layer_price_unit` function, a traceback is triggered as we have division by zero

**Solution:**
In case there is no layer associated with the original move, we can consider the difference as 0. 

For example, in our case, the layer of the returned move has a value of 30 (15 for P1 and 15 for C1). Therefore, even if we return P1 to the subcontractor, we will not return the value of C1 because it has already been delivered and used.


opw-4053362

Forward-Port-Of: odoo/odoo#176637
Forward-Port-Of: odoo/odoo#176515

Steps to reproduce [`17.2`]:

- Start a fresh DB.
- Enable one of the Spanish sub-languages except the `Spanish LATAM`
(the one with default `/es` url code) e.g., `"es_AR"`.
- An error is triggered when upgrading to a `17.3+` version by the code
trying to set the `'es'` url code while it was already available in
another record.

Starting from [1], we allow using the short url code `'es'` when a
Spanish sub-language is enabled (as long as `es_419` is not) [A].

We also update the records in XML to set the Spanish LATAM (`es_419`) as
the one with the default `'es'`, assuming that the `base.lang_es` record
will always hold the `'es'` url code.

Running the XML updates again in the situation of [A] will try to set
the unique `es` url code on a record while another record (other than
`base.lang_es`) is holding it (`"es_AR"` in this case).

The goal of this commit is to simply add a `noupdate` for the XML
updates so they are only loaded on initialization.

[1]: https://github.com/odoo/odoo/commit/a992d2deab9d582cc33dc31f0b1bd610f82add0d


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

Forward-Port-Of: odoo/odoo#176706

Description of the issue/feature this PR addresses:

- i found that context is never passed in [_duplicateRecords()](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/dynamic_list.js#L210) function for list views, when making 'orm' calls from js side, while it is passed in [duplicate](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/record.js#L191) function of record.js, which is called when duplicating record from form view.

**use case:**
- In `sale_renting` module, There is difference in the result, when a `sale_order` is duplcated from form view(duplicated properly) and when it is duplicated from list view(unexpected result). When duplicating a sale_order, its lines are also being duplicated, and at that time [_compute_is_rental](https://github.com/odoo/enterprise/blob/10006504139abc706ccdb00f71c16846414731eb/sale_renting/models/sale_order_line.py#L56) is being computed, which relies on context key `in_rental_app`. 'in_rental_app' is set in the related action yet was not available when duplicating the sale_order from list view (which resulted in unexpected behaviour).

Current behavior before PR:
- Context is not passed when duplicating Records from list view.

Desired behavior after PR is merged:
- Context is passed when duplicating Records from list view.

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

Forward-Port-Of: odoo/odoo#176305
Forward-Port-Of: odoo/odoo#174137

### **Description:**
* **Steps to Reproduce:-**
        1. Install the Inventory module and create a new warehouse, other than the standard one.
        2. Archive the standard warehouse.
        3. Attempt to install the Point_of_Sale module.

* After this commit: https://github.com/odoo/odoo/commit/0ddd04a34d85386d4ffc59aab07f68b365619b0a, archived warehouses are now also considered when defaulting the `pos_type_id`. Initially, if a warehouse was archived, no `pos_type_id` would be created for it. Later on, if any new `pos_config` record is created for `self.env.company` where the warehouse is archived, it will throw the following error:

```py
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
DETAIL:  Failing row contains (1, null, null, 1, null, 221, 222, null, 1, 170, 169, 289, null, null, 7, null, 1, 1, Shop, total, null, 17c45bf9-4ffa-45ce-b637-53249b394421, direct, null, null, null, null, null, null, null, null, null, null, f, t, null, f, null, t, null, null, null, f, null, null, null, null, null, null, null, null, null, null, t, null, t, 2024-08-06 04:46:54.504337, 2024-08-06 04:46:54.504337, null).
```

While parsing this...

```py
 File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 569, in _tag_root
    raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/odoo/17.0/addons/point_of_sale/data/point_of_sale_data.xml:35, somewhere inside
<record model="pos.config" id="pos_config_main" forcecreate="0">
            <field name="name">Shop</field>
        </record>
```

OPW - 4094096

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

Forward-Port-Of: odoo/odoo#175838

Issue:
======
Image changes aren't auto saved.

Steps to reproduce the issue:
=============================
- Add cover snippet and text-image snipets
- Change cover image or the image in the text-image snippet
- Don't click anywhere after that
- Switch tab to A/B testing for example
- Go back to mail body
- The image changes aren't saved

Origin of the issue and solution:
=================================

When we choose an image from the media dialog, we loose the focus from
the editable which means `onWysiwygBlur` is not called and as
consequence `commitChanges` isn't called too.

Since the flow of the destroy and the `commitChanges` in `onWysiwygBlur`
are in parallel, the following happens:
- We don't update the value in the blur flow because we will wait for
  some promises which may take some time and the component gets
  destroyed and we never call the `updateValue` at the end of the
  function.
- Now in the `commitChanges` coming from `onWillUnmount` we need to pass
  the `urgent` flag in mass_mailing too.

opw-3947516

Forward-Port-Of: odoo/odoo#174740
Forward-Port-Of: odoo/odoo#172312

It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered before the command to stop reaches the browser, that frame capture may complete and be dispatched.

Locally this seems to occur in about 3.5% of calls to `test_screencasts` (7 out of 200 runs). In those cases, the event sequence looks like this:

    T + 0.0000s _save_screencast()
                   sends `Page.stopScreencast`
    T + 0.0002s stop
                   send `Page.stopScreencast`, unsets `screencasts_dir`
    T + 0.0100s _handle_screencast_frame
                   accesses screencasts_frames_dir

`screencasts_frames_dir` then proceed to access `screencasts_dir`, not handle it being `None`, and break.

To fix, just make `screencasts_frame_dir` return `None` if `screencasts_dir` is `None`. This makes `_handle_screencast_frame` properly no-op on the incoming frame. And remove the redundant check on `screencasts_dir` after having ack'd the frame.

Note that this issue has *not* been reported upstream for consideration, as it would require creating a bespoke test case and I can't be arsed. A search on both the tracker and the internet at large doesn't reveal anything relevant.

Example stagings failed due to this:
- https://runbot.odoo.com/runbot/build/66915127
- https://runbot.odoo.com/runbot/build/66915510

And because it's a "traceback found in the logs" it doesn't seem like the runbot is able to see / track it.

Forward-Port-Of: odoo/odoo#176893

**Description**

A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new child and parent hierarchy between report lines that never existed before. This causes a traceback when opening the report on migrated databases. 
The report lines must be loaded in an order where parent lines come before their children. The sorting of `account.report.line` model is by `sequence, id`, where `sequence` column (if unchanged) remains null, causing lines to be sorted by `id`. The change caused larger id records to be assigned as the parent of smaller id records, violating the required hierarchy and raising a traceback.


**Traceback :** 

  ```py
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 4386, in get_report_information
    'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 2123, in _get_lines
    parent_generic_id = line_cache[line.parent_id]['id'] if line.parent_id else None # The parent line has necessarily been treated in a previous iteration
KeyError: account.report.line(338,)
```


**steps to reproduce**
1. install 'l10n_fr' and 'account_accountant' in a demo database of version 16
2. migrate it to version 17.
3. go to Reporting->Profit and Loss (Fr company should be selected)
4. Change Report to "IMB - Intermediate management balances"

Note:  This PR is created by this [suggestion](https://github.com/odoo/upgrade/pull/6267#issuecomment-2244373973).

Forward-Port-Of: odoo/enterprise#68182
Forward-Port-Of: odoo/enterprise#67147