### Steps to reproduce the issue:

1. Create a Product and add a Vendor Price under the Purchase tab
2. Create a Request for Quotation from the Vendor with the Product, change the Unit Price
3. Confirm Order
4. Create a Vendor Bill from the Vendor with one Invoice Line, click on "Purchase Matching"
5. Select the Invoice Line and click on "Add to PO"
6. Select the PO previously created and Add Down Payment
7. On the PO, the Unit Price on the Product Line has reverted to the Vendor Price

### Explanation:

During `_create_downpayments`, `purchase.order.line` created from `account.move.line` are added to `purchase.order.order_line` through a concatenation operator (here a `+`, but `|` would have the same effect).
With this operation, `purchase.order.order_line` is flagged as a modified value and needs to be totally recomputed. In the triggered recomputation methods is `_compute_price_unit_and_date_planned_and_name`, which affects multiple values including `unit_price` and uses `product_product.seller_ids`. https://github.com/odoo/odoo/blob/d0e7be7832672d476f1b289af52d3a425990d719/addons/purchase/models/purchase_order_line.py#L313-L318 https://github.com/odoo/odoo/blob/d0e7be7832672d476f1b289af52d3a425990d719/addons/purchase/models/purchase_order_line.py#L351-L358

### Fix reasoning:

With `Command.link`, only the added lines are flagged as new values and `purchase.order.order_line` is not recomputed.

opw-4275163

Steps to Reproduce:

Create an accrual allocation:
  - Carryover date on allocation start date.
  - Has 1 level:
    * Start 0 days after allocation start date.
    * Accrues 1 day monthly on 1st day of the month.
    * Carryover policy all accrued time carried over.
    * Carryover validity 1 month.
    * Leave other options as is.
  - Leave other options as is.

Create an allocation:
  - Allocation type: accrual allocation.
  - Accrual plan: use the one defined above.
  - The following dates are in mm/dd/YYYY
  - Set allocation start date 08/01/2023.
    Number of days becomes 2 days (as expected).
  - Set allocation start date 09/01/2023.
    Number of day becomes 12 days (as expected).
  - Set allocation start date 08/01/2023.
    Number of days becomes 13 days (wrong).

The issue is that the expiration date of carried over days and the number of expiring days aren't reset when the start date of the allocation changes.

The fix is to reset these values when the start date of the allocation changes.

task-4208024

When the user edits the view and adds context with invalid syntax,
a traceback will appear.

Steps to reproduce the error:

- Go to Settings > Technical > Views > Open any view
- Add context = ``"[]"`` or context = ``"{a}"`` like this in the view
- Save

Traceback:
```
UnboundLocalError: cannot access local variable 'err' where it is not associated with a value
  File "odoo/http.py", line 2365, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1892, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1955, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1922, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2169, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/18.0/industry_fsm_report/controllers/main.py", line 10, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/18.0/worksheet/controllers/main.py", line 10, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/18.0/web_studio/controllers/main.py", line 695, in edit_view
    self._set_studio_view(view, new_arch)
  File "home/odoo/src/enterprise/18.0/web_studio/controllers/main.py", line 456, in _set_studio_view
    studio_view.arch_db = arch
  File "odoo/fields.py", line 1402, in __set__
    records.write({self.name: write_value})
  File "home/odoo/src/enterprise/18.0/web_studio/models/studio_mixin.py", line 33, in write
    res = super(StudioMixin, self).write(vals)
  File "odoo/addons/base/models/ir_ui_view.py", line 535, in write
    res = super(View, self).write(self._compute_defaults(vals))
  File "odoo/models.py", line 4750, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "odoo/models.py", line 1599, in _validate_fields
    check(self)
  File "odoo/addons/base/models/ir_ui_view.py", line 413, in _check_xml
    elif err.__context__:
```

https://github.com/odoo/odoo/blob/69b404c7109ff689381f56520aad758424ec01aa/odoo/addons/base/models/ir_ui_view.py#L413-L418
Here, the ``err`` variable is referenced before the assignment,
So, it will lead to the above traceback.

sentry-5993638522

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

On a stock move, when using a lot from a sub-location, the created
SML will still start from SM's source location instead of lot's location

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a tracked-by-sn product P
3. Update its qty:
   - SN01 at WH/Stock
   - SN02 at WH/Stock/Shelf 1
4. Confirm a delivery with 1 x P
5. Enable the column "Serial Number"
   - SN01 should be present
6. Remove SN01, set SN02
7. Validate the transfer
8. Open the detailed operations

Result: SN02 has been taken from WH/Stock, but the user probably
wanted to use the existing one, in WH/Stock/Shelf 1.

An onchange already exists to make sure that the user is not using a
lot that already exists somewhere else. Before Odoo 17.2, we were
considering the sub locations as not expected:
https://github.com/odoo/odoo/blob/d5a7a3d02e3e2b4e47977abc8b9fc0d5d6135937/addons/stock/models/stock_move.py#L1167
But since Odoo 17.2 (via [1]), we now also accept the sub locations:
https://github.com/odoo/odoo/blob/60b0bafc8abd1893c9cdd9913617c234692369cf/addons/stock/models/stock_move.py#L1242

This is a bit confusing because we don't display any warning anymore,
but we don't select the correct source location neither. The commit
should help the user and avoid that confusion

[1] https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69

OPW-4231749

Forward-Port-Of: odoo/odoo#185796

Currently, a traceback occurs when the user deletes a module which is having a gamification goal record.

To reproduce this issue:

1) Install `sale` and `gamification`
2) Create a new `gamification challenge` record
3) Create a new `goal` in the gamification challenge 
4) Make sure the goal has the definition as `Automatic: sum on a field` 
5) Select the model as `account`
6) Uninstall the invoicing module and start the `challenge` of that gamification.

Error:- 
```
KeyError: False
```

The value of the model_id became `False` when the user deletes a module used in goal.

This leads to a traceback as model_id is used for the reference of obj 

https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165

We can resolve this issue by adding `ondelete='cascade'` in the field
definition. Where the record will be deleted if the corresponding model is 
uninstalled.  

sentry-4089991441

Forward-Port-Of: odoo/odoo#180307

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

Forward-Port-Of: odoo/odoo#185757
Forward-Port-Of: odoo/odoo#171705

**Note** 
Compared to previous versions the `amount_currency` is not updated
anymore in `_sync_invoice` (only the `balance`).

Steps to reproduce:

1. Go to a website page (in edit mode) > Switch the header template to
`"Menu with Search Bar"`.

2. Set a highlight effect on the text element in the top section of the header.

3. The highlight keeps adapting itself infinitely.

Technical details:

After [1], two header navbars were added in the DOM (for the desktop
view and mobile). Which means that the targeted text field is also
duplicated and every change on it in Desktop will be reflected in the
"invisible" mobile version.

When the text is highlighted, the highlight observers are also adapting
the content on both navbars... To understand the conflict, here is an
example of the behaviour causing the infinite loop:

**a.** DESKTOP TEMPLATE > Set a highlight on the text field:
```xml
   <span class="o_text_highlight">
    <span class="o_text_highlight_item">
        Text content.
        <svg.../> // SVG adapted to text dimensions.
    </span>
```

**b.** MOBILE TEMPLATE > The "field observer" will set the same content on
the "invisible" mobile version:
```xml
   <span class="o_text_highlight">
    <span class="o_text_highlight_item">
        Text content.
        <svg.../> // SVG adapted to the desktop text dimensions.
    </span>
```

**c.** MOBILE TEMPLATE > The "highlights adaptation system" detects the
changes on the hidden mobile field and adapts the highlight:
```xml
   <span class="o_text_highlight">
    <span class="o_text_highlight_item">
        Text content.
        <svg.../> // SVG adapted to the mobile text dimensions (0×0).
    </span>
```

**d.** DESKTOP TEMPLATE > The "field observer" will set the same content on
the desktop version, which automatically triggers the highlight size adaptations...

**e.** Same as [**b**].

Infinitely...

In this very specific case, the text content is the same, only the
highlight path is different (because one of the field duplicates is
visible, and the other is hidden).

The goal of this commit is to fix this behaviour by preventing the
highlight's mutation observer from adapting invisible content.

This way, the field synchronization mechanism will always set the same
highlight SVG on the hidden duplicate too (*).

[1]: https://github.com/odoo/odoo/pull/119650

(*): Remarks:

- This won't have an impact on the saved content: We remove all size
related DOM (SVG paths, line breaks,...) before the "save" and we
only keep minimal information needed to rebuild the highlights.

- Also, having a non-adapted effect on the hidden copy of the field is
not an issue here since the "highlight resize observer" will immediately
fix it once displayed (e.g. when switching to mobile preview).

opw-4183587
task-4270159

Forward-Port-Of: odoo/odoo#183414

The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language.

The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874,    Before, to sent the email  `mail.send_mail()`  function was used, and it has a check for the receiver language. and after  https://github.com/odoo/odoo/pull/125874 the function wasnt used any more. it replaces with `mail.send()` that send the rendered content directly.

To resolve this issue, the language of the receiver user is explicitly set in the context before rendering the email template. This ensures the email content is translated based on the user's preferred language then calling the function that send it. 

Now the template is rendered using the receiver's language (`user.lang`), or falls back to the website language `self.env.lang` if the receiver's language is not set. Or falls back to  'en_US' if the language is not set.

owp-4149894


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

Forward-Port-Of: odoo/odoo#182635

**Current behavior:**
Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components.

**Expected behavior:**
The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price.

**Steps to reproduce:**
1. Create a kit product with 2 components, both with qty > 1

2. Assign dropshipping to the kit

3. Create a sale order and confirm -> confirm the purchase order

4. Validate the dropship transfer, invoice the sale order and post it

5. See the 2 inaccurate journal entries, where the debit/credit respectively only total to one instance of each component's cost added together

**Cause of the issue:**
The price unit calculation didn't look at the bom line product qty, only using the price unit 1 time per component.

**Fix:**
Multiply the value by the quantity of it required on its line in the BoM.

opw-4253827

Forward-Port-Of: odoo/odoo#185247
Forward-Port-Of: odoo/odoo#183916

This pr is created to help de user to know the origin of the afip error 10016.

The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The objective of this pr is to be able to differentiate what is the origin of error 10016 and to be able to give a more precise message to the client.

1) If the last afip invoice validated has a higher date than the date of the invoice that is being validated then the message shown to the user is '10016-1': 'The invoice date cannot be after the last invoice validated in AFIP.'

2) If the last afip invoice number is higher than the current invoice number being validated in Odoo, then the message shown to the user is '10016-2': 'There may have been a mismatch in the numbering of this type of document between Odoo and AFIP.'

3) If any other reason cause the error '10016' then the message shown to the user is:
    * Please note that if you are trying to validate an invoice with a date other than today, you must verify if it falls within the date range according to the AFIP concept or document type:

    a) If it is Product: N+5 or N-5 with N being today's date.
    b) If it is Services or Products and services: N+10 or N-10 with N being today's date.
    c) If it is a MiPyme Invoice: N-5 0 N+1 with N being today's date. For Debit Note or Credit Note only N-5"

Task Adhoc side: 37771
Task latam side: 1194

This pr replaces https://github.com/odoo/enterprise/pull/65675

Forward-Port-Of: odoo/enterprise#72901
Forward-Port-Of: odoo/enterprise#72656

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of lines that are shown.

When this limit is reached, we just don't display the exceeding lines, and replace them by a summary line.

To avoid confusion, a warning is now shown on top of the report when some lines need to be hidden. Since such a warning requires a module update (because it's a template, and needs to exist in db), we only apply our new trimming mechanism if the warning template exists (and can hence be displayed). This way, we won't change the behavior on existing databases without being sure the user is properly notified. Plus, thanks to that, we're sure the old load_more_limit value (originally 80 by default) set on the VAT Book will have been increased to a value fitting our use case more, so we won't bother people with excessive trimming.

Original fix suggestion raised here by Adhoc: https://github.com/odoo/enterprise/pull/45936

Forward-Port-Of: odoo/enterprise#72836
Forward-Port-Of: odoo/enterprise#72096

**Steps to reproduce:**
- Install Accounting
- Go to Accounting settings
- Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled)
- Save

**Issue:**
A traceback is raised because it tries to access some fields that are defined in "account_check_printing" module.

**Cause:**
After uninstallation of "account_check_printing" module, the settings page is reloaded.
However, this reload is performed with an old version of the env where the fields defined in the uninstalled module are still there. It's coming from an override of "execute" method of "res.config.settings" defined in Accounting module.
This override is checking if "sign_invoice" field is enable in order to install Sign module.
This action is performed after the "execute" on "super()". If the "execute" is uninstalling a module, the "env" is reset as some models or fields may not be present anymore.
However, in the override of the "execute" method, the old "env" is still used and non-existent fields are prefetched.

**Solution:**
Check to install Sign module in the override of "execute" method before executing the one from "super()" to prevent using an expired "env".

opw-4251932

Forward-Port-Of: odoo/enterprise#72227