# How to reproduce
- Have a lot of reusable & locationless packages (e.g. > 10 000)
- Go to any transfer via the barcode application

# The issue
There is a very long loading time, even in local testing. The client of the tickets experiences loadings up to 120 seconds with 50k packages

# Cause
When opening a transfer, we load barcode data by doing an API call to `_get_stock_barcode_data` : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L85

During this we preload a lot of records, notably packages : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L128

The issue is that in the fields we read for the packages, two of them (`location_dest_id` & `contained_quant_ids`) have a `_read_group` in their compute (or in the compute of one of the fields they depend on) :
https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L65 https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L146

Fortunately, this does not mean that we make a query for every records. Instead, in Odoo, we fetch records in batch of 1000.

So, for the case of the client, every time he loads the database, the backend does 50 000 / 1000 x 2 = 100 queries, which hinders performance a lot

A [PERF] commit was done to limit the number of packages that are fetched base on a config parameter. The problem is that this parameter does not have a default value, so clients still end up with the problem.

[PERF]: https://github.com/odoo/enterprise/commit/efe18bc1ea479270e42846986d7ed449b0865617

# Proposed Solution
Add a default value for that config parameter. The exact value is up to discussion

opw-6200730

Forward-Port-Of: odoo/enterprise#124538
Forward-Port-Of: odoo/enterprise#123696

Steps to reproduce:
- Set the user language to Dutch.
- Go to Accounting > Reporting > Annual Statements.
- Generate the XBRL export for a report other than the "company,
  abridged" (acon) balance sheet/P&L combination, e.g. an association
  (asso_a/asso_f) or "company, full"/"company, capital" report.
- Open the file: the `<met:bln1>` boolean facts are exported as
  "onwaar" instead of "false", which is not a valid XBRL boolean
  lexical value and gets rejected by the NBB validator.

Cause of the issue:
QWeb templates translate static text nodes by default. The base
module ships a generic `msgid "false" -> msgstr "onwaar"` translation,
used elsewhere in the UI, which silently hijacks the literal
"false"/"true" and unit tokens ("iso4217:EUR", "pure") in the XBRL
data templates whenever the file is generated in Dutch.

Solution:
Add `t-translation="off"` on the `<met:bln1>` boolean facts and the
`<measure>` unit tokens in the 5 remaining XBRL templates,
so these fixed-vocabulary XBRL values are never subject to translation

opw-6395785

Forward-Port-Of: odoo/enterprise#124945

Steps to reproduce
---
1. Enable Packages and turn on "Move Entire Packages" on the delivery operation type.
2. Create a storable product P and add 2 units in different package in stock: 1 in PACK001, 1 in PACK002 
3. In the Barcode app > Operations > Delivery > New
4. Scan a first package PACK001, then a second different package PACK002
5. Scan the first package PACK001 again.

Issue
---
Re-scanning an already scanned package is meant to be rejected with a "This package is already scanned." warning, but the rejection stops working as soon as a second package is present in the transfer, so the package content gets added a second time and, once validated, the source quant goes negative (the package ends up holding a negative and a positive quant of the same product).

Commit 23613c63947 added a canPackSomeLines flag that is set to true for every package line that is not the scanned one, so any other package in the transfer makes the alreadyDonePackId && !canPackSomeLines guard false and silently skips the warning. The scanned package already exposes whether it had something left to pack through scannedPackages, so gating the warning on that flag instead keeps the check working regardless of how many other packages are in the transfer.

https://github.com/odoo/enterprise/blob/3cc1a162e61662814b0e52c0c720831952d208a8/stock_barcode/static/src/models/barcode_picking_model.js#L1976-L2006

opw-6279105

Forward-Port-Of: odoo/enterprise#121755

To reproduce the issue:

1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January
3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock date exception removing the tax lock date just for you, for 5 min. 5) Reset January's return
6) Reopen the lock date wizard.
    ====> Your exception is still there, but the tax lock date for everyone has been reset to December 31st.

This is plain wrong. Resetting a return should not automatically reopen the period for everyone. Lock dates exceptions/modifications are anyway required to reset the return ; they should pilot the whole flow. Nothing being magically hidden from the user means there can't be someone else mistakenly encoding something into the reopened period.

Another fix was required to make this one work: setting the tax lock date before submitting the return should work. In bigger environments, users might want to do that as a first step to reduce the number of people encoding data before actually doing the submission of the return. Therefore, the case where the tax lock date is already set at the date_to of the return when submitting it was supposed to be already supported, and allow the creation of the closing entry for that return, despite it being on the tax lock date. The test ensuring this was however badly written, and the feature didn't work: the closing was created at a later date than the lock date automatically, due to the Bills' Algorithm.

Forward-Port-Of: odoo/enterprise#124872
Forward-Port-Of: odoo/enterprise#124811

`pos_amount_unsettled` is a stored computed field defined as the invoice's residual minus the settle lines belonging to sessions that are not yet closed. Its compute method filters the lines on `order_id.session_id.state`, but that state is not in the compute dependencies.

When closing a session holding a settle order, `_validate_session()` first reconciles the settle payment with the invoice (which lowers `amount_residual_signed` and flags the field for recomputation) and only then writes `state = 'closed'` on the session. If the pending recomputation is executed in that window (any flush of `account.move` does it: recomputing the field for any other flagged record drags the whole queue along), the settle line is deducted from the already reconciled residual, i.e. counted twice, and the field is stored as `residual - settled` instead of `residual`. Since the session state is not a dependency, writing `state = 'closed'` does not flag the field again and the wrong value is never corrected.

The partner's `invoices_amount_due` then goes negative, which hides the "Settle invoices" option in the POS partner list and inflates the "Settle due amount" proposal
(`remainingDue = total_due - pos_orders_amount_due - invoices_amount_due`): a customer owing e.g. 500 is proposed, and charged, 700.

Steps to reproduce:
1. Post a customer invoice of 1000.
2. In the POS, select the customer > Settle invoices, pick the invoice, set the amount to 700 and pay in cash.
3. Close the session. The issue only occurs when the pending recomputation runs during the closing, which depends on the other operations performed by it (not deterministic in real usage; the regression test forces it with a flush after the reconciliation).
4. The invoice's "Amount To Pay In POS" shows -400 instead of 300 and the POS proposes to settle 700 instead of 300.

Add the session state to the compute dependencies so that the field is recomputed once the session is closed, yielding the correct amount regardless of any intermediate recomputation.

opw-6375095

Forward-Port-Of: odoo/enterprise#123783

**Steps to reproduce:**
1. Create a Sales Order.
2. Create a 50% down payment invoice.
3. Create a credit note for the down payment invoice.
4. Reset the credit note to Draft and cancel it.
5. Create the final invoice from the Sales Order.

**Issue:**
The final invoice is generated for 100% of the order amount, acting as if the down payment invoice does not exist.

**Expected behavior:**
The final invoice should only include the remaining 50% of the order amount because a valid 50% down payment invoice still exists.

**Why this happens:**
- The `price_unit` on the Sales Order's down payment line is manually updated during `action_post()` based on the sum of posted invoices minus posted credit notes.
- When the credit note is posted, `price_unit` drops to 0. However, when that credit note is subsequently reset to draft and cancelled, it triggers `button_cancel()` which only refreshed the line's display name and failed to recalculate `price_unit`. As a result, `price_unit` remained at 0 even though the credit note was no longer active, causing the final invoice to deduct nothing.

opw-6373578

Forward-Port-Of: odoo/odoo#277043
Forward-Port-Of: odoo/odoo#275684

Steps to reproduce:
- Install Argentina(l10n_ar) localization > Change Company
- Accounting > Customers > Invoices > Select an invoice > Click "Pay"
- In "Journal" select "Third Party Checks" > In "Payment Method" select "New Third Party Checks" > Fill the rest of the check info (Number, Bank Account, Issuer Vat, Payment Date and Amount) > Click on "Create Payment"
- Repeat the payment process for another invoice with same info > Validation Error

A change in [PR] caused the check uniqueness constraint apply to all checks. Because of this, using the same check number with the "New Third Party Checks" payment method now raises a validation error.

This is not the intended behavior. The uniqueness constraint should only apply to "Own Checks" when using a "Bank" journal for Vendor Bills. It should not apply to "Third Party Checks" with the "New Third Party Checks" payment method in Customer Invoice.

Avoid linking `l10n_latam_check_ids` on liquidity lines for outbound "Own Checks" payments so that the uniqueness constraint is enforced only for the "Vendor Bills".

[PR]: https://github.com/odoo/odoo/pull/243509/changes

opw-6334965

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

**Steps to reproduce:**
Both problem are reproducible on runbot aswell 
but for more clarity (and for empty accounting), 
those steps are on a fresh db with no demo data

Problem 1 : 
- create a new db with stock_account, purchase 
and accountant
- In the companies view, select your company
- in the branch tab, create a branch for your company
- for both the branch and the company, in the settings 
set the valuation as periodic daily

With only the branch company selected:
- create a warehouse for your branch
- create a storable prod with a cost of 10
- validate a receipt for 1 unit of the prod
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'

With the main company selected: 
- Open journal items
- click on the journal entry of  any of the move line 
with label 'closing stock variation global for 
company [branch]'
- select the 'other info' tab


Problem 2: 
- create a new db with stock_account, purchase 
and accountant
- create a company 2 
- for both companies, in the settings 
set the valuation as periodic daily

With company 2 selected
- create a warehouse for company 2
- in the settings for fiscal localization set the 
'generic chart of account'
- create a storable product with a cost of 10
- validate a receipt for 1 quantity of the product
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'


**Current behavior:**
Problem 1: 
the company of the account move 
is the main company

Problem 2: 
There is a traceback including 
'UserError: Everything is correctly closed'

**Expected behavior:**
Problem 1: 
It should be the branch company

Problem 2: 
Everything is closed in company 1, but 
it shouldn't prevent to generate the entries
for company 2

**Cause of the issue:**
Problem 1: 
Inside _cron_post_stock_valuation
we call action_close_stock_valuation for each company
(if periodic daily or periodic monthly and we're the last 
day of the month)
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L143-L144

Inside action_close_stock_valuation when creating 
the account move we add a context to be sure that 
the move is created for the main company selected 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L72
The fix comes from this PR 
https://github.com/odoo/odoo/pull/263828
and was improved starting from 19.1 
to simply add a the company_id on the moves_vals.

But the problem is that this fix failed to consider 
the case where we come from cron because 
in this case self.env.company is the main company 
of the user, which is a problem because  as we iterate 
through the companies we want each account 
move to be created for its own company.
This other PR https://github.com/odoo/odoo/pull/269152 corrects
this by using self.id instead of self.company.id
but only starting from 19.1.

The fix is essentially a back port of those 2 PR.

Problem 2: 
When you call action_close_stock_valuation from 
_cron_post_stock_valuation for the company 
that has no inventory valuation and thus no 
account move to create we will raise the user
error 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L58-L60
This makes sense if the method was called 
from the inventory valuation view. 
But in our case it's called from cron so we might 
also call it on other companies and therefore we 
don't want to raise an exception if there is no 
account move to create on one of the companies.

opw-6144294

Forward-Port-Of: odoo/odoo#276771
Forward-Port-Of: odoo/odoo#275294

Issue:
When a shopper pays for an online order entirely using a reward (e.g. a discount code covering 100% of the total), the order total is zero. With automatic invoicing enabled, an invoice with an amount of 0 is created. But, the 0 invoice is never emailed to the customer. Whereas, for orders where the total is more than 0, an invoice is created, then emailed to the customer. The customer should be emailed the invoice, even if its amount is 0.

Steps to reproduce:
1. Enable automatic invoicing.
2. Create a code for a 100% discount.
3. As a shopper, add a product to cart on the website.
4. While checking out, apply the 100% discount code to the order.
5. Complete the checkout.
6. Confirm that an invoice was created and posted, but was not emailed to the customer.

Explanation:
Normally, order confirmation and invoicing are handled by the `_post_process` method on the `payment.transaction` model. With automatic invoicing enabled, `_post_process` confirms the sale order, creates the invoice, and sends the invoice via `_send_invoice` (another method on the `payment.transaction` model). If `sale.async_emails` is enabled, `_post_process` will trigger a cron that invokes `_send_invoice` instead of invoking it directly.

When an order is fully covered by a reward, there's nothing to pay. In this case, no payment.transaction record is ever created, and `_post_process` never runs. Instead, the order is confirmed through the `_validate_order` method on the `sale.order` model. The `sale_loyalty` module extends `_validate_order` so that, with automatic invoicing enabled, it will create and post an invoice for zero-amount orders. But, nothing in this path ever calls `_send_invoice` or an equivalent. So, the invoice is created and posted but never sent.

Solution:
This adds logic for sending invoices to the extension of `_validate_order` in the `sale_loyalty` module. We mirror the logic used in `_send_invoice` in the `payment.transaction` model.

Notes:
There is duplicated code from `_send_invoice` in this fix. That is because `_send_invoice`, a method on the `payment.transaction` model, can't be used in this flow. A fix that avoids code duplication would require serious refactoring.

This will never trigger a cron to send the invoice, even if `sale.async_emails` is enabled. That is because the cron invokes `_send_invoice`. Since fully reward-covered orders are probably not common, any performance benefits of using a cron are probably not significant. But, making a new cron to be used in this case is also an option.

opw-6363334

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

Forward-Port-Of: odoo/odoo#275750
Forward-Port-Of: odoo/odoo#275190

# Step to reproduce
- Install eCommerce
- Activate dev mode with tests assets (important!)
- Go to the website & add a Countdow in the footer
- Add a new product from the website system tray
- Put any name & Save
- Go into Edit mode
- In the Style tab, (un)toggle "Tax Indication" (may need to do it multiple times)

> Note that the issue is quite inconsistent to reproduce
# Issue
A traceback is shown

# Cause
The only thing I'm sure of is that the error is caused by this code :
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/website/static/tests/tour_utils/lifecycle_dep_interaction.js#L18-L20

And that it is linked to `browser.localStorage`. I suspect it is due to some weird localStorage and
WysiwygAdapter interaction :
https://github.com/odoo/odoo/blob/d6a08b67a948f569a1ca893b6337ce50b4ef9f07/addons/website/static/tests/tours/widget_lifecycle.js#L53-L60

But I can't be sure because debugging tools do not seem to be working. See the inverstigation comment
in the associated PR for more information.

# Proposed Solution
Since this code is only used for this test :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L14-L15

And the test directly parses from the `window.localStorage` :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L50

We can use `window.localStorage` instead of `browser.localStorage`  as it fixes the issue

opw-6246850

Forward-Port-Of: odoo/odoo#272736

The translate button next to a translatable field saves the record before opening the translation dialog for its id. Since https://github.com/odoo/odoo/commit/a85ca9679e3855936afc66b034d05d75f672dd26 it saves record.model.root rather than the record itself. When the field belongs to a new record still edited inside an x2many, for example an answer added in the survey question popup, saving the root only saves the parent and the new line keeps no database id. The dialog then opens with the id set to false and calls update_field_translations on it, which builds WHERE id = false and the database rejects it with operator does not exist: integer = boolean.

Such a record gets no id of its own, and after a save and reload there is no reliable way to match the saved line back to the one that was clicked, so the dialog can never open for it. A canTranslate getter in TranslationButton returns false for a new record whose model root is another record, which is exactly a line still edited inside an x2many, and the template only renders the button when it is true. The variant in editable lists, where model.root is a list rather than a record, was handled in https://github.com/odoo/odoo/commit/cb34b318004c3ca9db755d8dbbad429609220df3.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app and create a survey
3. Add a question, then in the Answers tab add a line and type a value
4. Click the EN button next to the answer, fill the second language, and Save

=> RPC error operator does not exist: integer = boolean from WHERE id = false

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

Forward-Port-Of: odoo/odoo#270635
Forward-Port-Of: odoo/odoo#267781

**Steps to reproduce:**

- Create an attribute of type always, 2 values A and B for it
- The two values should have an extra price, like 100 for A and 150 for B
- Create an attribute of type dynamic, 2 values C and D for it
- C should have an extra price of 100 and 150 for D
- Make a product with both of those product, set the price to 100

2 possibilities:

- In the PoS, click the product, on the product popup, the price is 100
- This 100 is the product's price and does not change even if we change the values
- Order that product and buy it with variants A and C
- Click on the product again, the price is 300, which is correct
- When we click on D, the price is reset to 100, but should be 350

**Why the fix:**

When computing the popup's title, we try to get the current product based on the variants choices in the popup. If the product is found, we take that, because it means that it's already in the database.

https://github.com/odoo/odoo/blob/0d7f5058664b501779b833609468e535b34356bf/addons/point_of_sale/static/src/app/components/popups/product_configurator_popup/product_configurator_popup.js#L260

If we do not find it, we just take the product template, which does not contain the current extra prices, which is why we got a price of 100 in the exemple.

The product is not found because in the case of dynamic variants, the product is only created once it has been ordered at least once. Which means that for this newly created product, it is not yet in the database, so we take the product template instead of the product itself.

We now also add the extra price for a product if it is undefined, meaning it has not been found in the database yet.

We can't directly update the getter for the priceExtra, as it's also used to build the payload. As the rest of the code works fine with dynamic products with extra price the way it is sent now, we only change the title instead of changing the entire logic and computation.

opw-6326125

Forward-Port-Of: odoo/odoo#273411

## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058

Problem:
Some users with limited access rights cannot access invoices they created, after another user duplicates their sales order and invoices it.

Steps to reproduce:
1. Create a user with minimal access rights (only access rights to their own sales orders and invoices).
2. Sign in as that user and create a sales order and confirm it.
3. Create an invoice for that sales order and validate it.
4. Sign in as an administrator and create a duplicate sales order for that sales order, but assign it to a different user (not the one created in step 1).
5. Confirm the duplicate sales order, create an invoice for it and validate it.
6. Sign in as the user created in step 1 and try to access the invoice created in step 3.
7. Note the access error

Cause:
When reading an account.move record, the system searches for duplicate moves and adds them to the duplicated_ref_ids field. However, it does not check if the user has read access to those duplicate moves, which leads to access errors when trying to access the main account.move record (which the user has read access to) because the system tries to read the duplicate moves (which the user does not have read access to).

opw-6374566

Forward-Port-Of: odoo/odoo#276547

**Description of the issue/feature this PR addresses:**
----------------------------------------------
On mobile devices, the meeting view had two UI issues affecting the call
experience.
The call permission dialog could display an unwanted focus outline around
its content because the dialog body was focused on touch devices.
Additionally, meeting action buttons could be partially hidden,
especially in portrait mode, as the meeting view could extend beyond the
visible viewport height.

**Current behavior before PR:**
----------------------------------------------
- Opening the call permission dialog on mobile could show an unwanted
  focus outline around the dialog content
- Meeting action buttons could be partially hidden on mobile devices
- In portrait mode, the footer could overflow below the visible viewport


**Desired behavior after PR is merged:**
----------------------------------------------
- Call permission dialog opens on mobile without showing the unwanted
focus outline on main body.
- Meeting action buttons remain fully visible on mobile devices


Task-6232825

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

Forward-Port-Of: odoo/odoo#266620

Before this commit, the journal and the memo of a payment linked to a company-paid expense report could be modified although such payments must be kept consistent with their expense report: a missing comma in the set of protected fields merged 'journal_id' and 'ref' into a single meaningless entry. The memo was also left editable because the set still referred to 'ref', which was renamed to 'memo'.

Steps to reproduce:
- submit, approve and post an expense paid by company
- open the payment created for the expense report
- edit the memo or the journal and save, then try to edit the date

Editing the date is refused with "You cannot do this modification since the payment is linked to an expense report", while the memo and journal changes are silently accepted.

Solution:
Restore the missing comma and protect the renamed memo field.

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

Forward-Port-Of: odoo/odoo#277737
Forward-Port-Of: odoo/odoo#277423

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/2fb92b4523 [REL] 19.2.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f9a1ba8541 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808)
https://github.com/odoo/o-spreadsheet/commit/f09540dff1 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/b393ef986e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/3a324a7e75 [FIX] table computed style: fix render table [Task: 6396322](https://www.odoo.com/odoo/2328/tasks/6396322)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

# How to reproduce
- Enable Cloudflare Turnstile in Settings > Integrations
- Add a CF Site Key & a CF Secret Key. e.g. :
	- `1x00000000000000000000AA`
	- `1x0000000000000000000000000000000AA` 
(See : https://developers.cloudflare.com/turnstile/troubleshooting/testing/)
- Go to a Website page with a form
- Add `?cf=show` to the URL
- Open the browser console
- Search the dom for an element with s_turnstile_container
- Look for the `data-appearance` attribute

# The issue
`data-appearance` is set to `interaction-only` but should be `always` according to :
https://github.com/odoo/odoo/blob/1e73172b51cd673c3414187af4f98304921ed7b3/addons/website_cf_turnstile/static/src/interactions/turnstile.js#L8-L12

# Cause
`appearance` is misspelled in the template :
https://github.com/odoo/odoo/blob/1e73172b51cd673c3414187af4f98304921ed7b3/addons/website_cf_turnstile/static/src/interactions/turnstile.xml#L7

Documentation on the Appearance modes for Turnstile : https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/widget-configurations/#appearance-modes

opw-6359977

Forward-Port-Of: odoo/odoo#275077

all_sm is referenced by two branches of the outer UNION, so PostgreSQL materializes it (a CTE used more than once is an optimization fence). Every query on report_stock_quantity therefore builds the forecast for all products/warehouses first and filters afterwards, so predicates like product_id can't reach the stock_move scan.

This hurts single-product lookups such as _read_group() in mrp_report_bom_structure._get_stock_availability(), called repeatedly per component while rendering a BoM report: each call does a full stock_move scan plus two sorts that spill to disk.

Marking all_sm NOT MATERIALIZED lets the planner inline it and push the product_id/warehouse_id filter down to an index scan, removing the full scan, the GENERATE_SERIES expansion and the on-disk sorts. warehouse_cte stays materialized (small and cheap).

Query generated from the _read_group:
```SQL
SELECT MIN("report_stock_quantity"."date")
FROM "report_stock_quantity"
WHERE (
        (
            (
                (
                    ("report_stock_quantity"."state" = 'forecast')
                    AND ("report_stock_quantity"."date" >= '2026-07-08')
                )
                AND ("report_stock_quantity"."product_id" = 15743)
            )
            AND ("report_stock_quantity"."product_qty" >= 1.0)
        )
        AND ("report_stock_quantity"."warehouse_id" = 4)
    )
    AND ("report_stock_quantity"."company_id" IN (1))
```

Before:
800 ms by _read_group in _get_stock_availability().
For opening a BoM overview with hundred of components takes 17 sec.

After:
25 ms by _read_group in _get_stock_availability().
Same BoM overview drops to 3 sec to open.

cc @Aurelienvd 



I can send you EXPLAIN ANALYZE, but I prefer to not putting them here to avoid data leakage.

Forward-Port-Of: odoo/odoo#277235
Forward-Port-Of: odoo/odoo#275022