Problem: For expense created from stripe payment, OCR overwrites the data
fetched from stripe.

Solution: Skip OCR for expense created from stripe payment and put a log note
explaining the same.
***
Purpose: One language may have been set on employee, but that employee may be
using any other language in his environment, in that case user should see
chatter messages in language from his environment.

Before this commit: expense refusal message in chatter used employee's language.
After this commit: expense refusal message in chatter uses language of user
related to employee.
***
Problem: Expense Digitalization (OCR) setting is not properly applied.

Steps to reproduce:-
- Create a new database with demo data and install `hr_expense_extract`.
- Switch to `My US Company` and create an employee for that company.
- In expense settings set Expense Digitalization (OCR) to Digitize on demand
only.
- Create an expense for above created employee and attach receipt.
- Expense is digitized automatically.

Cause: Here https://github.com/odoo/enterprise/blob/d8acbf22fec266ff7d5dcc9499543e6bea3c1325/hr_expense_extract/models/hr_expense.py#L43
`self.env.company` gives that user's default company instead of currently active
company in company selector.

Solution: Use `company_id` set on expense to determine Expense Digitalization
setting.
***
task-5712223

Forward-Port-Of: odoo/enterprise#106261

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

\* = test_website_modules

### Issue:
When accessing a record from the website without logging in, a `404`
error occurs if a public record rule filters records by website related
domain, for example `[('website_id', '=', website.id)]`.

### Steps to reproduce:
- Install the 'website_blog' module and create at least one website.
- Enable debug mode.
- Go to Settings > Technical > Database Structure > Models.
- Open the `blog.post` model.
- Go to the 'Record Rules' tab.
- For the record 'Blog Post: public: published only', change the domain
  from `[('website_published', '=', True)]` to
  `[('website_id', '=', website.id)]`.
- Go to Website > Configuration > Blogs.
- Open a blog (e.g., Travel).
- Select 'My Website' in its 'Website' field.
- Open 'My Website' without logging in.
- Click on the 'Blog' menu and the blog listing will appear correctly.
- Try opening a blog post and a `404` error occurs.

### Reason:
<pre>
┌─────────────────────────────────────────────────────────┐
│                    Request Lifecycle                    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  User Request (not logged in)                           │
│       ↓                                                 │
│  ┌──────────────────────────────────────┐               │
│  │ 1. _pre_dispatch                     │               │
│  │    ↓                                 │               │
│  │    check_access_rule                 │               │
│  │    ↓                                 │               │
│  │    _eval_context (compute domain)    │               │
│  │    ↓                                 │               │
│  │    get_request_website()             │               │
│  │    ↓                                 │               │
│  │    request.website = None            │  ← Issue      │
│  │    ↓                                 │               │
│  │    Domain evaluation FAILS           │               │
│  │    ↓                                 │               │
│  │    Access DENIED → 404 Error         │               │
│  └──────────────────────────────────────┘               │
│       ↓                                                 │
│  ┌──────────────────────────────────────┐               │
│  │ 2. _frontend_pre_dispatch            │               │
│  │    (NEVER REACHED)                   │               │
│  │    ↓                                 │               │
│  │    request.website initialized ✓     │  ← Too Late   │
│  └──────────────────────────────────────┘               │
│                                                         │
└─────────────────────────────────────────────────────────┘
</pre>
Because `request.website` is initialized later in
`_frontend_pre_dispatch`, access rules evaluated earlier in
`_pre_dispatch` cannot rely on website context. As a result, record
rules depending on `website_id` are evaluated before `request.website`
is available, incorrectly denying access to public records.

### Fix:
Avoid totally relying on `get_request_website` during access rule
evaluation. Use the `request.is_frontend` attribute as a fallback, which
is set earlier, to detect frontend requests and ensure correct access
handling.

task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311)

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

Forward-Port-Of: odoo/odoo#255708
Forward-Port-Of: odoo/odoo#213143

Before this commit, the quality option would not work properly for images with a shape applied by default. After changing an option, the DOM would be updated and the slider disappeared because the image format would not be considered valid anymore.

Steps to reproduce the issue :
- Drop a snippet with an image with a shape (.s_cta_mockup, ...)
- Do one of the following:
    - Move the quality slider
    - Change an shape option
=> The Quality slider disappeared.

If the user replaces an image with a png, sets the format to "webp" and adds a shape, the dataset would have the following :
- format-mimetype: the value of the format option ("image/webp")
- mimetype-before-conversion: the original format ("image/png")
- mimetype: the mimetype of an image with shape ("image/svg+xml")

We first evaluate "data-format-mimetype", as it indicates the current format of the image (if it was changed by the user). Otherwise, we check "data-mimetype-before-conversion" since the mimetype for an image with shape is always "image/svg+xml" and doesn't correspond to the real image format. Finally, default to getMimetype to avoid issue for images on which nothing no option was changed.

task-5358952

Forward-Port-Of: odoo/odoo#240360

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

*= im_livechat, portal, test_discuss_full

**Steps to reproduce:**

• Install the mail_group module
• Open Discuss
• Go to the History tab
• Add a reaction on a message that has model `mail.group`  
• Throws an error

The error occurs because the `mail.group` model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model
does not inherit from mail.thread.
https://github.com/odoo/odoo/blob/d12c1e07727f9b04cd2be2e7dac1ec3af49cb637/addons/mail/models/mail_message.py#L579

Desired behavior after PR is merged:

This PR fixes the issue by hiding the "add reaction" button on messages with
models that don’t inherit from mail.thread, such as mail.group.

enterprise: https://github.com/odoo/enterprise/pull/111271
Task-5098050

[Reference](https://github.com/user-attachments/assets/aa2c4251-fd1f-4734-a62c-9fc80dd5f587)

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

Forward-Port-Of: odoo/odoo#255744
Forward-Port-Of: odoo/odoo#218615

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

Problem:
Sometimes pressing space in content containing a symbol pattern creates the symbol even when the space is not placed directly before it.

Cause:
`leftLeafOnlyNotBlockPath` sums the `spaceOffset` of all non-block leaf nodes, then performs a substring on the whole block containing those leafs.

In this case, the file box contains a `span` with `d-flex`, which is considered a block. Therefore, the file box text content length is not included in the `spaceOffset` calculation.

However, we later call `substring` on the `textContent` of the `closestBlock`, which includes the file box content. This leads to an incorrect `spaceOffset`, effectively skipping the file box text.

This can happen by chance when the `substring` returns the file box text content with `"-->"` immediately after it, making it the last character and triggering symbol creation.

Solution:
When computing the `substring`, consider only the `textContent` of the leaf nodes traversed while calculating `spaceOffset`. This ensures the offset matches the actual traversed content and prevents accidental symbol generation.

Steps to reproduce:
- Use the same HTML structure as in the test.
- Place the selection as in the test case.
- Press space.
- Observe that a symbol is incorrectly created.

task-6004954

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

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