Currently, an error occurs when a company-dependent selection field (e.g. invoice sending method) keeps a value after the related module is uninstalled.

**Steps to Reproduce:**
1. Install the Accounting app.
2. Disable 'Snailmail' from settings.
3. Send any invoice, make sure wizard Print & Send has selected "by Post" option.
4. Click on the Send button.

**Error:**
`AssertionError`

**Cause:**
Fields defined with `company_dependent=True` are stored as property fields rather than regular values. In PostgreSQL, these fields are stored as **JSONB** values keyed by company id.

When a selection value is removed (e.g. during module uninstallation), it attempts to compare the JSONB column directly with a string value, resulting in an invalid comparison and triggering the error. - [1]

**Fix:**
Update the SQL query to extract the value for the active company using JSON operators (->>), ensuring correct comparison with the expected selection value.

[1] - https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/odoo/addons/base/models/ir_model.py#L1812-L1815

sentry-6970900918

Forward-Port-Of: odoo/odoo#246671
Forward-Port-Of: odoo/odoo#241248

**Current Behavior:** description is not available for the Crowler

<img width="1159" height="802" alt="image" src="https://github.com/user-attachments/assets/2979f413-6487-4f44-993c-b9a806e0d0ef" />


**Steps to reproduce:**
1. Install `marketing_card`
2. Create a card campaign
3. Set Recipient, Post Link and Post Suggestion
4. Save and Preview
5. Copy the URL and replace `preview` with `redirect`
6. To reproduce in locale,  in the `contoller` make the marketing_card.card_campaign_crawler template the only return
7. Now paste that URL in the browser

**Issue**
- The `<meta property="og:description">` tag is empty in inspect. It does not contain any content

**Cause:**
- The controller `card_campaign_redirect` passes the campaign's suggestion text to the view using the key `post_text`. However, the template `card_campaign_crawler` attempts to access `post_suggestion`, which is not present in the rendering context.

**Solution:**
- Update the controller to pass `post_suggestion`

opw-5351041

Forward-Port-Of: odoo/odoo#238534

**Problem:**
when adding quantities to a lot via the physical inventory 
the move created, uses the standard_price of the product
and not the standard_price from the lot even if the product
is valued by lot.

**Steps to reproduce:**
- create an avco perpetual product, tracked and valued by lot
- confirm a PO for a quantity of 1 and a price of 10
- on the picking set the lot as 'lot1' and validate the picking
- confirm a PO for a quantity of 1 and a price of 16
- on the picking set the lot as 'lot2' and validate the picking
- open "Inventory/ Operations/ Adjustments/ Physical Inventory"
- on the quant line of the lot1 change the quantity from  1 to 2 
and apply
- open the product form

**Current behavior:**
the move created has a value of 13 (the standard price of the product),
so :
1) the standard price of the product is still at 13 
2) if you select the smart button for lots/serial number and select lot1 
you can see that the new cost is 11.5

**Expected behavior:**
the move created should have a value of 10 because we added a quantity
without specifying a cost in a lot which has a value of 10,
so:
1) the standard price of the product should now be 12
2) the cost of the lot should stay 10

**Cause of the issue:**
when calling _get_value_data on the move, and that we use 
_get_value_from_std_price (because there is remaining_qty 
after previous steps), 
https://github.com/odoo/odoo/blob/555df96ac87a51405767c32f0396f762d458fd29/addons/stock_account/models/stock_move.py#L382-L384
inside _get_value_from_std_price, we use the standard 
price of the product
https://github.com/odoo/odoo/blob/555df96ac87a51405767c32f0396f762d458fd29/addons/stock_account/models/stock_move.py#L450-L452

But if : 
- the product is valued by lots, 
- we're not in the case where we want to call _get_standard_price_at_date
(when the product is standard_price and at_date is set)


in this case we should use the standard_price of the lot 

**fix**
in case there is multiple lots on the move, we stay with the 
standard_price of the product because it's not clear that 
a weighted average would be better

opw-5898837

Forward-Port-Of: odoo/odoo#247437

This commit fixes an issue from report_invoice_document.
In the “show_payment_term_details” t-if, there was a single td
containing the `invoice_payment_term_id`.

In another module, `l10n_gcc_invoice`, we use this td in the following
xpath:
```xml
<xpath expr="//div[@id='total_payment_term_details_table']//td" position="before">
```
The problem is that a td cannot be used outside of a table, which will
cause incorrect HTML to be generated and therefore prevent Studio from
working on it.

One solution would be to replace the incorrect td with div, add a class
`early_payment_discount` to it, and create a new customization that
would target this time
```xml
<xpath expr="//div[@id='total_payment_term_details_table']//div[@id='early_payment_discount']" position="before">
```

In order not to break the current customization targeting the old
incorrect td, we keep it but this time in a correct `table/tbody/tr/`
and we do not display it in the final report.
This will be removed in master.

A new `oe_structure` has also been added below the Terms to allow people
who want to add a field below to do so, as this is currently not
possible. The only way to do this is to add a modification to the terms,
which will only be displayed if this field is not empty because it is in
a t-if.

opw-5248145
opw-5879285
opw-5410727
opw-5476981
opw-5381578
opw-5369618
opw-5485437
opw-5498946
opw-5331519

Forward-Port-Of: odoo/odoo#235969

Steps to reproduce:
1. Ensure you have a good amount of contacts set up in your database
2. Ensure that you have an IAP Account setup for the service "Partner Autocomplete"
3. Zoom in on your browser to at least 150% AND/OR make your browser window incredibly short
4. Go to the CRM app
5. Go into the form view of an opportunity
6. Type 3 characters or more into the 'Contact' field
7. Observe the error

An Unhandled Promise error could occur if, after typing more than 3 characters in an autocomplete field, the dropdown is scrollable, and Partner Autocomplete finishes loading before the normal autocomplete does. In this scenario, normal autocomplete is still loading and has not rendered it's options. This causes a `null` element to be passed [`scrollTo()`](https://github.com/odoo/odoo/blob/555df96ac87a51405767c32f0396f762d458fd29/addons/web/static/src/core/utils/scrolling.js#L80), which causes an error when it tries to access `element.parentElement`. This change ensures that this scenario is properly handled and does not cause the database to crash.

opw-5491270

Forward-Port-Of: odoo/odoo#247270

Description of the issue/feature this PR addresses:
This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing.

the first and main issue this PR addresses is that _get_downpayment_lines and _is_downpayment don't work properly on downpayment and final invoices generated in POS since there is no link formed between them through the sale order.

the second issue occurs during when printing downpayment invoices that were made through POS. since there is no line.name for the downpayment line. an error pops up due to the dual language logic in place.

To reproduce the issue:
- install pos_sale & l10n_sa_edi_pos.
- configure downpayment product on pos.config
- generate an SO and confirm it in the backend
- create a downpayment for that SO through POS
- settle the SO on the POS or through the backend.
- you'll find that the final invoice generated doesn't reference the downpayment invoice
- you'll also find that the downpayment invoice doesn't have the correct invoice type code indicating that it's a downpayment. 
- printing the invoice will also give an error when l10n_gcc_invoice is installed (for the downpayment invoice)

Current behavior before PR:
xml documents generated from l10n_sa_edi don't carry the correct reference to the downpayment invoice when it's the final invoice. they also don't have the correct invoice type code when it's a downpayment invoice if generated through POS

Desired behavior after PR is merged:
the methods _get_downpayment_lines and _is_downpayment now correctly identify the downpayment lines & if it's a downpayment respectively.
the dual language product name now shows on the invoice pdf without raising an error if line.name is undefined.

Task-5135918

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

Forward-Port-Of: odoo/odoo#247388
Forward-Port-Of: odoo/odoo#244443

Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.

Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)

When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17

This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.

OPW-5448916

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#244245

This change hides the remaining_hours_so field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic.

In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle.

To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription.

opw-5246238

Forward-Port-Of: odoo/odoo#247694
Forward-Port-Of: odoo/odoo#241099

The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the tax-included amount, but `total_excluded` (used for the discounted amount) is tax-excluded.

This caused the tax amount to be incorrectly reported as an AllowanceCharge (discount) in the MyInvois XML, because:
  discount_amount = price_unit * qty - total_excluded
                  = tax_included - tax_excluded
                  = TAX AMOUNT (not a discount!)

Example: Product priced at 110 MYR with 10% tax included:
- price_unit = 110 (tax-included)
- total_excluded = 100 (tax-excluded: 110 / 1.10)
- discount_amount = 110 - 100 = 10 ← incorrectly reported as discount

refs:

The cac:AllowanceCharge element in UBL is specifically for discounts and surcharges, NOT for taxes. According to the Peppol Malaysia e-Invoice specification:

https://docs.peppol.eu/poac/my/pint-my-sb/bis/#_allowances_and_charges

https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL5189/ (For this case we are interested in code 95)

Steps to Reproduce:
1. Configure a tax as "Included in Price" with Malaysia tax type
2. Create a product with that tax.
3. Create POS orders without any discount
4. Generate consolidated invoice and XML
5. XML incorrectly shows <cac:AllowanceCharge> with tax amount as discount

The fix uses `raw_total_excluded / discount_factor` (always tax-excluded) instead of `price_unit * quantity` (may be tax-included), consistent with the parent method:
https://github.com/odoo/odoo/blob/d645361a95037ac580d55e80bcb61d1eeb293efd/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1846-L1876

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

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

Forward-Port-Of: odoo/odoo#247267
Forward-Port-Of: odoo/odoo#245535

Issue :
-
After commit odoo/odoo@6d7f4012cfa06b35089e7557522fcbf658978b37, the `employee_overtime` field in `hr_holidays_attendance` was converted to a computed field on `hr.leave` model to use the new overtime deduction logic. However, the same change was not applied to `hr.leave.allocation` model.

Steps to Reproduce:
-
1. Create a Leave Allocation for an employee who has extra overtime hours.
2. Set the allocation less than the available extra hours.
3. In 19.0, when saving the allocation and creating a new allocation for the same employee:
   - The `employee_overtime` value did not update.
   - Even though the actual extra hours were reduced, the field still showed the old value.

Fix:
-
After this fix, the `employee_overtime` field in `hr.leave.allocation` is computed correctly, reflecting the actual available overtime hours.
This commit updates `hr.leave.allocation` by:
   - Converting `employee_overtime` to a computed field.
   - Computing its value using `_get_deductible_employee_overtime`.
This aligns the overtime computation between leave requests (`hr.leave`) and leave allocations (`hr.leave.allocation`).

Before Fix:
-
<img width="1898" height="659" alt="before_fix" src="https://github.com/user-attachments/assets/e4797a17-1031-4ba7-81c8-9ab09494134d" />

After Fix:
-
<img width="1902" height="623" alt="after_fix" src="https://github.com/user-attachments/assets/9d592795-20f6-40ce-bf42-a157769589a5" />

opw-5479200

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#245881

## Versions
19.0+

## Issue
The website's pick-up in store dialog doesn't show up full opening days.

## Steps to reproduce
*Ensure "Click & Collect" is enabled in the Settings*
- Go to "Delivery Methods" and edit "Pick up in store":
  - Click on the warehouse under the "Stores" tab:
    - Change the "Opening Hours" values (set one if needed) by clicking on the internal link:
      - Under the "Working Hours" tab, change or add a line with its "Day Period" set to "Full Day" and save.
    - Save.
  - Ensure the method is "Published".
- Go to the website's shop:
  - Look for a product that can be retrieved from the store (e.g. "Chair floor protection");
  - Go to checkout and fill forms in until you arrive on the delivery form where you can select a store location:
    - Select the warehouse you changed:
      - Check the opening hours not displaying the full day's data.

## Cause
`full_day` has been introduced in the calendar via commit 77f860f5d3757e5a56861ac1de95b9ad29ea0dff but its retrieval in `website_sale_collect` was skipped du to `day_period` restrictions. These restrictions exist because we don't want to consider breaks in the opening hours

opw-5904377

Forward-Port-Of: odoo/odoo#247840

### Issue:
When saving a page while elements that use page options are not present
in the DOM, the related page options are still saved. This ends up
overriding the previously saved values with defaults.

### Steps to reproduce (for the header):
1. Open any website page and enter edit mode.
2. Make sure both the header and footer are visible.
3. Set the header position to 'Hidden'.
4. From the 'Theme' tab, hide the header using the 'Show Header' option
   under 'Advanced'.
5. Select the footer and hide it using the 'Page Visibility' option.
6. Click on 'Save'.
7. Show the header again from the 'Theme' tab.

A similar issue can be reproduced when the breadcrumb is not present on
the page.

### Reason:
When the relevant element is not present in the DOM, the
`getVisibilityItem` method falls back to 'regular'. This fallback value
overrides the previously saved option, even though the element was not
available to compute its real state.

### Fix:
Only compute and save page options related to an element when that
element exists in the DOM.

task-[5135925](https://www.odoo.com/odoo/action-4043/5135925)

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

Forward-Port-Of: odoo/odoo#240065

### Issue:

Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.

Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n   SET l10n_pl_edi_certificate = NULL,\n       l10n_pl_edi_access_token = NULL,\n       l10n_pl_edi_refresh_token = NULL,\n       l10n_pl_edi_session_id = NULL,\n       l10n_pl_edi_session_key = NULL,\n       l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n     INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n          VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n     ON CONFLICT (key)\n   DO UPDATE SET value = 'test',\n                 write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9:        l10n_pl_edi_session_key = NULL,

```

Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(4 rows)
```

After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_session_iv
 l10n_pl_edi_session_key
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(6 rows)
```

### Solution:

Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the  res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.

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

Forward-Port-Of: odoo/odoo#247130

# Steps to reproduce:
* Install **Accounting** and **l10n_be_reports**.
* Enable **debug mode**.
* Go to **Accounting → Reporting → Belgium → Partner VAT Listing**.
* Create invoices with invoice lines with no product set on it, just a label, so that **more than 10 Belgian partners** appear in the report and ensure each partner has a **VAT number**.
* Open the report **Options** tab and set **Load More Limit** to **5**.
* Click **Load More** until all partners are visible.
* Click **Returns** and create a return for the month you have created invoices for, and submit it.
* Download the generated XML.

# Observed behavior:
* The XML file contains only the first batch of partners.
* Partners shown after clicking **Load More** are missing from the export.

# Cause:
* In v17, the XML export button was defined as:
https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/l10n_be_reports/models/partner_vat_listing.py#L53-L59
* This meant clicking the button would go through the [export_file](https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/account_reports/models/account_report.py#L4927)
 method, which sets `options['export_mode'] = 'file'` before calling the export function. The test in v17 explicitly sets `export_mode = 'file'` to simulate what `export_file` does in production.
 
* In v19, the architecture changed:
  - The XML export is now triggered via the account.return workflow and a submission wizard [1.](https://github.com/odoo/enterprise/blob/19.0/l10n_be_reports/wizard/vat_listing_submission_wizard.py)
  - The wizard's `print_xml` method calls [_get_closing_report_options()](https://github.com/odoo/enterprise/blob/19.0/account_reports/models/account_return.py#L1601) which does NOT set `export_mode = 'file'`.
  - The controller then calls `dispatch_report_action(options, file_generator)` directly, bypassing `export_file`.
 
* Why the test changed:
  - In v17 test: `export_mode = 'file'` was set to mimic the `export_file` →  `partner_vat_listing_export_to_xml` flow.
  - In v19 test: `export_mode = 'file'` should NOT be needed in the test because the fix is to set `export_mode = 'file'` inside `partner_vat_listing_export_to_xml` itself.


# Fix:
* Enable **export mode** when generating the XML.
* Ensures all partners are included regardless of the load limit.

opw-5494247

Forward-Port-Of: odoo/enterprise#106134

**Steps to produce:**
- Install `website_sale` with demo data.
- Go to the shop page.
- Select product `Customizable Desk` > click `Add to cart`.
- In the wizard, change the quantity to 100 and directly click `Checkout`.

**Issue:**
- The cart shows the product with quantity = 1 instead of the edited value.

Root cause:
- When the user clicks Checkout, both `setQuantity` and `onConfirm` are triggered
  almost simultaneously.
- At [1], the `_setQuantity` method is called, but due to the await before the
  quantity update is completed, the update may not finish in time. As a result,
  the previous quantity is sometimes used during checkout instead of the
  newly selected one.

Solution:
- we can update the quantity immediately before awaiting `_updateCombination`,
  ensuring that the correct quantity is already set when onConfirm runs.

[1]: https://github.com/odoo/odoo/blob/f4eabe47a602301013afa63da6bdf87809903d29/addons/sale/static/src/js/product_configurator_dialog/product_configurator_dialog.js#L225

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

Forward-Port-Of: odoo/odoo#241424

**Current Behavior:** description is not available for the Crowler

<img width="1159" height="802" alt="image" src="https://github.com/user-attachments/assets/2979f413-6487-4f44-993c-b9a806e0d0ef" />


**Steps to reproduce:**
1. Install `marketing_card`
2. Create a card campaign
3. Set Recipient, Post Link and Post Suggestion
4. Save and Preview
5. Copy the URL and replace `preview` with `redirect`
6. To reproduce in locale,  in the `contoller` make the marketing_card.card_campaign_crawler template the only return
7. Now paste that URL in the browser

**Issue**
- The `<meta property="og:description">` tag is empty in inspect. It does not contain any content

**Cause:**
- The controller `card_campaign_redirect` passes the campaign's suggestion text to the view using the key `post_text`. However, the template `card_campaign_crawler` attempts to access `post_suggestion`, which is not present in the rendering context.

**Solution:**
- Update the controller to pass `post_suggestion`

opw-5351041

Forward-Port-Of: odoo/odoo#238534

**Steps to reproduce:**
- Create a combo, set the free and max to 3
- Create the product combo and set it's price to 50
- Go to PoS, order said combo and chose the same product 3 times
- The price is 49.98 instead of 50

**Problem:**
When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50.

**Why the fix:**
This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines.
In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. 

The solution would be to take the line's qty into account when computing how much we should subtract.
Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend.

The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. 
This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them.
As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered.

opw-4931215

Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.

Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)

When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17

This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.

OPW-5448916

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#244245

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Forward-Port-Of: odoo/odoo#247664
Forward-Port-Of: odoo/odoo#241603

### Issue:

Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.

Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n   SET l10n_pl_edi_certificate = NULL,\n       l10n_pl_edi_access_token = NULL,\n       l10n_pl_edi_refresh_token = NULL,\n       l10n_pl_edi_session_id = NULL,\n       l10n_pl_edi_session_key = NULL,\n       l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n     INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n          VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n     ON CONFLICT (key)\n   DO UPDATE SET value = 'test',\n                 write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9:        l10n_pl_edi_session_key = NULL,

```

Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(4 rows)
```

After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_session_iv
 l10n_pl_edi_session_key
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(6 rows)
```

### Solution:

Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the  res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.

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

Forward-Port-Of: odoo/odoo#247130

Currently journal items shown don't belong to the account group that
they should belong to, and from saas-18.3 an error will be generated
after following the below steps or step mentioned in ref PR [1].

- Install `Accounting (accountant)` with demo data
- Create account groups e.g., name as `Test 1` and code prefix `1 to 1`
- Go to the general ledger report
- Click on `Journal Items` of the account group line `1 Test 1`

Error from saas-18.3:
`ValueError: Cannot convert account.account.group_id to SQL because it is ...`

This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the
`account.account` model to the search domain. However, in 18.0, commit [2] modified
this field so that it is no longer stored. As a result, when a search domain includes
this `non-stored` field, Odoo skips the domain evaluation and logs a error at code
line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0.

Also, starting from saas-18.3, passing such a non-stored field in a domain raises an
explicit error at code line [4], instead of being silently ignored.

This commit resolves the issue by introducing an SQL query that
returns the account ids related to `record_id(account group id)`
include `record_id` as `None`.

[1]: https://github.com/odoo/enterprise/pull/100191
[2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767
[3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174
[4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201

sentry-7100657414

Forward-Port-Of: odoo/enterprise#103137

Steps to reproduce:
--------------------------------
1. Install `industry_fsm_sale` module
2. Go to Settings > Configure Document Layout
3. Select the Bubble document layout and save
4. Open any Field Service task
5. Use the Products smart button to add one or more products
6. Click the Settings icon > Print > Field Service Report

Observation:
--------------------------------
In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals

Issue:
--------------------------------
The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders

Solution:
--------------------------------
Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout


Before:
<img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" />


After:
<img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" />


opw-5401612

Forward-Port-Of: odoo/enterprise#105616

*= account_bank_statement_import_csv

An exception is currently triggered when a user attempts to import a bank
transaction file containing more than 80 transaction lines (see ref file [1]).

Steps to produce an error:
- Install `Accounting (accountant)` module
- Go to `Accounting` > Click on `Bank` > Click `Upload`
- Upload  ref file [1] and click `Test/Import` >>> Error occurs

Error: `psycopg2.errors.SerializationFailure: could not serialize access
due to concurrent update`

Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f
-11f0-bc75-74563c5c983f" does not exist`

The issue occurs because, in `model.py` code line [2] creates a `savepoint`.
Before this `savepoint` is closed, code line [3] is triggered during the
creation of the bank statement line [4] and attempts to commit the
cursor using `self.env.cr.commit()`. Because a commit is executed while
the savepoint is still active, the system fails when trying to close the
previously created savepoint.

This commit fixes the issue by avoiding cursor commits during the import
process. The `import_file=True` flag is added to the context when
`_cron_try_auto_reconcile_statement_lines` is called from `execute_import`,
allowing the method to safely skip commit/rollback logic when
`import_file` is present in the context.

[1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true
[2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973
[3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218
[4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780

sentry-6974536471
opw-5359810

Forward-Port-Of: odoo/enterprise#106780
Forward-Port-Of: odoo/enterprise#102760

### Issue:

Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.

Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n   SET l10n_pl_edi_certificate = NULL,\n       l10n_pl_edi_access_token = NULL,\n       l10n_pl_edi_refresh_token = NULL,\n       l10n_pl_edi_session_id = NULL,\n       l10n_pl_edi_session_key = NULL,\n       l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n     INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n          VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n     ON CONFLICT (key)\n   DO UPDATE SET value = 'test',\n                 write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9:        l10n_pl_edi_session_key = NULL,

```

Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(4 rows)
```

After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_session_iv
 l10n_pl_edi_session_key
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(6 rows)
```

### Solution:

Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the  res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.

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

Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.

Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)

When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17

This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.

OPW-5448916

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#244245

This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines.

Steps to reproduce:
1. Create payment with x amount and validate it.
2. Open the payment journal entry.
3. Reset to draft and update the liquidity line amount from x to (x - y)
4. Create another liquidity line with amount y to balance entry and post it.
5. Draft the payment and try to update the amount.

A traceback will appear. `ValueError: Expected singleton`

Cause:
The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error.

Description of changes made:
While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write.
Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually.

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

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

**Steps to produce:**
- Install `point of sale` without demo data.
- From the settings, enable `Promotions, Coupons, Gift Card & Loyalty Program`.
- Create a product test with a sale price of `1000`. (Remove the taxes).
- Create `3 loyalty programs`: 
     - `100 off` on a specific product test.
     - `10% off` on a specific product test. 
     - `20% off` on a specific product test.
- Now go to the POS and add the test product in order.

**Issue:**
- As the product price is `1000`, the first discount applies a `fixed amount of
  100`. The remaining amount is `900`, on which a `10% discount` applies (`-90`). The final `20% discount` should then apply to `810`, resulting in a discount of `-162`. However, the system currently applies `-160 instead`.

**Root cause:**
- At [1], in the `_getDiscountableOnSpecific` method, when the system attempts to apply the `final 20% discount`, it first evaluates the previously configured discounts. During this evaluation, `percentage discounts` are applied `before fixed amount discounts`. As a result, the `10% discount` is applied on the `original price (1000 → 900)`, followed by the `fixed 100 discount (900 → 800)`. The `final 20% discount` is then calculated on `800`, leading to an incorrect discount of `160 instead of 162`.

**Solution:**
- In the solution, we don’t just apply the raw percentage discount. We compare the computed percentage reduction against the `actual discount amount`, cap it to the smaller value, and then subtract safely so the remaining amount never overshoots.

[1]https://github.com/odoo/odoo/blob/50308d7d69af6848c2aa2cca8e5dbfff1491c983/addons/pos_loyalty/static/src/overrides/models/loyalty.js#L1249-L1262

**Before:**
<img width="500" height="336" alt="image" src="https://github.com/user-attachments/assets/2fa6e76e-ff02-4cda-b5e5-63ec1d099cba" />


**After:**
<img width="500" height="284" alt="image" src="https://github.com/user-attachments/assets/e3fe0adf-e64a-45bc-a8a1-939427af9e9e" />


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

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

When the "Enter Code" text popup is open in POS, typing outside the input field still affected the active orderline quantity because the number buffer globally captured key events. This change blocks number buffer handling only when the top popup is the text input popup.

Steps to reproduce:
-------------------
* Open a POS session.
* Add a product (quantity one).
* Click “Enter Code”.
* Click outside the popup input, then type a code.
> Observation:
Quantities on the selected product increase even though a popup modal is open.

Why the fix:
------------
The number_buffer was listening to global keyup events and only ignored events targeting INPUT/TEXTAREA. With a modal open, keystrokes outside inputs still modified quantities. We now:
Ignore number buffer events only when the top popup is TextInputPopup (so virtual numpad popups still work). Make popup usage optional (inject via env.services?.popup) to avoid breaking cases that don’t start the popup service.

opw-5144792

Currently, the `Tax name` configured on taxes is not applied in 
the web preview of orders.

**Steps to reproduce:**
- Install the `sale_management` module.
- Go to Invoicing > Configuration > Accounting > Taxes.
- Create a new tax, `Tax Type: Sale`and set `Description`.
- Create a new quotation and apply this tax to a product.
- Click Preview > observe the `Taxes` value.

**Observation:**
- Web preview incorrectly displays `description` instead of `tax name`.

**Root Cause:**
At [1], the sale portal web preview template uses `description or name`, 
which causes an incorrect tax description to be displayed in the preview.

**Fix:**
This commit ensures that `Tax Name` is used when rendering taxes 
in the portal preview for Reantal, Sales, and Subscriptions apps.
This aligns with the behavior in the next versions.

Related Enterprise PR: https://github.com/odoo/enterprise/pull/106830

[1]:
https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/views/sale_portal_templates.xml#L598

opw-5411496