Currently when the user creates an invoice the delivery date is set incorrectly.

<h2>Steps to produce:</h2>

* Set system timezone to Asia/Kolkata and time to 5:00
* Install Sales, Inventory
* Create and confirm a sale order
* Go to Delivery and Validate the delivery
* Go back to the Sale order and create an invoice.


<h2>Observed Behavior:</h2>
The delivery date on the customer invoice is set to one day before the current date, even though the effective date for the delivery correctly reflects the system date and time.

<h2>Root cause:</h2>

This issue occurs because, when a delivery is validated, the `date_done` field is set using the current time in UTC at [1], because odoo operates in UTC by default. This value is then used to compute the effective date on the
sales order at [2], which in turn is used to determine the delivery date on the invoice at [3] and [4].

Users see the effective date on the delivery in their own timezone because `Datetime` fields are converted from UTC to the user’s timezone on the client side as stated in [5]. However problem arises from a type mismatch. The delivery date field is of type `Date`, while the effective date is a `Datetime`. As a result, when the value is assigned at [3] or at [4], only the date portion is passed.

Because a Date field does not carry any timezone information, no timezone conversion occurs, leading to the observed discrepancy.

[1]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/stock/models/stock_picking.py#L1274
[2]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L87-L88
[3]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/account_move.py#L122
[4]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L301
[5]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/odoo/orm/fields_temporal.py#L214-L217

## **Solution:**
Using the `context_timestamp` function makes it possible to work with the `Datetime` in the client’s timezone, which can then be used to correctly assign the delivery date on the invoice.


opw-5391189

Forward-Port-Of: odoo/odoo#255404
Forward-Port-Of: odoo/odoo#247122

An error is raised when we try to acces the inventory valuation if a move has been returned and the quantity set on the original move is changed to 0

Steps to reproduce:
1. Install Accounting and Inventory
2. Create a product called "Product" and set the Category to "Goods"
3. Go to Inventory > Configuration > Categories, open category "Goods" and change the costing method to "Average Cost (AVCO)"
4. Go to Inventory > Operations > Deliveries and create a new delivery for any customer with one of product "Product"
5. Validate the delivery, click on "Return" then on "Return All"
6. Validate the return
7. Go back to the original delivery and in Actions, click on "Lock/Unlock"
8. Set the quantity to 0 and save
9. Go to Accounting > Review > Inventory valuation
10. Change the day to any day after today
11. An error is raised

Issue:
Trying to get the inventory valuation at another day then today will replay the history
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/stock_account/models/product.py#L444-L450
Which will call `_get_value()` on the moves related to the product
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/stock_account/models/stock_move.py#L388-L391
A ZeroDivisionError will then be raised when trying to get the value of a return move and the original move's quantity is 0
https://github.com/odoo/odoo/blob/873d4d262ed3e85362aa677b5a782d6e7fa00f09/addons/stock_account/models/stock_move.py#L457

Solution:
If the original move's quantity is 0, set the value to 0
This ensures the move is valued at 0 if the move has no quantity. In other words, a move that has no quantity shouldn't be considered to have any value as there really is nothing to value.

opw-5980600

Forward-Port-Of: odoo/odoo#253392

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Additionally, `_get_localized_times` called `.astimezone()` on naive UTC datetimes without first localizing them, producing incorrect local times for the same reason.

Solution:
- In `_get_overtimes_to_update_domain`, localize check_in/check_out to the employee's timezone before computing the overtime search date range (with a ±1 day buffer) so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.
- Fix `_get_localized_times` to call `utc.localize()` on naive UTC datetimes before converting to the employee's timezone.

opw-5931665

Forward-Port-Of: odoo/odoo#254543
Forward-Port-Of: odoo/odoo#251812

Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies with standard `btn`.

This commit fixes that by providing the contrast-adjusted color only on default palettes, and use the manual color as is when selected in the Theme tab.

task-5392258

| State | Before | After |
|--------|--------|--------|
| Normal | <img width="261" height="122" alt="image" src="https://github.com/user-attachments/assets/482ed97f-303c-4332-a748-1130a9ee5db7" /> | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/5e0b14ba-677a-480e-8aad-85c13f3a5f6e" /> | 
| Hover | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/87cec4fc-521c-4b36-84d3-81460cefa68c" /> | <img width="259" height="123" alt="image" src="https://github.com/user-attachments/assets/b17c309d-2b64-4dc2-a33b-e576831647e0" /> | 

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

Forward-Port-Of: odoo/odoo#239584

Purpose
=======
Fix the "This question requires an answer" alert which is displayed under the question even if it's the first time the user sees it.

Specification
=============
Following odoo/odoo#215237 conditional questions can now be displayed in the post-submit flow. The purpose was to give the user the chance to see and answer the conditional questions that are triggered by a mandatory question that was skipped.

However the condition to display this error alert was only relying on the fact that the question was considered post-submit or not. But now that the post-submit questions also includes the conditional questions that are waiting for answer, this condition is not enough anymore.

Making the condition more precise to be sure that the error is displayed only if the questions is considered post-submit AND it's already the post-submit flow or it's the pre-submit flow and the question was effectively skipped by the user.

Task-6048598


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

Forward-Port-Of: odoo/odoo#254848

### Steps to reproduce:

- Impersonate a user with only Inventory user access rights
- Inventory > Operations > Adjustments> Physical Inventory
- Select any quant in the list > Print > Count Sheet
#### > Access Error: You are not allowed to access 'System Parameter' (ir.config_parameter) records.

### Cause of the issue:

The template of the count sheet relies on the `get_param` methods of the `ir.config_parameter` model which requires read access rights on the model:
https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/addons/stock/report/report_stockinventory.xml#L36-L39 https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/models/ir_config_parameter.py#L59-L69 This access right is limited to the the `base.group_system` (admin) user group:
https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/security/ir.model.access.csv#L118

opw-5959200

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

Forward-Port-Of: odoo/odoo#254294
Forward-Port-Of: odoo/odoo#253251

# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component

*Component Product*
- Storable
- Tracked By Lot

# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"

# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned

# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.

This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.

In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
            moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
            if moves_to_update:
                moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```

This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
    def _compute_picked(self):
        for move in self:
            if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
                move.picked = True
            else:
                move.picked = False
```

If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.

opw-5937171

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

Forward-Port-Of: odoo/odoo#253607

PR #212726 removed a Many2One field and used an existing binary field, `l10n_it_edi_attachment_file`, to store E-invoice files as XMLs. This change was made for security reasons.

However, this PR also stores attachments embedded in the `<Allegati>` element of the XML in this same field. This results in three issues when importing invoices from the SDI:

1. The first embedded attachment will overwrite the XML file's contents, corrupting it.
2. Subsequent embedded attachments will continue to overwrite the previous attachment.
3. All embedded attachments are linked to the `account.move` record by the Many2one field `attachment_ids`, which is contrary to the stated goal of PR #212726.

These behaviors cannot be replicated in a runbot environment, as there is no way to test the SDI import process in runbot at the time of writing.

Localhost environments can replicate this issue by receiving an XML from the test l10n_it API server, or by passing similarly encrypted data to the method `_l10n_it_edi_process_downloads()`. See the method `test_decrypt_invoice_from_IAP()` from PR #250439 for an example of the encryption process.

**Solution**: Do not overwrite the field `l10n_it_edi_attachment_file`. Add stored field(s) to master for attachment(s) within an XML's `<<Allegati>` element.

This PR also improves how Allegati attachments are named, as my previous PR #246220 could result in files with two extensions (e.g. "filename.txt.TXT").

Ticket [link](https://www.odoo.com/odoo/project.task/5800658)
opw-5800658

Forward-Port-Of: odoo/odoo#252806

# How to reproduce
- Have atleast one product published on the website. The more products published, the more noticable the issue is
- Edit the website
- Add a table block to a page (Search for table in the "Insert block" popup and pick the first one)
- Add a catalog block to the table. This catalog block needs to be the one with the title "Our latest content".
- Add any other block in the table block to update the table of content

# The problem
The table of contents display the names of the different products. If there are a lot of products, it fills the whole table of content

# Why
The TableOfContentPlugin scans for ```<h2>``` tags to use them in the table of content.
```js
updateTableOfContentNavbar(tableOfContentMain) {
        const tableOfContent = tableOfContentMain.closest(".s_table_of_content");
        const tableOfContentNavbar = tableOfContent.querySelector(".s_table_of_content_navbar");
        const currentNavbarItems = [...tableOfContentNavbar.children].map((el) => ({
            title: el.textContent,
            href: el.getAttribute("href"),
        }));

        if (tableOfContentMain.children.length === 0) {
            // Remove the table of content if empty content.
            this.dependencies.remove.removeElement(tableOfContent);
            return;
        }

        const targetedElements = "h1, h2";
        const currentHeadingItems = [...tableOfContentMain.querySelectorAll(targetedElements)]
            .filter((el) => !el.closest(".o_snippet_desktop_invisible"))
            .map((el) => ({ title: el.textContent, id: `#${el.id}`, el }));
```

The product snippet template uses ```<h2>``` for their product title dispite having the h6 CSS class.

Note that the reason you need to add another block to the table to see the issue is that the table of content is updated before the products are loaded in the catalog.

opw-5992937

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

Forward-Port-Of: odoo/odoo#253002

To compute the inventory valuation report, stock_account builds a valuation context through `_with_valuation_context()` and passes the valued internal/transit locations to stock quantity computation.

Without `strict=True`, stock quantity domains treat these locations as hierarchical anchors and expand them again through the location tree. This is redundant in this specific call site because `_with_valuation_context()` already provides the valued locations to filter on.

On databases with a large location tree, this extra expansion makes the inventory valuation load much slower than necessary.

Using `strict=True` makes quantity computation use the provided valued locations directly.

### Benchmark:
- active products: 5912
- stock moves: ~785k
- internal locations: 4213

| Before  | After  |
|---------|--------|
| 99.285s | 1.853s |

opw-5944584

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

Forward-Port-Of: odoo/odoo#253656

# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component

*Component Product*
- Storable
- Tracked By Lot

# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"

# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned

# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.

This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.

In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
            moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
            if moves_to_update:
                moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```

This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
    def _compute_picked(self):
        for move in self:
            if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
                move.picked = True
            else:
                move.picked = False
```

If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.

opw-5937171

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

Forward-Port-Of: odoo/odoo#253607

### Steps to reproduce:

- Create a product that is not track inventory (`is_storable = False`)
- Set its cost to 50$ and put it in an avco perpetual valuation category
- Create and receive a purchase order for 10 units
- Set the product as track inventory (`is_storable = True`)
- Inventory > Reporting > Stock
- Click on the `unit cost` of your product line
#### > This opens the `stock.avco.report` according to which the total value of your stock is 500$ and the total quantity is 10 units even though do not have any unit in stock.

### Expected behavior:

The line of the receipt should have been counter balanced by an inventory adjustment line to resets the valuation at the same time as the product has been set to `is_storable`

### Cause of the issue:

There is currently no mechanism to counter balance the stock that should have been present in internal locations if the moves done had been processed with a storable product.

opw-5472902

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

Forward-Port-Of: odoo/odoo#254380

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/5416006

Issue:
If a database has products that use the average cost method, and those products have millions of stock moves, a memory error can occur when the inventory valuation report is opened.

Explanation:
When the inventory valuation report is opened, the `_run_average_batch` method is invoked on batches of up to 1000 AVCO products at a time. Previously, all matching stock moves for those products were fetched in a single query and kept in cache for the duration of the computation. For large databases, even a single invocation of `_run_average_batch` can exhaust available memory if the products involved have enough stock moves.

Solution:
Moves are now fetched and processed in batches of 50,000 records, with the cache for `stock.move` and `stock.move.line` invalidated between each batch.

For memory:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 280 MB | 274 MB |
| 500 products with 535,250 moves | 983 MB | 301 MB |
| 500 products with 912,405 moves | 1.7 GB | 337 MB |
| 1000 products with 1,447,655 moves | Mem error | 393 MB |

For speed (in m:ss):
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 0:15 | 0:16 |
| 500 products with 535,250 moves | 1:12 | 1:17 |
| 500 products with 912,405 moves | 2:02 | 2:10 |
| 1000 products with 1,447,655 moves | N/A | 3:53 |

opw-5416006

Co-authored by Cooper Spinelli (spco)

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

Forward-Port-Of: odoo/odoo#250526

*: website_blog, website_event, website_sale

The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-5427353

Forward-Port-Of: odoo/odoo#253985
Forward-Port-Of: odoo/odoo#246328

**Issue**:
Choosing a PO among several alternative POs resets the price of all the unselected ones.

**Steps to reproduce**:
- Create a storable product with a standard price of 1
- Add two vendors for a quantity of 1 with a unit price 1.1 and 1.2
- Create a PO for one vendor with 10 units at price 1.3
- Create an alternative PO for the other vendor with 10 units at price 1.4
- Compare the POs and choose the first one
-> The unit price of the second one (1.4) is reset to the standard price (1)

**Cause**:
When choosing a PO, the quantities of alternative POs are reset to 0:
https://github.com/odoo/odoo/blob/1b5072c0e0af6be340389e0c429ca370d8dc169d/addons/purchase_requisition/models/purchase.py#L317-L321
https://github.com/odoo/odoo/blob/1b5072c0e0af6be340389e0c429ca370d8dc169d/addons/purchase_requisition/models/purchase.py#L304
which will trigger the `_compute_price_unit_and_date_planned_and_name`.
Since the quantity no longer matches any vendor, no seller is found (10 on the pol and 1 in vendor):
https://github.com/odoo/odoo/blob/f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1/addons/purchase/models/purchase.py#L1198-L1203
but `unavailable_seller` is found, since the quantity is not in the search
https://github.com/odoo/odoo/blob/f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1/addons/purchase/models/purchase.py#L1210-L1215
As a result, the price is recomputed using `standard_price`:
https://github.com/odoo/odoo/blob/f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1/addons/purchase/models/purchase.py#L1218

**Solution**
Cancel unselected alternative POs instead of resetting their quantities to 0.
This avoids triggering `_compute_price_unit_and_date_planned_and_name` and preserves original prices.

opw-[6022718](https://www.odoo.com/web#id=6022718&view_type=form&model=project.task)

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

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

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

**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