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

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/enterprise#106807
Forward-Port-Of: odoo/enterprise#99813