Behavior before:
Opening the inventory valuation report on databases with 300k+ products
(storable) caused an out-of-memory (OOM) error, making the report completely
unusable at this scale.

Behavior after:
The inventory valuation report loads successfully and efficiently for 300k+
products without any memory errors or RAM spikes.

Root Cause:
In `_get_accounts_by_product()`, querying all storable products creates a massive
recordset. When iterating through this recordset, the call to `_get_product_accounts()`
accesses various relational and property fields (like categories and accounts).
Because standard ORM prefetching was active, accessing these relational fields on the
first loop iteration triggered a massive batch-fetch for all 300k+ products in the
recordset simultaneously. This cascading prefetch overloaded the environment cache
and caused an immediate OOM crash.

Fix:
Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`.
This disables the greedy batch-loading behavior across the entire recordset. The ORM
now fetches the required relational accounting fields surgically, record-by-record
inside the loop, maintaining a minimal memory footprint and preventing the crash.

Benchmark:

| Products Count | Memory Before  | Memory After | Time Before | Time After |
|------------------------|-------------------------|----------------------|------------------- |----------------|
| 300k+                  | Memory Error     | 1.1. GB             | 46.63 s           | 1.9 m         |
| 200k                    | Memory Error     | 566.4 MB         | 1.2 m              | 1 m            |
| 100k                    | 873.1 MB             | 286.8 MB         | 36.74 s            | 32.15 s      |
| 50k                      | 442.1 MB             | 145.6 MB         | 18.96 s            | 17.65 s      |

opw-5462037



Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#253331

Steps to produce:
---
- Install `Sales` module.
- Go to `Sales > Configuration > Sales Orders > Quotation Templates`.
- Create a new template and add a section.
- In the section name, add text with line breaks using `Shift + Enter`.
- Go to sale orders > Create new SO > Set quotation template created above.

Issue:
---
- Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one.

Root cause:
---
- At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2].

Solution:
---
- Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered.

[1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96
[2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86

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

Forward-Port-Of: odoo/odoo#256058

Problem:
In RTL websites, the table row menu is not placed correctly.

Cause:
The `inlineStartOffset` calculation in `table_menu` depends on the
`direction` parameter, which was not passed during the editor
initialization.

Solution:
Ensure the `direction` parameter is properly passed during editor
initialization so the `inlineStartOffset` is computed correctly in
RTL layouts.

Before:
<img width="1091" height="682" alt="image" src="https://github.com/user-attachments/assets/964903b2-d33b-48aa-86c2-632cc5adac9a" />
After:
<img width="1093" height="658" alt="image" src="https://github.com/user-attachments/assets/846fd39c-1114-408d-a1f4-75b27218b9b0" />


Steps to reproduce:
- Change website language to Arabic.
- Add a text block and insert a table inside.
- Hover over the first table row.
- Observe the row menu is misplaced.

opw-6049260

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

Forward-Port-Of: odoo/odoo#256045

# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
	- Inactive Accounts
	- Account: 101401 (the code of the record)

 # The problem
 The record that we searched for is not shown

 # Cause
The domain for  the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147

And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159

This is correct and the search should return what we wanted, but the code's search is overriden by:

https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384

And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored

This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`

# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search

opw-6059404

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

Forward-Port-Of: odoo/odoo#256939
Forward-Port-Of: odoo/odoo#256060

How to reproduce :
- Create a product
- Create an attribute with a value set to "free text"
- Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name
- Put Dropship as the route for the product to create a PO on a SO confirmation
- Create a SO with that product
- Confirm the SO and go to the PO
- Change the vendor in the SO

The problem :
The Vendor Code and/or Vendor Name does not change correctly in the product description

Why :
The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user.

This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions.

It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method.

The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change.

opw-5888233

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

Forward-Port-Of: odoo/odoo#256665
Forward-Port-Of: odoo/odoo#247330

The AVCO audit report currently recalculates the AVCO value on outgoing moves. Based on the logic in `run_average_batch()`, it should instead use the AVCO value computed on the last ingoing move to recalculate the
`added_value`.                                                         

On the other hand, the `added_value` should not be recomputed from the AVCO value on ingoing moves.

Source of those changes: [245141](https://github.com/odoo/odoo/pull/245141)

Steps to reproduce the issue:
1. Create a new product. Do not assign it to a category yet.
2. Set the cost (standard_price) to 10$ on the product form.
3. Add 10 units to inventory.
4. Sell and deliver 5 units to a customer.
5. Purchase 10 units at 25$/ea and validate the receipt.
6. Sell and deliver 5 units to a customer.
7. Assign the product to category with AVCO cost method.
8. Go to the AVCO justification report:
    - The added value on the purchase is incorrect: 200$ instead of 250$.
    - On the last delivery: the added value is -125$ and the AVCO increases from 20$ to 25$.

Ticket: opw-5921104

Forward-Port-Of: odoo/odoo#252239

When users would follow the following step as they are makeing a private task,  they would be hit by an incorrect access error.

Steps to reproduce:
1.Open the form view to create a new task.
2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task.
4.Create the private task.
5.An access rights error occurs, stating that the user does not have permission to create the record.

⚠️ Note:
This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs.

Root cause:
When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation.

This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users.

Fix (implemented):
Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing.
To address this, we now require at least one user to be assigned to a task when it is not attached to a project.  This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record


Versions : 17.0 -> master
Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#257050
Forward-Port-Of: odoo/odoo#242216

Currently an error is generated when the user tries to save a report with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow  `view.arch` to be empty. As a result, this error is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available.

[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#256009
Forward-Port-Of: odoo/odoo#255316

Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC

-> Nothing happens.

Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains  no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.

When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.

Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases

opw-5891054

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

Forward-Port-Of: odoo/odoo#254284
Forward-Port-Of: odoo/odoo#250050

**Steps to reproduce:**
- Install Mail Marketing app
- Change user language to a RTL language (such as Arabic)
- Create a marketing campaign with RTL content
- Send it
- Mail received changes from RTL to LTR

**Issue:**
Conversion doesn't take into account the current
language direction anymore when creating the inline
styling. This keeps the mails in the default format ('ltr').

Previously the inline conversion was using the `/portal/static/src/scss/portal.scss`
to set the html body text direction using the `rtlcss` library:
```css
 // Frontend general
body {
    // Set frontend direction that will be flipped with
    // rtlcss for right-to-left text direction.
    direction: ltr;
}
```
It was used during the inline conversion in a `CSSStyleRule`
after loading the doc sheets, and added with the `.o_layout` selector:
```js
if (selector === "body") {
    // The top element of a mailing has the class
    // 'o_layout'. Give it the body's styles so they can
    // trickle down.
    cssRules.push({
        selector: ".o_layout",
        rawRule: subRule,
        specificity: 1,
    });
}
```
But recent refactor reworked the styling assets used by
this process, which removed this behavior.

**Fix:**
Keep style `direction` (instead of `dir` attribute) like
before, to avoid compatibility issues in mail engines.
This is done by reapplying the body rule on the
mass_mailing iframe styling, but it could also be manually
added to the fragment itself using the editor current config
or localization.

related: https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86

opw-5982854

Forward-Port-Of: odoo/odoo#255628

# How to reproduce
- Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number)
- Go to another page in edit mode
- Select a button
- In the "Enter URL, /page, or #anchor" input, write the url to your page (/3-14)
- Click on Apply

# The problem
Instead of a link to our page, the button has a link with a tel: protocol.

# Cause
When clicking on the Apply button, the `applyDeducedUrl()` function will be run.

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/link_popover.js#L294

That function will change the selected url with the URL deduced from `deduceURLfromText()` if any is found. In our case "/3-14" matches the `PHONE_REGEX` pattern so the url is prefixed with the tel: protocol.

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L71

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L34

That regex is a bit too permissive and allows our "/3-14" to be matched even though it starts with "/".
Side note : cases like "( )", "...", "--)" are also a match, which is not really an issue because they do not really represent anyting but it shows that the regex is not strict enough.

# Proposed solutin
We edit the regex to make it so it only matches strings that have atleast a digit and where the first character (after "+") is a digit or "("

opw-6047571

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

Forward-Port-Of: odoo/odoo#255877

Currently, an error occurs when user validates a picking.

**Steps to Reproduce:**

 - Install the `sale_management` and `sale_stock` modules.
 - Create a `sale order` without `any sale order lines` and `confirm` it.
 - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`.
 - In the `Additional tab`, select the `sale order (the one without order lines)`.
 - Now `validate` this delivery.

**Error:**
`ValueError: max() arg is an empty sequence`

This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error.

This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used.

[1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164

sentry-7089149997


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

Forward-Port-Of: odoo/odoo#254803
Forward-Port-Of: odoo/odoo#239030

When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env.

In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle.

Steps to reproduce:
1. Configure Odoo with a PostgreSQL primary/replica setup.
2. Open a website in edit mode.
3. Trigger an asset regeneration (for example by changing a theme color).
4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle.

Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env.

opw-6034833

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

Forward-Port-Of: odoo/odoo#257189
Forward-Port-Of: odoo/odoo#255530

[FIX] website_profile, gamification: fix weekly/monthly leaderboards

Prior to this commit, the leaderboard pagination logic was flawed when
filtering by specific time periods (e.g., "This Week" or "This Month").

The system would first retrieve users sorted by their *all-time* global
karma, apply pagination (taking the top X users), and only then calculate
the karma gain for the specific period for those few users.

This caused users with high recent activity but low all-time karma to only
be displayed much later in the page order than they should.

This commit fixes the issue by introducing a pre-search step that
calculates the karma gain for the requested period at the database level.
Pagination is now applied to this specific result set, ensuring users are
correctly ranked by their actual performance during that week or month.

Note: A new method `_get_users_by_tracking_karma_gain` was added to
`res.users` to handle this logic. This approach was chosen to strictly
preserve the signature of existing methods for the stable version.
A distinct refactor to unify these calculation methods is planned for
the master branch.

Steps to reproduce:

- Install the eLearning module.
- Create a few users with different karma_points (more than 25 to have 2 pages).
- Go to /profile/users.
- Group by week.
- Paginate, and you will notice that the order is wrong; the first user on the second page might have more points than users on the first page. Also, when the logged-in user is not on that page, they do not appear at the bottom.

task-5344657
opw-3979785

Forward-Port-Of: odoo/odoo#257210
Forward-Port-Of: odoo/odoo#176626

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112818
Forward-Port-Of: odoo/enterprise#112566

In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant.

When no sequence number is provided, the system automatically assigns one by taking the highest existing sequence among articles with the same parent and incrementing it by 1.

When demo data is enabled, additional users are created along with their corresponding onboarding articles. As the onboarding articles does not have any parent, the onboarding article are included in the computation of the sequence number of the new article we create in the test. These extra articles impacts the sequence number of the new article, causing the test assertion to fail.

To resolve this, the test computes the expected sequence number dynamically based on the current state of the data. This ensures consistent behavior regardless of whether demo data is present.

runbot-error-id~231695

Forward-Port-Of: odoo/enterprise#106326

## Issues
When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears.

Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab.

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a second company
3. Create a subscription product and set a company in the *Company* field (`company_id`).
4. In the *Recurring prices* tab, add a line (any recurring plan, any price)
5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_**

For the second issue, after the same 3 first steps:
1. Create a *Recurring Plan* RP with its *Company* field set to the current company
2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP
3. **The Recurring plan RP is missing from the list of available plans.**

## Cause
When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases.

https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26

By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`:

https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173

opw-5981629
opw-6051978

Forward-Port-Of: odoo/enterprise#109403

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and  create a new delivery with
   - **Source Location:** WH/Stock
   - **Product:**  [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

Forward-Port-Of: odoo/enterprise#112616
Forward-Port-Of: odoo/enterprise#109204

### Issue before this commit:
When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'.

### Steps to reproduce the issue:
1. Select two or more companies from multi company menu
2. Accounting / Reporting / Ledgers / General Ledger
3. Posted Entries, Accrual Basis button
4. Pick Consolidation
5. Error

### Cause of the issue:
When more than one company is selected, the General Ledger consolidation groups journal entries by multiple parameters in an increasingly strict hierarchy. One of these parameters is account_code, which is required only in a multi-company context (as account_id alone is sufficient when a single company is selected).
However, the SQL query was not properly adapted to handle this case. The account_code field was used as a grouping key but was not retrieved from the database, resulting in a KeyError.

### Reason to introduce the fix:
To ensure that the General Ledger consolidation can be correctly displayed in a multi-company context and to prevent runtime errors.

opw-5933074

Forward-Port-Of: odoo/enterprise#112567
Forward-Port-Of: odoo/enterprise#109036

A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled

Steps to reproduce:
1. Install eCommerce and Subscriptions
2. Go to Settings and enable `Prevent Sale of Zero Priced Product`
3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website
4. Go to Subscriptions > Pricelists and edit pricelist "Benelux"
5. In the Recurring Prices tab, create a new entry for product "subscription"  with a Fixed Price of $20.00 and a monthly Recurring Plan
6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected)
7. Try to add it to the cart
8. Nothing happens and an error is displayed in the log

Issue:
When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs
We reach this code
https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero
Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches
https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans
Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart

Solution:
We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart.

Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`.

opw-5993614

Forward-Port-Of: odoo/enterprise#111624

Currently an error is generated when the user tries to save a report
with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access
nodes by using `etree.fromstring()` with an empty `view.arch`, which is
empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml`
constraint, which raised a validation error when an `etree.ParseError`
occurred while parsing `etree.fromstring(view.arch)` with an empty
`view.arch` (see code reference [2]). However, recent changes introduced
in commit [3] allow  `view.arch` to be empty. As a result, this error
is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling
`etree.fromstring()` when `view.arch` is empty, avoiding attempts to access
nodes from invalid data. It also updates the logic in the `web_studio`
module's `get_xml_editor_resources` method to ensure resources are processed
only when a valid view architecture is available.


[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

Forward-Port-Of: odoo/enterprise#112111
Forward-Port-Of: odoo/enterprise#88613