Steps to reproduce
==================

- Install contacts,web_studio
- Login as admin
- Go to contacts
- Open any record
- Open studio
- Click on any field
- Add the "Role / Portal" group
- Toggle the "Show invisible Elements" checkbox
- Click on the same field

=> The field is marked as invisible

- Add an invisible condition

=> The invisible condition is lost (but still applied on the view)

Cause of the issue
==================

In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups).

The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled.

But this causes the actual value of the invisible attribute to be lost.

Note that this also applies to the column_invisible attribute.

Solution
========

If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute.

We then use that value in the editor, when present.

opw-6026971

Forward-Port-Of: odoo/enterprise#111868
Forward-Port-Of: odoo/enterprise#111299

Steps to produce:
---
- Install `purchase_stock` module.
- Inventory > Configuration > Settings > Warehouse > enable `Multi-Step Routes`.
- Go to Configuration > Warehouse Management > Warehouses.
- Open `YourCompany` record.
- Click on Routes > open `Buy` > enable `Products`.
- Return to `YourCompany` and disable `Buy to Resupply`.

Issue:
---
- After disabling `Buy to Resupply`, the option is automatically re-enabled.

Root cause:
---
- In [1], `buy_to_resupply` is set to true if either buy route is product selectable OR the current warehouse is included in buy route warehouses.
- In the `_inverse_buy_to_resupply` method, unchecking the flag only unlinks the warehouse from the route. However, if `product_selectable` is still enabled, the compute logic will continue to set the field back to true.

Solution:
---
- `warehouse.buy_to_resupply` is now set to True only when the warehouse ID is present in the buy route’s warehouse_ids.

[1] https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/purchase_stock/models/stock.py#L57

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

Forward-Port-Of: odoo/odoo#250360

### Issue:
When we try to print the field service report on multiple tasks, some with worksheets, then everything is duplicated in the PDF.

### Steps to reproduce:
- Install `industry_fsm` and `sale`
- Create two tasks with the same customer
- Add timesheet, products and save a worksheet on one of them (the goal is to have titles on two different pages)
- In list view select both tasks and click Report > Field Service Report
- The downloaded PDF has the report twice

### Cause:
When printing for several records then `_render_qweb_pdf_prepare_streams()` tries to split the document. If the document has more pages than the number of records [we fetch the "Outlines"](https://github.com/odoo/odoo/blob/55a58571fbfa6a6bb0edacd6f9676382cc23630b/odoo/addons/base/models/ir_actions_report.py#L938-L954). These are the biggest sections in the document. In our case these sections are the `<h2>` tags, as there are no `<h1>`: [the main title](https://github.com/odoo/enterprise/blob/6c4b88a1dfe245a63a424e3f51ff803e51ccde61/industry_fsm/report/worksheet_custom_report_templates.xml#L31-L33), [the Timesheet section title](https://github.com/odoo/enterprise/blob/6c4b88a1dfe245a63a424e3f51ff803e51ccde61/industry_fsm/report/worksheet_custom_report_templates.xml#L39), etc. Then we check the pages where these titles are displayed; if we get the same number of pages as the number of records, we use them to split the report.

If not, then we [render the report for each record individually](https://github.com/odoo/odoo/blob/55a58571fbfa6a6bb0edacd6f9676382cc23630b/odoo/addons/base/models/ir_actions_report.py#L974-L976), add them to `collected_streams`. Then add the initial report generated on the recordset and return.

These streams are later merged into one, which explains the duplication:
- Task 1 report individually generated
- Task 2 report individually generated
- Report of the recordset containing the two first reports

### Solution:
The issue was introduced by [this commit](https://github.com/odoo/odoo/commit/7fc1ebd4466a2d9b4a48dfe86332b5844026c4fc) which implements the individual generation without returning. So the individual documents will always be followed by the recordset document.

This commit adds the return directly after the individual reports generation.

opw-6032935

Forward-Port-Of: odoo/odoo#255581

Steps to reproduce:
- Enable "Expiration Dates" in Inventory settings
- Create a storable product "P1"
  - Add 10 units with "Lot 1"
- Enable expiration dates on product P1
- Add 10 units with "Lot 2" and set an expiration date
- Create a delivery for 10 units of P1
  - Mark as "To Do"
  - Open the move line

-> "Lot 1" is automatically reserved

- Change the lot from "Lot 1" to "Lot 2" -> The expiration date is not updated automatically

- Save and reopen the move line -> The expiration date is correctly set

- Change again to "Lot 1"
- Save and reopen the move line -> The expiration date is not reset and incorrectly keeps the value from "Lot 2"

Cause:
The expiration date was only computed based on `lot_id`, ignoring the
`quant_id` used during reservation. Additionally, the value was not
reset when switching to a lot without an expiration date.

Solution:
- Add `quant_id` to the compute dependencies
- Compute the expiration date based on `quant_id.lot_id`
- Explicitly set an expiration date to today when the
use_expiration_date product is set to True and the lot doesn't have an
expiration date.

Result:
The expiration date is now correctly updated and cleared when changing lots on stock move lines.

opw-5999294

Forward-Port-Of: odoo/odoo#254610

Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed.

The slowdown comes from `mrp.bom.line._get_cost_share()`, which is called for every line during a BoM explosion. When no explicit `cost_share` is set, the method recomputes the list of eligible BoM lines and checks whether any of them has a manual cost share.

That computation depends only on the BoM and the product variant, but it is recomputed for every exploded line during `mrp.bom.explode()`. This causes a full BoM scan to be repeated for every single line.

This commit introduces a contextual cache, initialized in `mrp.bom.explode()`, to store that metadata. We compute it once and reuse it for all lines of the same (BoM, variant) within the same explosion.

### Benchmark:

| BoM lines | Before PR | After PR |
| --- | ---: | ---: |
| 100 | 3.747s | 1.094s |
| 300 | 26.554s | 2.826s |
| 600 | 85.378s | 5.299s |
| 992 | 229.246s | 9.068s |

opw-6017626

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

Forward-Port-Of: odoo/odoo#255686
Forward-Port-Of: odoo/odoo#254868

Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`.

But the method is not run when the system parameter is created manually, for example through the UI, because the current conditional logic is not triggered for write and create call.

This can be an issue if for example the use submits this value: "domain1.com, domain2.com,domain3.com"

The comma seperated list will only be split by ',', meaning that the second element is " domain2.com" (space character in front). As such, that domain will not be used as expected, since most flows using that data will end up comparing "domain2.com" vs " domain2.com", and not considering it a match.

Before this fix:
Create new record in System parameters with
key = "mail.catchall.domain.allowed"
value = "domain1.com, domain2.com,domain3.com"
-> after save, value == "domain1.com, domain2.com,domain3.com"

After this fix:
-> after save, value == "domain1.com,domain2.com,domain3.com"

* fixed 19.1 FW

OPW-5505414

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

Forward-Port-Of: odoo/odoo#244279

Currently, if a user selects an exchange difference account as a write-off but then
decides to keep the invoice open, the system still fully reconciles the invoice.

Steps to reproduce:
- Create an invoice in foreign currency
- Click 'Register Payment'
- Select company currency
- Change the amount to a lower one
- Select 'Mark as fully paid'
- Add the exchange difference loss/gain account as write off account
- Select 'Keep open'
- Click 'Create payment'

Issue:
Even though the user selected the option to create a partial payment and keep
the invoice open, it is totally reconciled with a difference booked in the
selected exchange account.

Analysis:
This occurs because the use of the exchange account as write off account
trigger a specific flow used in localization where a writeoff is not allowed.
Once the payment registration process is ongoing, the system does not check
that user kept the same choice on how to handle the payment difference.

opw-5468052

Forward-Port-Of: odoo/odoo#254479
Forward-Port-Of: odoo/odoo#251965

After https://github.com/odoo/odoo/pull/240547 was merged, an issue appeared with the snippets that could also be dropped as inner content. Instead of only having the dropzones for sections, all dropzones were activated, meaning that snippets such as countdown would sometimes be dropped as inner content.

Steps to reproduce the issue:
- Go to Website
- Go to Edit mode
- From an empty website, click on the snippet group "Content"
- Select the countdown
=> The countdown was dropped in the footer instead of the main

To fix this issue, this commit restores the missing filter (removed when the new builder was added). However, since the drag and drop was updated to only display dropzones of the "active" element, there is no need to filter the dropzones within #website_cookies_bar. Finally, the filter is no longer based on the s_popup snippet, as the drag and drop mechanic was moved outside of the website module.

This commit also partially reverts the commit 5cb4f5c, since it made the tour fail with the changes of this PR (s_banner snippets can no longer be dropped inside of the s_table_of_content)

The tour testing the Countdown was updated since it did not fail prior to saas-19.2, because it was not precise enough.

Related to task-5428387

Forward-Port-Of: odoo/odoo#254724
Forward-Port-Of: odoo/odoo#250613

Steps to reproduce:
- Enable analytic distribution in Accounting settings
- Create a storable product "P1":
  - Routes: MTO + Buy
  - Vendor: add any supplier
- Create a Sale Order:
  - Add 1 unit of P1
  - Set any analytic distribution
- Confirm the Sale Order

Result:
A Purchase Order is created, but the analytic distribution is not propagated
to the purchase order line.

Problem:
When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered.
It creates and confirms the corresponding stock move with values from the
sale order line.

Since the product uses the MTO route, the procurement rule is executed.
The rule prepares procurement values from the stock move, but the analytic
distribution is not included in these values:

https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539

Later, `_run_buy` is triggered. It uses the procurement values coming from the
stock move to find an existing purchase order line candidate or to create a
new one. Because the analytic distribution is missing from the values, the
created (or matched) purchase order line does not contain the analytic
distribution:

https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113

Solution:
Propagate the analytic distribution from the sale order line through the stock
move so it can be included in the procurement values and correctly applied to
the purchase order line.

opw-5936971

Forward-Port-Of: odoo/odoo#254933
Forward-Port-Of: odoo/odoo#252292

[Issue]
1) When a POS downpayment is created, it doesn't set the account.move.lines.is_downpayment = true. So, no POS invoice line was being marked as a down payment. 2) When preparing to create the invoice lines for the sales order, it never checks the original POS Invoice lines for down payments.

[Fix]
1) When creating the invoice lines for the down payment through the POS, set the 'is_downpayment' based on if the product is the POS's down payment product. 2) Create _prepare_invoice_lin,e then filter through the POS invoice lines for downpayments and then set them accordingly.

Steps to Replicate:
1) User creates a Sales Order for a customer,
2) Transfers it to the POS, and the customer makes a down payment. 3) The user creates an invoice on the Sales order to pay the remainder of the bill 4) The account Id on the account.move.line does not match the original account on the POS invoice for the original account.move.line

Video Demo of the issue:
https://drive.google.com/file/d/1FszCJRUF-cCgg8otxu1jj1kmdKauwTGL/view?usp=drive_link

Video Demo of Solution:
https://drive.google.com/file/d/1yrYBdQZFw7YeKxsgsQQx5gHkuGER-7BN/view?usp=drive_link

Forward-Port-Of: odoo/odoo#249180