Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids.

This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings.

Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the
`purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s).

Benchmarks:

| No. move lines in delivery | Before  | After |
| -------------------------- | ------- | ----- |
| 7579                       | Timeout | < 200 s   |

opw-5826905

Forward-Port-Of: odoo/enterprise#110587
Forward-Port-Of: odoo/enterprise#110153

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

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#260099
Forward-Port-Of: odoo/odoo#256357

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#113408

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

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

Backport of: https://github.com/odoo/odoo/pull/258938

Forward-Port-Of: odoo/odoo#259717
Forward-Port-Of: odoo/odoo#259585

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/f67756809c [REL] 18.3.43 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7c13cca1f5 [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/3d605a6739 [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/83d8c6b8fc [FIX] package: add rolldown binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d40fcccb5a [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/1efd2ccd33 [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659)
https://github.com/odoo/o-spreadsheet/commit/093fd55760 [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/02e49398f1 [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/7521d5e12c [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/c8aa3813ef [REF] *: apply eslint to entire codebase [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/24afb2933c [IMP] config: Fix eslint to work alongside typescript [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/1091562b49 [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/c8e5617dd4 [FIX] spreadsheet_pivot: avoid crash on invalid dimension values [Task: 6111913](https://www.odoo.com/odoo/2328/tasks/6111913)
https://github.com/odoo/o-spreadsheet/commit/77a7f00b12 [FIX] side_panel: prevent chart picker layout shift on hover [Task: 6095239](https://www.odoo.com/odoo/2328/tasks/6095239)
https://github.com/odoo/o-spreadsheet/commit/1ba7513a50 [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101)
https://github.com/odoo/o-spreadsheet/commit/30ac20d3ca [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0f8f7c632e [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Backport of https://github.com/odoo/odoo/pull/251769

Before this commit, Discuss code may crash with the following error:

```js
TypeError: Cannot read properties of undefined (reading '_raw')
```

This happens because delete operations in JS models could lead to inconsistent state of record lists. Deletion of a record is done internally as follow:

```js
const index = recordList.indexOf(record);
recordList.splice(index, 1);
```

This is done that way as to reuse custom methods of `RecordList`, especially the `splice()` that is used by many methods that mutate the record list. Internal code of the custom `splice` method does `slice()`, which is used to retrieve some records without mutating the record list.

In practice, these `.slice()` were accidentally mutating the list, because they invoke the `Proxy.getter` of the `RecordList`, and when the list is flagged for `computeOnNeed` / `sortOnNeed`, invoking this `Proxy.getter` would mistakenly enable the `computeInNeed` / `sortInNeed` flags and thus mutate the list, e.g. with a sort, which may change the order of items and mess up the `index` computed in `indexOf()` step.

This is what might happen with deletion of any item in record list. For example, let's have `menuThreads` that have this value:

```js
menuThread = ["thread_1", "thread_2", "thread_3"];
```

With the removal of `thread_2`, the `.indexOf()` is `1`, but due to `.slice()` triggering the sort, the list was changed to:

```js
menuThread = ["thread_2", "thread_1", "thread_3"];
```

... And it instead removed `thread_1` but kept `thread_2` in list. This introduce 2 problems:
- `thread_1` is mistakenly removed from relation when it shouldn't
- `thread_2` is kept, but since this is a local id with no actual record in store, `recordList[index]` would return `undefined` as there's no existing record matching this local id.

This commit fixes the issue by improving internal code of record list methods to avoid accidental triggering of lazy re-compute and re-sort. The accidental re-compute and re-sort come from invoking non-implemented array methods on the proxy of record, such as:

- `recordProxy.at()`
- `recordProxy.slice()`

These methods were just used meant to retrieve records from the record list, and they did so by using accessing through `recordProxy`. This approach has the benefit to look good as this is exactly the same as the external API, but it has the unintended side-effect of the re-compute / re-sort of lazy fields. Instead of using these methods, records are retrieved with:

- raw access to get local ids in relation
- convert local ids to raw records through raw access in `store.recordByLocalId`

This approach, while uglier, has the benefit to not accidentally trigger the re-compute / re-sort.

Task-4793779

Forward-Port-Of: odoo/odoo#260109

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#257637
Forward-Port-Of: odoo/odoo#255478

Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels

Steps to reproduce:
1. Install Sales
2. Log in as Marc Demo
3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu
4. An access error is raised Same issue happens for Product Variants

Issue:
https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling
`_can_execute_action_on_records`:
https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239

Solution:
Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed
This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2

opw-6111333

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

Forward-Port-Of: odoo/enterprise#112857