Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome turns out to have pretty extensive debug logging facilities which are somewhat valuable: https://www.chromium.org/for-testers/enable-logging/

For instance if the oomkiller decides to nuke a chrome tab (example selected for no reason whatsoever), the debug log will have an entry along the lines of

    [...:WARNING::chrome/browser/ui/sad_tab.cc:256] Tab Killed: http://127.0.0.1:8069/

which is a much more helpful hint than just being told a test timed out (to say nothing of being told that chrome was not able to do dbus stuff when we never asked for that).

Because it can be useful for all sort of debugging, this log is saved not just when chrome fails to start, but also when a Chrome completes, successfully or unsucessfully (in the latter case it's logged as RUNBOT to be available from the runbot UI).

The chrome logging facilities are controlled by a new envvar `ODOO_BROWSER_LOG_VERBOSITY`, it can be set to `-1` to disable logging, or a strictly positive integer for ever increasing amounts of logging. At `1` chrome will log every network request it attempts which can be useful for debugging some races but is already extremely noisy.

Forward-Port-Of: odoo/odoo#255548
Forward-Port-Of: odoo/odoo#255054

This commit aims to provide better support for contract changes that happen in the middle of a pay period.
It has a few impacting changes, notably:

1) Payslip calculation sequencing
As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun.
In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps.

To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers":
  - Layer 1: Computes the 1st payslip for ALL employees simultaneously.
  - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc

2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio.

3) Rule updates
The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit.
In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month.

Forward-Port-Of: odoo/enterprise#111570

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

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

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

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

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

opw-5995290

Forward-Port-Of: odoo/enterprise#109652

The bank reconciliation view was freezing on large databases (50k+ invoices,
90k+ journal entries), making it impossible to expand lines, filter, or interact
with the view in any way. Attempting to open a line would sometimes result in a
timeout.

**Root cause:** The `reconciledLineName` getter was called multiple times per
render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL
re-evaluates the template on every reactive state change, this created an O(n×m)
computation loop (n renders × m statement lines) that overwhelmed the browser.

**Fix:** Cache the result in OWL reactive state via a dedicated
`_computeReconciledLineName()` method, called once on setup and reactively via
`useEffect` when `line_ids.records` changes. The template is updated to store
`Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding
the array on every iteration.

| Metric | Before | After |
|---|---|---|
| Longest blocking task | 15 091 ms | 5 118 ms |
| Total blocking time | 74 147 ms | 22 481 ms |
| Avg. click response | 2 163 ms | 28 ms |
| Max click response | 14 305 ms | 222 ms |
| Total microtasks executed | 9 917 | 32 484 |

opw-5879798

Forward-Port-Of: odoo/enterprise#107135

[FIX] documents_account: sync all XML documents for account moves

Before this commit, the synchronization between accounting attachments and
the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol).

This caused several specific issues:
1. When creating an invoice via the Accounting upload interface, only the
   generated PDF was synced to the correct Documents folder, leaving the
   original XML file unsynced.
2. When creating an invoice from an existing file in the Documents app
   (via server action), the system correctly synced the generated PDF,
   but failed to move or sync the original XML source file to the
   target folder.
3. When receiving vendor bills via Peppol or other EDI networks, the proxy
   attaches the fetched XML to the `account.move` via an `ir.attachment` 
   write. Because this bypassed the existing sync filters, the Peppol XMLs 
   were never pushed to the Documents app.

This commit updates the `ir.attachment` logic in both `create` and `write`.
It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`)
is attached to an `account.move`—regardless of the move type or whether it 
was uploaded manually or fetched via EDI—the document synchronization logic 
is triggered, properly linking and filing the XML alongside the PDF.

Task-5909245
Task-5917535

Forward-Port-Of: odoo/enterprise#106574

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

Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.

Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
    - In the `Stores` tab, set your company warehouse.
    - In the `Availability` tab, add the created tag to Excluded Tags.
    - Publish the delivery method.
- Open the tagged product on the website.

Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.

Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.

Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
  for that delivery method. This keeps the behavior consistent across
  the website, avoids showing unavailable delivery options, does not
  impact other flows and aligns with the existing behavior during
  checkout.

[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194

opw-5921268

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

Forward-Port-Of: odoo/odoo#255482
Forward-Port-Of: odoo/odoo#250837

Case 1:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment > down payment of 300 is created in SO.
- In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order.

**Issue:**
- The down payment line is added twice in the POS order.

**Root cause:**
- At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order.
- At [2], the down payment line from the SO is added again.
- Here, when `Automatic invoice` is on and we make the online payment
  then `amount_paid` is updated and the downpayment invoice is also created.
- So, we have also downpayment line in sale order also.

**Solution:**
- Ensure that if a downpayment line has already been added to the POS order,
  the first downpayment line matching `amount_paid` is skipped.

[1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93
[2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111

Before:
<img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" />


After:
<img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" />

Case 2:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
-The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice
  is automatically created and amount_paid is also updated.
- At [3], the logic subtracts both the total invoice amount and amount_paid from
  the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to
  an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is
  encountered again, it should be skipped to avoid double-counting.

[3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

Forward-Port-Of: odoo/odoo#255420
Forward-Port-Of: odoo/odoo#242026

Steps to reproduce:
1. Go to an Email Template (e.g., 'Invoice: Send by email') and set a specific 'Reply-To' address.
2. Open a posted Invoice and click the 'Send & Print' button.
3. Ensure the 'Email' method is selected and click 'Send'.
4. Observe the sent email in the chatter or the mail queue. Observation: The 'Reply-To' header is overwritten by the system's catchall or author email, ignoring the template setting.

Cause:
The 'account.move.send' logic processes email data via the '_get_mail_params' method. This method manually constructs a dictionary of parameters to be passed to 'message_post'. However, it only explicitly includes a fixed set of fields (author_id, body, subject, partner_ids, and attachments), effectively filtering out the 'reply_to' value. When 'message_post' is called without this key, Odoo's mail thread logic defaults to the standard '_notify_get_reply_to' calculation, causing the custom template configuration to be lost.

Solution:
Update the '_get_mail_params' method to safely extract the 'reply_to' value from the move data and include it in the parameters dictionary passed to the mail engine.

opw-5922963

Forward-Port-Of: odoo/odoo#249116

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

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

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

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

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

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

**opw-6015526**

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

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

# How to reproduce
- Go to the Pysical Invetory list view
- Select more than one record
- In the Counted field, try to type a two digit number

# The problem
A popup asking for confirmation for editing a field is shown before the user has the time to type in the other digits. This makes it so it is not possible to input a number that has more than one digit.

# Cause
The Counted (invetory_quantity) field in the list view uses a special widget (CountedQuantityWidgetField). This widget has the responsability to set the inventory_quantity_set field to true when the the value of the inventory_quantity field is updated.

The inventory_quantity_set field is updated on input :
https://github.com/odoo/odoo/blob/f450bb6379b5c0354c048abcc688428d8bff1172/addons/stock/static/src/widgets/counted_quantity_widget.js#L33-L35

The inventory_quantity field is updated on blur :
https://github.com/odoo/odoo/blob/f450bb6379b5c0354c048abcc688428d8bff1172/addons/stock/static/src/widgets/counted_quantity_widget.js#L44-L49

This does not make a lot of sense, because we tell the backend that the quantity has been changed before sending the new quantity. This was not really an issue before but starting in 19.0, this commit (https://github.com/odoo/odoo/commit/9f0470b48e4e8c783513788e269ad16cbf84b7af) made the Physical Invetory list view multi-editable, highlighting the desynchronization

This fix aims to resynchronize the editing of both of theses values, allowing the bulk edit at the same time.

opw-5908205

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

Forward-Port-Of: odoo/odoo#254399

Steps to reproduce:
- Go to Azure Interior contact form:
  - Sales & Purchase tab > Group RFQs > Always
- Create a storable product "P1":
  - Route: Resupply Subcontractor
  - BoM:
    - Type: Subcontracting
    - Component: C1 with Dropship route and azure interior as vendor
- Create a storable product "P2":
  - Route: Resupply Subcontractor
  - BoM:
    - Type: Subcontracting
    - Component: C2 with Dropship route and azure interior as vendor
- Create a purchase order with one unit of P1 and P2
- Confirm the purchase order

Problem:
Two RFQs are generated (one for C1 and one for C2) instead of a single grouped RFQ.

When confirming the purchase order, a stock reference is created and assigned to it. This reference is correctly propagated to the picking and stock moves.

However, when the two manufacturing orders are created, new stock references are generated instead of reusing the original one. As a result, each MO ends up with a different reference:

https://github.com/odoo/odoo/blob/2713876dbc70d3984e584a9037a2206dcda4e84a/addons/mrp_subcontracting/models/stock_picking.py#L69-L72

This prevents from grouping RFQs, since the grouping logic relies on identical references. When the first RFQ is created for C1, it uses the MO reference, and when searching for a candidate RFQ for C2, none is found due to the reference mismatch:
https://github.com/odoo/odoo/commit/77dc92e4a0db0575a1a0e865cdd0c82978d593f6#diff-201f9fd7ec1067f7530aafeaa88420021930be82ce89e912d595ed55bb885f26R370-R372

Solution:
Reuse existing stock references when creating subcontracting MOs instead of creating new ones.

opw-5895378

Forward-Port-Of: odoo/odoo#254327

When creating a backorder because of missing product, if there is an extra product received it will create a return also create a return for that product.

### Steps to reproduce:

* Create and confirm a purchase ordre for 2 products (A & B)
* Add a product C to the picking order and reduce the quantity of product B received
* Validate the picking ordre
* Create a backorder
* Go back on the PO and open the linked pickings 
-> There is delivery linked for product C

### Observation:

When processing the backorder, it will sync the delivery and the PO with _action_synch_order where it will add the new product to the PO: https://github.com/odoo/odoo/blob/1a62c4333de61a4e1358ef8e229b2e0f5a3e9826/addons/purchase_stock/models/stock_move.py#L88-L89 
The create that is started by the creation of the new POL will trigger _create_or_update_picking that will create a stock move and a picking: https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L97 https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L197-L198

opw-5868172

Forward-Port-Of: odoo/odoo#248433

### Steps to reproduce:

- Ensure that sale_stock is installed
- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse WH2 and enable: Resupply from WH1
- Create a physical product using the route: Resupply from WH1
- Click on the product form cog wheel icon > Replenish
- Replenish 1 unit to warehouses 2
#### > The delivery that was created from WH1 to the inter company transit location does not set the `partner_id` (delivery address) to the partner of warehouse 2.

### Cause of the issue:

Triggering the replenish will create a move chain relying on the `_run_pull` mechanich. In particular,
the receipt move will be created first from Inter-company transit to `WH2/Stock` without `partner_id`:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_move.py#L1709 https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_move.py#L1674-L1677 Then, during its confirmation, the delivery move from WH1/Stock to the intercompany transit location will be created based on the rule and, thanks to these lines:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L342-L349
The `partner_id` of WH2 will be set as the `partner_id` of the delivery. Since there is a single partner this will also set the partner of the `move_values` of the delivery move we are creating to this partner:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L355-L360 However, if `sale_stock` is installed that `move_value` is reset to the value provided by the procurement values just a few lines bellow: https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L381-L384 because the `partner_id` field is part of the field name returned by the `_get_custom_move_fields`:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/stock.py#L173-L176
Since the `partner_id` value provided by the procurement values was `False`, it resets the the `partner_id` creation value to `False`.

### Fix:

As the flow relies on the value provided here:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_rule.py#L342-L349 when `sale_stock` is not installed but relies on the value of the procurement provided here:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_move.py#L1709 https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_move.py#L1674-L1677
if `sale_stock` is installed, it is necessary that both provide the same value to keep coherence in the flow. However, since the partner is will be expected to be set also via the procurement values, it is necessary to adapt the condition to which we will set a partner on the reception of the inter-company-transit:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_rule.py#L349 Which is the reason why we moved this line should be triggered only if no partner was set by the procurement values.

opw-6034309

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

Forward-Port-Of: odoo/odoo#254855

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

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

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

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

opw-5934381

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

Forward-Port-Of: odoo/odoo#253876