Steps to reproduce:

- Open the website editor.
- Add a carousel snippet to a page.
- Remove content from the first slide so it is shorter.
- Save the carousel as a custom snippet.
- Open the snippet dialog and locate the custom snippet. => The preview height is too small.

Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low.

After this commit, the preview height uses the layout size so the min-height stays consistent with other slides.

----------

Steps to reproduce:
- Open the website editor.
- Open the snippet dialog and resize the window.
=> The parallax preview background shifts to the left.
- Save a snippet with a parallax zoom in/out effect as a custom snippet.
- Open the snippet dialog and locate the custom snippet.
=> The preview shows a top to bottom effect instead of zoom.

Before this commit, resizing the snippet dialog could offset the
parallax background to the left, and zoom previews looked like top to
bottom effects.

After this commit, the preview keeps the background aligned and shows
zoom in/out effects for custom snippets.

Fixed parallax is still not previewed because it would require an
oversized background in the dialog.

----------

Steps to reproduce:

- Open the website editor.
- Save a "Carousel" snippet as a custom snippet.
- Open the snippet dialog.
=> The custom snippet shows no label.

Before this commit, custom previews dropped the base label so the dialog
showed no tag for custom snippets.

After this commit, custom previews reuse the base label.

task-5156137

**To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present**

Forward-Port-Of: odoo/odoo#249163
Forward-Port-Of: odoo/odoo#244295

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

[opw-5915515](https://www.odoo.com/odoo/project.task/5915515)

----
*Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.*

Forward-Port-Of: odoo/enterprise#107677

Steps to produce:
---
- Install sales module.
- Go to Settings and enable Pricelists (make sure we have 2 pricelists
  so that we able to change the pricelist value in quotation).
- Create a new quotation > Add a customer and product.
- Change the pricelist.
- Save the record.

Issue:
---
- After saving the quotation, the `Update Prices` button becomes invisible.

Root cause:
---
- The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible.
- The field is removed from the view in this [commit].

Solution:
---
- Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable.

[commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0

**Enterprice PR:** https://github.com/odoo/enterprise/pull/107621

opw-5927659

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

Forward-Port-Of: odoo/odoo#249881
Forward-Port-Of: odoo/odoo#248957

Prior to this commit, creating a multi-action that moved a document to a
new folder and immediately triggered another action (e.g., "Create
Invoice") often failed. This occurred because the security check required
the sub-action to be explicitly embedded (pinned) on the *destination*
folder. Since the record was moved during the process, the subsequent
action failed the security check on the new folder where it wasn't pinned.

This limitation caused confusion for users setting up automation flows,
as the intent of the sequence (Move -> Action) was clear and initiated
from a valid context (the source folder), but strict per-action security
rules blocked execution.

This commit improves the `ir.actions.server` execution logic to support
this pattern by introducing a context-based security sentinel:

1. Entry Point Validation: When a Documents action (root) is triggered,
   the system enforces strict security: the action must be explicitly
   embedded on the record's current folder.
2. Context Inheritance: Once the root action is authorized and begins
   execution, it sets a secure sentinel in the context.
3. Trusted Execution: Any subsequent sub-actions (children) detect this
   sentinel and are allowed to run, regardless of the record's current
   folder location.

This ensures that if a user has the right to start the process (the root
action), they have the right to complete the defined sequence, even if
intermediate steps move the record to a folder where the sub-actions are
not explicitly pinned.

As a result, the `_can_execute_action_on_records` override in
`documents_account` is no longer necessary and has been removed.

Tests have been extended in the `documents` and `documents_account` 
modules to cover these scenarios (using Tags in the `documents`
module instead of Accounting-specific models to make the tests generic).
A new test file `test_documents_ir_actions_server.py` was created
to maintain a clean testing environment, covering nesting, move sequences,
and RPC spoofing attempts.

Task-5916630

Forward-Port-Of: odoo/enterprise#106702

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a product category hierarchy (grandparent → parent → child).
* Set an **income account** on the grandparent category.
* Set an **expense account** on the child category.
* Leave the parent category without any accounts.
* Create a product assigned to the child category.
* Create a customer invoice using this product.

**Observed behavior:**
* The invoice line uses the **default income account** from settings instead of the grandparent category’s income account.
* The category hierarchy is not checked to retrieve parent accounts.

**Expected behavior:**
* If no account is defined on a category, Odoo should traverse the **parent categories** to find one.
* Only if no account exists in the hierarchy should it fall back to journal or default accounts.

**Cause:**
* Account lookup only checked the **immediate category**.
* Parent categories were not considered.

**Fix:**
* Traverse the product category hierarchy when searching for accounts.
* Use the first account found in the parent chain.

opw-5869592

Forward-Port-Of: odoo/odoo#249909
Forward-Port-Of: odoo/odoo#248389

Steps to produce:
---
- Install `sale_renting` and `sale_management` modules.
- Go to `Sales > Products > Products`.
- Create a product and disable the Sales option (`sale_ok = False`).
- Create a Sales Order and try to add that product.

Issue:
--
- Even though the product is not sale-enabled (`sale_ok = False`), it is still selectable in the Sales Order.

Root cause:
---
- At [1], The issue occurs because `super_domain` was not always included.
- When `order_is_rental` is True, `super_domain + []` happens,
  so only `super_domain` is applied.
- But when `order_is_rental` is False, instead of
  `super_domain + [('rent_periodicity', '=', False)]`, only
  `[('rent_periodicity', '=', False)]` was returned, and
  `super_domain` was ignored.
- Because of this, base conditions from `super_domain` like
  `sale_ok = True` were not applied.

Solution:
---
- Add parentheses around the conditional expression to ensure proper evaluation order and correct domain construction, so only products with `sale_ok = True` are selectable.

[1] https://github.com/odoo/enterprise/blob/abfde5f253c4c52d3a734ca8dafe6f8ed261cf75/sale_renting/models/sale_order_line.py#L49

opw-5902403
---

Before this commit, the following discuss call test may fail non-deterministically:

```
@mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window
```

This happens at the step where it checks that when inside the discuss meeting view, having another participant enable a video stream does not auto-focus the card.

The test was failing and auto-focusing the card because the simulated toggling of enabling the video stream happens before the side-effect of rendering to toggle the flag that meeting view is on. So the handling of event that video stream is toggled on was mistakenly considering outside of meeting view.

This commit fixes the issue by awaiting a `data-active` on the UI if meeting view, which ensures the rendering of meeting view is complete and store is aware of meeting view being open, before triggering the event that simulates toggling of video stream. This technique is borrowed from `DiscussApp` component that requires a similar technique to determine whether a chat window must auto-open or not, which also requires making sure the store knows precisely when `DiscussApp` is logically open.

Fixes runbot-error-240554

In [1], a refactoring of the POS framework was done, but in the process some overlooked behaviors induced a complete loss of the answers given in the registration process, as long as they do not include an answer to a 'selection' question.

STEPS
=====

0. Create a new event with a few questions (no 'selection' one)
1. Add tickets so that you can buy one in the POS
2. Go in the POS (reload data if needed)
3. Buy a ticket and fill the attendee form (answer to all questions)
4. Continue the POS flow and pay for your ticket.
5. Go back to the back-end and event > attendees
6. Check your new attendee: no answers are linked to the record.

ISSUE
=====

TLDR - Two fields have the same comodel on event.registration. This breaks the use of inverseMap as both are loaded in the pos. As they are treated sequentially when connecting related records, hidden side effects occur when both are not set.

Details:

This effect is due to two main issues. First, after [1], we compute the whole model reference relations using processModelDefs method, that accounts for inverse relations of o2m, m2o fields and provides an inverseMap to be used in several places, notably on creation or deletion of relational records from the POS.

However, pos_event presents a peculiar situation, as registrations have two o2m fields, both loaded in _load_pos_data_fields, that are linked to the model event.registration.answer: registration_answer_ids and registration_answer_choice_ids, a subset of the first, just with a domain to only include answers of 'selection' questions.

Meaning that the inverseMap will only use one of the two, in this case registration_answer_choice_ids. In turn, this means that any update of registration_id on the answer model will update that field, even if the original update was done on registration_answer_ids...

Secondly, one could notice that this should still work, as the inverseMap is used in all places, we should just update the records through the field registration_answer_choice_ids.

So why does it not work and why are all answers removed? Because both fields are loaded in _load_pos_data_fields, and in _sanitazeRawData we use getFields to know which fields to update and to connect (for relations on the model), both being returned.

This means that independantly of the create values for the registration in addProductToOrder in pos_event, the 'framework' will still have two fields to connect and will do so sequentially, one field at the time.

But in the _connect logic, if a field has no value given at creation, then the 'CLEAR' command is used, as this would mean we remove the content of the relational field. But in this case, this means that as both answer fields try to update registration_id through registration_answer_choice_ids, if no value is given at creation in that field, then we clear existing ones, for instance those we just linked through the creation values in the first field registration_answer_ids, as we basically empty registration_id on those records. The answers will also be deleted of the indexedDB because of the condition in databaseTable (no linked registration -> can be removed)

FIX
===

Remove registration_answer_choice_ids from the loaded data, as it is not used anywhere except in the registration creation values. As it is a subset of the other field registration_answer_ids, only keep that one instead. Update the creation values to only use that field.

Note that this seems to highlight a limitation when it comes to having more than one o2m field on a model loaded at the same time in POS.

[1] odoo/odoo@a80a39f2ad16baf474553574c79d55948f86c453

Task-4919080

Forward-Port-Of: odoo/odoo#231293

__

## Short functional explanation of the error
Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours.

As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours.

## Reproduction Steps
1. Go to Planning. Click on Configuration tab > roles.
2. Create a role and add an employee as a resource This employee has to have a fixed working schedule.
3. Click on Configuration tab > Shift Templates.
4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created.
5. Click on Schedule tab > By resource and click on New.
6. Select the role you just created.

### Expected behavior
The start and end hours should align with the shift template start and end hours.

### Unexpected behavior
The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36.

## Origin of the issue
We kept computing the working intervals of employees, even if a shift template was set:
https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule.
__
opw-5898509

Forward-Port-Of: odoo/enterprise#107018

## [FIX] Accrual account domain
Since [1], the accrued order wizard can be open from a purchase order line view and from a sale order line view.
The wizard account field uses a domain, and this domain is different if the active model is `purchase.order`. In quoted PR, the domain wasn't adapted to work with `purchase.order.line` as active model.
This PR fixes that.

## [FIX] Correct COGS cost
#### How to reproduce the issue
- Use anglo-saxon config;
- Have a product with a cost;
- Sale this product with its unit price =/= its cost;
- Deliver;
- Create accrual entry for this product => The perpetual valuation lines are not correct, they use the SO lines' price for their debit/credit instead of the product's cost.

#### Example
If we have a product with cost of $100 and sell it for $180

We currently have:
Account			Debit		Credit
Stock Valuation		$ 0.00		$ 180.00
Cost of Goods Sold	$ 180.00	$ 0.00

But we should have:
Account			Debit		Credit
Stock Valuation		$ 0.00		$ 100.00
Cost of Goods Sold	$ 100.00	$ 0.00

## PO line price diff
#### Issue
While generating accrual entries for a PO with billed not received, if the billed price is different than the PO line price, no entries were generated for the price diff account.

#### How to reproduce
1. Create a product using "Standard Price" as its costing method and set a cost for this product and set a price  difference account (on its product category);
2. Create a purchase order for this product and confirm it;
3. Create an invoice for this PO with a different price for the product;
4. Go to Accounting > Review > Billed Not Received;
5. Select the PO and click on "Create Accrual Entries" button => Accrued entries are created but no entries are created for the price difference.

#### Expected behavior
Two more entries must be created: one for the price diff account and one for the stock valuation account.

[1]: https://github.com/odoo/odoo/pull/231510

task-[5349657](https://www.odoo.com/odoo/966/tasks/5349657)

Forward-Port-Of: odoo/odoo#234600

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a product category hierarchy (grandparent → parent → child).
* Set an **income account** on the grandparent category.
* Set an **expense account** on the child category.
* Leave the parent category without any accounts.
* Create a product assigned to the child category.
* Create a customer invoice using this product.

**Observed behavior:**
* The invoice line uses the **default income account** from settings instead of the grandparent category’s income account.
* The category hierarchy is not checked to retrieve parent accounts.

**Expected behavior:**
* If no account is defined on a category, Odoo should traverse the **parent categories** to find one.
* Only if no account exists in the hierarchy should it fall back to journal or default accounts.

**Cause:**
* Account lookup only checked the **immediate category**.
* Parent categories were not considered.

**Fix:**
* Traverse the product category hierarchy when searching for accounts.
* Use the first account found in the parent chain.

opw-5869592

Forward-Port-Of: odoo/odoo#249909
Forward-Port-Of: odoo/odoo#248389

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a product category hierarchy (grandparent → parent → child).
* Set an **income account** on the grandparent category.
* Set an **expense account** on the child category.
* Leave the parent category without any accounts.
* Create a product assigned to the child category.
* Create a customer invoice using this product.

**Observed behavior:**
* The invoice line uses the **default income account** from settings instead of the grandparent category’s income account.
* The category hierarchy is not checked to retrieve parent accounts.

**Expected behavior:**
* If no account is defined on a category, Odoo should traverse the **parent categories** to find one.
* Only if no account exists in the hierarchy should it fall back to journal or default accounts.

**Cause:**
* Account lookup only checked the **immediate category**.
* Parent categories were not considered.

**Fix:**
* Traverse the product category hierarchy when searching for accounts.
* Use the first account found in the parent chain.

opw-5869592

Forward-Port-Of: odoo/odoo#249909
Forward-Port-Of: odoo/odoo#248389

Steps to reproduce
------------------
1. Install `pos_settle_due`
2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc).
3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0
4. Select the invoice(s)
5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom.

-> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method.

Why the issue
-------------
If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created.

That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions.

After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places:
1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation.
2. On the products screen, when using fast payment, that is fast validation.

For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation.

However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation.

The fix
-------
Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation.

Notes
-----
- We keep the methods in `payment_screen` for backward compatibility, they will be removed in master.
- We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so  it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`.

opw-5488587

**Steps to reproduce:**
- create a storable avco automated product
- in the purchase tab, select control policy : "on invoice quantitites"
- create and confirm a purchase order for 100 qty at 1 unit price
- on the picking, unhide the description column
- change the description for the move
- go back to the purchase order and change the quantity to 105
- (because we changed the description, the new move created 
with a quantity of 5 is not merged to the existing one of 100 and 
we now have two moves on the picking)
- create and confirm the bill
- validate the picking
- select the valuation smart button

**Current behavior:**
the svl with a quantity of 100 has a total value of 105
the svl with a quantity of 5 has a total value of 105

**Expected behavior:**
the svl with a quantity of 100 should have a value of 100
the svl with a quanitty of 5 shoul have a total value of 5

**Cause of the issue:**
When the picking is validated, action_done is created on the 
two moves. 
In the stock_account override: 
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 105.
- then product_price_update_before_done is called on the two 
moves before creating the svls.
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/stock_account/models/stock_move.py#L352

Inside product_price_update_before_done, for each move, 
we call _get_price_unit.
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/stock_account/models/stock_move.py#L426

For the first move, in the purchase_stock override 
of _get_price_unit : 
- to get the received qty we call _get_qty_received_without_self()
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L50
and because the super method of action_done was already called, 
qty_received of the purchase order line is 105, so _get_qty_received_without_self
will return 5. 
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L108-L113
So received_qty is 5 and later remaining_qty will be 100
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later 
remaining_value will be 105
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L60
Therefore price_unit will be 1.05 (105/100) instead of 1
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L95

For the second move, the problem is the same and 
the price unit ends up being 21 (105/5)

**fix**
We do not take into account the move(s) for the same product
of the same picking in the remaining value (because svls are not created yet)
so we should not take them into account in the remaining quantity.

the problem is very similar to https://github.com/odoo/odoo/pull/235601
In this other PR it happend because we had multiple move for 
the same product because they were in a batch, and in this PR we 
have the issue because we have multiple move for the same product 
because they didn't merge due to the description difference. 

opw-5429501

Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.

### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B). 
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.

### **Current/Buggy Behavior:**
The contact does not appear in the search results.

### **Expected Behavior:**
The contact should be selectable.

### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.

However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].

This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.

### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.

[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896

**opw-5484611**

Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong.

**Steps to produce:**
* Install `hr` with demo data
* Modify the view `report_employee_cv`  by adding `<div t-if=o.no/>`
* Print resume of any employee

**Observed Behavior:**
Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" />

**After:**
<img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related: https://github.com/odoo/enterprise/pull/100142

opw-5167898

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898