Steps to reproduce the issues:

**Issue 1**
- Enter "Website" edit mode.
- Drag and drop a "Cover" snippet into the page.
- Save the snippet as a custom snippet.
- Click the "Custom" category.
- Bug: the "Parallax" label is not displayed on the snippet preview.

**Issue 2**
- Install the "Artists" theme.
- Enter "Website" edit mode.
- Click the "Intro" category.
- Bug: The "Parallax" label is displayed on the "Cover" snippet preview even though it doesn't have a parallax effect.

Commit [1] added a label on snippet previews to indicate if they are Carousel, Popup, Gallery, Tab, or Parallax. This label is linked directly to the snippet's original template. However, this does not work well for "Parallax" because it's an option that can be enabled or disabled. So it doesn't make sense to keep the label when the option is not active.

This commit fixes that by checking the snippet structure to see if it contains a parallax on its background.

[1]: https://github.com/odoo/odoo/commit/63cd0c6497c3c2e8482dc62b4359eb2431a75926

task-4926420

An `AccessError` occurs when a user tries to schedule an activity assigned 
to another internal user without linking it to a record.

**Steps to reproduce**:
1) Install a module
2) Click on the `View all activities` from activities (Top right corner) 
3) Create a new activity without setting a "Link to" record, and assign it
   to another user.

**Issue**:
An AccessError will be raised.

**Cause**:
When the activity has no res_model, the `_action_schedule_activities_personal` 
method is triggered:
https://github.com/odoo/odoo/blob/8e1e4f68763af141c97647fd3e3a2d3a64654a13/addons/mail/wizard/mail_activity_schedule.py#L400-L402 https://github.com/odoo/odoo/blob/8e1e4f68763af141c97647fd3e3a2d3a64654a13/addons/mail/wizard/mail_activity_schedule.py#L415-L424

In this method, both `res_id` and `res_model_id` are passing False, 
and since `activity_user_id` is not the current user, this leads to an `AccessError` 
when trying to create the activity.

**Solution**:
Make res_model required when the assigned user (activity_user_id) is not the current user.

opw-5032100

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/77fd30760 [REL] 18.3.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dc20407b7 [FIX] menu_items: fix sequence calculation for pivot data sources [Task: 5025230](https://www.odoo.com/odoo/2328/tasks/5025230)
https://github.com/odoo/o-spreadsheet/commit/cb952fde2 [FIX] evaluation: fix operation with empty matrices [Task: 5001658](https://www.odoo.com/odoo/2328/tasks/5001658)
https://github.com/odoo/o-spreadsheet/commit/7bba725e5 [FIX] xlsx: make import verbose [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/b50dd2aff [FIX] xlsx: cannot import CF with formulas [Task: 4945945](https://www.odoo.com/odoo/2328/tasks/4945945)
https://github.com/odoo/o-spreadsheet/commit/5ab44cdbd [FIX] GaugeChart: Update config upon sheet renaming [Task: 4868971](https://www.odoo.com/odoo/2328/tasks/4868971)
https://github.com/odoo/o-spreadsheet/commit/f14a2294a [FIX] OT: fix missing transformations [Task: 4868971](https://www.odoo.com/odoo/2328/tasks/4868971)
https://github.com/odoo/o-spreadsheet/commit/e031b43cd [FIX] Range: Clean-up of plugins `adaptRange` [Task: 4868971](https://www.odoo.com/odoo/2328/tasks/4868971)
https://github.com/odoo/o-spreadsheet/commit/1e3d0ff91 [FIX] figures: fix xlsx export [Task: 4755779](https://www.odoo.com/odoo/2328/tasks/4755779)
https://github.com/odoo/o-spreadsheet/commit/9043ef3cb [FIX] pivot: handle vectorized formula [Task: 5043187](https://www.odoo.com/odoo/2328/tasks/5043187)
https://github.com/odoo/o-spreadsheet/commit/ca760721e [FIX] composer: fix import from lib [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a608942b8 [FIX] borders: Recompute borders on `SET_BORDERS_ON_TARGET` [Task: 5024825](https://www.odoo.com/odoo/2328/tasks/5024825)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

### Steps to reproduce:

- Install stock_delivery
- Create and confirm a receipt for 2 products:
    - 1 x P1
    - 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking

#### Expected behavior:

The scheduled date of the picking is updated but not the one of the other move.

#### Current behavior:

The the move scheduled date is also updated.

### Cause of the issue:

Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901

### Note:

This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38

opw-5017423

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

Forward-Port-Of: odoo/odoo#224986

#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp}

### Steps to reporduced:

- In the settings enable: Automatic Accounting
- Create 3 storable product:
	- COMP1, cost 1 $
	- COMP2, cost 2 $
	- KIT with a kit bom using COMP1 and COMP2, cost 3 $
- Modify the product category of all three products to:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
- Create and confirm a sale order with 2 lines:
    - 1 x KIT
    - 1 x COMP2
- Create and confirm the associated invoive
- Try to validate the delivery
#### > UserError: You are trying to reconcile some entries that are already reconciled.

### Cause of the issue:

Validating the delivery will create stock valuation layers related to the associated stock moves — one for COMP1 and two for COMP2 — and then attempt to validate the corresponding accounting entries: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_move.py#L283-L291

However, during this call, the SVLs are grouped by product_id: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L88-L93

As a result, the first time we enter the loop, the accounting entries related to COMP01 will not be reconciled by the
`_stock_account_anglo_saxon_reconcile_valuation` call. This is because we restrict this call using the product COMP01. Therefore, we will not find the invoice needed to reconcile the outgoing moves here: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/account_move.py#L217-L219 (This happens because the related line of the invoice actually refers to the kit product, as the AMLs were not exploded like the stock moves.)

Now, the issue is that, since the AMLs were not reconciled, they will be added to the pool of lines to be reconciled later: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L92-L100

However, the second time we enter the loop — for COMP02 — since COMP02 was sold by itself, there will be an account move line referring to this product on the invoice. The `_stock_account_anglo_saxon_reconcile_valuation` call, now restricted to COMP02, will therefore reconcile the AMLs for both COMP02 and COMP01 related to the kits (as it successfully finds the invoice to reconcile all outgoing moves). This is problematic because the AML related to COMP01 has now been reconciled, despite already having been added to the set of moves to be reconciled. This will raise an error during the second reconciliation attempt: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/account/models/account_move_line.py#L2379-L2380

### Fix:

In the case of kit products, the account move lines of the invoice refer to a different product than the stock valuation layers (because the stock move was exploded but not the AMLs). Therefore, it is important to refer to the kit product during the reconciliation process.

We achieve this by grouping the SVLs using the product of their associated SOL or POL. Unfortunately, we cannot rely on the product from the BoM related to the stock move of the SVL, as kits can be nested within one another. In such cases, the invoice related to the SO or the bill related to the PO would not refer to the intermediate kit we would found that way.

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

Forward-Port-Of: odoo/odoo#223283
Forward-Port-Of: odoo/odoo#221337

Scenario:

- activate another lang on website
- go to a product page (eg. /shop/1)
- swith to secondary language and edit translations

Result: a 500 error page is shown with error:

  Error while render the template
  ValueError: Compute method failed to assign
              product.template.attribute.value(378,).name
  Template: website_sale.product

Cause:

From 18.0 40d79d6c869e2fdd0e85c372aa589373e6607975 used an underscore
prefixed lang in cache, when it should have only done so if the field
had a callable translate.

note: to have the issue, the field needs to also be readonly or we use
update_raw with the non underscore prefixed language.

opw-5039727
opw-5040036
opw-5043034
opw-5043718
opw-5045525
opw-5049079
opw-5049139
opw-5045575
opw-5049531
opw-5049811
opw-5052090
opw-5052930
opw-5053949
opw-5057485
opw-5058659
opw-5059343
opw-5059987
opw-5060138

closes #[225192](https://github.com/odoo/odoo/pull//225192)

Forward-Port-Of: odoo/odoo#225378

`_check_company` can be called on models that don't have a `company_id` field, but they might have a `company_ids` one. In this case the message logged as the user error should be able to handle that scenario.

Example on how to reproduce the error in accounting:

```py
company_a, company_b

tax_group self.env["account.tax.group"].create(
   {
        "name": "Tax Group",
         "company_id": company_a.id,
    }
)

tax = self.env["account.tax"].create(
    {
        "name": "30% - Loan Tax",
        "type_tax_use": "sale",
        "tax_exigibility": "on_payment",
        "amount": 30,
        "amount_type": "percent",
        "tax_group_id": tax_group.id,
        "company_id": company_a.id,
    }
)

account = self.env["account.account"].create({
    ...,
    "company_ids": [Command.link(company_b.id)]
})
account.tax_ids |= tax
```

Error raised
```
AttributeError: 'account.account' object has no attribute 'company_id'
```

After the PR the following message appears:
```
odoo.exceptions.UserError: Incompatible companies on records:
- “Loan Principal” belongs to company “BE Company Loan Tests” and “Default Taxes” (tax_ids: '30% - Loan Tax') belongs to another company.
```

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

Forward-Port-Of: odoo/odoo#225177

Step to reproduce:
- install `l10n_ar` , `website_sale` and `payment_demo`
- Add a language e.g. : spanish (AR)
- switch to `(AR) Responsable Inscripto` and create a website for this company
- change default company for "marc demo" user to `(AR) Responsable Inscripto`
- login with "marc demo" , go to shop page, and change site language to sapnish
- add a product e.g, three set sofa to cart and goto checkout page
- proceed and you will be directed to "Address management page"

Observation:
"Identification Type " and "AFIP Responsibility" are not translated

Cause:
After this commit [1], module l10n_ar_website_sale was dropped and address logic
was mooved to l10n_ar and l10n_latam_base
but the following pot files were not updated, this caused missing of tranlation
in following modules

[1] https://github.com/odoo/odoo/commit/5a93da8e9220ecbf664b26445b04717a9245ef5e

Fix:
Add missing translations in respective po and pot files

Before:
<img width="903" height="517" alt="image" src="https://github.com/user-attachments/assets/f1e265bd-e976-4698-b83b-9de821073b8c" />

After:
<img width="806" height="374" alt="image" src="https://github.com/user-attachments/assets/a04dfde9-8e5d-4699-a1a4-1a8c36339f63" />


opw-5000512

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

Forward-Port-Of: odoo/odoo#224260