Steps to reproduce:
- Install the `l10n_es_reports` module and switch to the `ES company`.
- Go to Invoices and create an invoice with taxes, then confirm it.
- Navigate to Accounting > Reporting > Tax Report.
- From the smart button, select `Report: Tax Report (Mod 390) (ES)` and 
  choose the year as `This Financial Year`.
- Download the `BOE` file using the dropdown and fill the wizard fields 
  (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345).
- Upload the generated .txt file to the AEAT portal. (AEAT credentials are required)

**Observation:**
AEAT rejects the file with:
`Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'`

**Root cause:**
At [1], when `judicial_person_procuration_date` is `false`, an empty string is 
written to the BOE file, resulting in blank spaces in the exported file. This 
does not comply with AEAT’s required numeric format and causes the file 
to be rejected.

**Fix:**
This commit ensures the file contains '00000000' when 
`judicial_person_procuration_date` is false, complying 
with AEAT numeric format requirements.

[1]:
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696

opw-5995290

Forward-Port-Of: odoo/enterprise#109652

\* = 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#213143

**Step to reproduce:**
- install "l10n_es_edi_verifactu_pos"
- setup "ePOS printer" for a pos
- open pos and settle a order below 400$
- notice we get l10n_es_edi_verifactu_qr_code in our receipt
- click on "Print receipt"
- repeat above steps for one more order

**Observation:**
- when we print the second order receipt, the QR still points to 1 order invoice

**Issue:**
- [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355
) was trimming query strings when generating cache keys. URLs like:
`  http://localhost:9000/report/barcode/?barcode_type=QR&value=... `
were reduced to:
`  http://localhost:9000/report/barcode/`

- As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders.

**Solution:**
Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly.

opw-5455807


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

Forward-Port-Of: odoo/odoo#251139

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Payroll).
- Go to Settings → Technical → Security → Groups.
- Open any group and assign an inherited view in the Views section.
- Upgrade the module.

**Issue:**
- Odoo already prevents assigning groups directly on inherited view records in
ir.ui.view. However, it is still possible to indirectly assign groups to
inherited views through res.groups via the view_access relation.

- This creates entries in ir_ui_view_group_rel and can trigger a ValidationError
during module upgrades. As a result, users may unknowingly create invalid
group-view relations, leading to errors and confusion.

**Solution:**
- Add a validation constraint on res.groups to prevent linking groups to
  inherited views via the view_access relation.

- Raise a ValidationError when such an assignment is attempted, with the message:
  "Groups should instead be defined using the 'groups' attribute inside the view XML definition."

This ensures that inherited views cannot be assigned to groups,
avoiding invalid configurations and preventing errors during module upgrades.

**opw-6015526**

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

Forward-Port-Of: odoo/odoo#255411
Forward-Port-Of: odoo/odoo#254849

Steps to reproduce:

- Create a database in saas-18.3 or above.
- Install mrp_workorder.
- Create a storable product tracked by serial number.
- Either purchase the product from a vendor (a Partners/Vendors quant with negative quantity will be generated) or confirm a Manufacturing Order (a Production quant with negative quantity will be generated).
- Create a Manufacturing Order using this product as a component.
- In the Shop Floor, scan the serial number barcode to add the component.
- Check the location of the scanned component.

Issue:
-  When scanning a barcode in the Shop Floor,  searches for a quant matching the serial number with no location filter. Because of this, it returns whichever quant has the lowest database ID — which is the Partners/Vendors quant created during the vendor receipt (quantity = -1), instead of the correct WH/Stock quant (quantity = +1).

Solution:
- To resolve this issue, a location filter ( source location) and have been added to the quant search. As a result, always returns the correct quant from the move's source location with positive stock.

opw-5974474

**Steps to reproduce:**
- Open the PoS
- Select a combo and choose whatever
- Use the numpad or keyboard to set the combo's qty to 10
- Choose another customer or preset
- The price is all wrong

**Why the fix:**
Whenever we change the customer or the preset, the **setPriceList** function is triggered. In this
function we recompute the combo's children lines' price.

Before this commit, we assumed that the combo's parent line's qty would always be one, and the logic was written on this assumption. Meaning that when it's manually changed, the data is wrong. What really happens is that most of the children line's qty end up being treated as an extra price.

This happens because in our exemple, the parent and children lines have a qty of 10, but we only set the free qty based on the assumption that the parent line has a qty of 1 on those lines https://github.com/odoo/odoo/blob/f5d5783b6a0c908127aa620ad0ec5b0008d7adf4/addons/point_of_sale/static/src/app/models/pos_order.js#L482-L485

This means that, as the free qty is rapidly depleted, we fall back on the extra products, and their unit price end up becoming the combo's base_price.

We now set the right amount in the free qty based on the parent line's qty.

When doing this, another problem arises, we have to multiply the children's unit price by the parent's qty, as theunit price's computation was based on the fact that weonly have a qty of one on the parent line.
This is because we were still basing the unit_price the the parent's lstPrice, but this price was not using the parent's qty at all, so we need to multiply it by the parent line's qty to make it work.

The unit price handling has to be done in the **computeComboItems** function, as we also need to adjust the remaining price accordingly. An access to the parent's qty was added onto the child line, to avoid adding a default parameter to the function, which should be avoided in stable if possible.


opw-5266483

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#254868

Steps to reproduce:

1. Go to the website editor (ensure developer mode is off)
2. Drag and drop a Map snippet onto the page
3. Click on the newly placed snippet and save it as a custom snippet
4. Enable developer mode and refresh the website editor
5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**.
6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above
7. Disable developer mode and refresh the website editor
8. Click one of the categories in the editor side panel to open the snippets browser
9. Click into the 'Custom' snippets category
10. Observe the error

Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case.

Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets.

opw-5933787

Forward-Port-Of: odoo/odoo#250236

**Problem:**
When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment.

**Steps to reproduce:**
1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe.
2) Change the company currency to euro.
4) Create a manual invoice for that customer.
5) Pay the invoice using the pre-configured Stripe SEPA token.
6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending".
7) When Stripe confirms the transaction, the payment stays canceled.

**Cause:**
In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled.

**Solution:**
- Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process.

opw-5934381

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

Forward-Port-Of: odoo/odoo#253876