Steps to reproduce:
1- Install invoicing app
2- Add French language in the settings
3- Create a customer with language set as French
4- Create a product and define french translations of the name and the description in Sales tab
5- Create an invoice for that customer and choose the product you created
6- You will find the translated product name and description under the product name
7- Edit the description, save and preview the invoice
8- The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR]

Description of the issue:
When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase.

Expected behaviour:
User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name.

Why this happens?
1- When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description.
2- After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.]

Fix:
Use the product name returned in the label for trimming and concatenation to handle both original/translated text scenarios.

References:
original PR: #248401
partial revert: #254158

opw-5480494

Forward-Port-Of: odoo/odoo#256837

**Issue**:
Making a product a kit could prevent confirming deliveries.

**Steps to reproduce**:
- Make sure the account application is installed
- Create a product P without kit
- Create a SO and confirm it
- Make the product P a kit
- Validate the delivery associated to the SO
-> A traceback occurs: the record does not exist anymore

**Cause**:
While confirming the delivery:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown

**Aditionnal information**
Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation.
Therefore, no stock valuation errors will be created.

opw-6063602

Forward-Port-Of: odoo/odoo#260844
Forward-Port-Of: odoo/odoo#258403

Version:
----------
- saas-19.2+

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

1. Install `stock_dropshipping` and `sale_management` modules.
2. Create a Customer (res.partner) with a proper address block.
3. Create a dropship product (route: Dropship).
4. Create a Sales Order for the created customer.
5. Add the dropship product.
6. Confirm the Sales Order to generate a Purchase Order.
7. Open the generated PO/RFQ and print the report.

Issue:
------
The shipping address is missing in the printed PO/RFQ report.

Cause:
--------

The `t-call` syntax is updated to use the new semantic, which passes
values *as attributes/parameters* on the `<t>` (with `t-call`) tag itself,
instead of relying on nested `t-set` directive.

- Old (Deprecated): Used nested `<t t-set='var_name' t-value='x'/>` tags
inside the calling element to define variables.
- New: Variables are passed as attributes directly on the element where
the `t-call` is located (e.g., `<t t-call='module.template' var_name='x'/>`).

A warning is added to alert developers when using the old deprecated
syntax.

see Reference: https://github.com/odoo/odoo/pull/197296

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/c6892b30-10d6-4fb4-881c-1433d4fe07a0" />
  </div>
  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/6109fcc3-5773-44a8-b07b-6566ed855d3f" />
  </div>
</details>


> NOTE: We can also move test into `purchase_stock`

----

opw-6075017

---

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

Issue:
----------------------------------------
Creating a night shift from a template produces a shift spanning over one additional day.

Steps to reproduce:
----------------------------------------
- Create a planning shift template form 23h to 1h the next day (2h)
- It must have a span over 2 working days
- Create a shift and use this template
- The shift spans over one more day

Cause:
----------------------------------------
In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day.

Solution:
----------------------------------------
We should call `plan_days()` without the hour specified so we make sure the first day is included in the count.

opw-6134844

Forward-Port-Of: odoo/enterprise#114825
Forward-Port-Of: odoo/enterprise#114616

Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached

Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.

Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
 was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.

Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464

opw-6010337

Forward-Port-Of: odoo/odoo#255263

Currently, an error occurs when user tries to group by an analytic plan on depreciation schedule.

Steps to replicate:
- Install `accountant` with demo, turn on `Analytic Accounting` from settings.
- Open `Accounting > Review > Depreciation Schedule`.
- Click `Analytic` > Add a `Plan`.

Error:
```
psycopg2.errors.UndefinedFunction: operator does not exist: text = record
LINE 12:             WHERE key IN (('7', '16', '8', '15', '6', '9', '...
                               ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
```

Cause:
- At line [1], we pass a tuple of `analytic_account_ids`, which is then wrapped again in parentheses at line [2].

- This results in the IDs being enclosed in double parentheses, e.g. `(('7', '16', '8', '15', '6'))`.

- When the `IN` clause is used with this double-parenthesized tuple, PostgreSQL treats it as a list containing a single record. It then tries to compare `key` (a text value) with that record `('7', '16', '8', '15', '6')`, effectively resulting in a `text = record` comparison, which is invalid and causes error.

Solution:
- Removed the extra parentheses from the query.

[1]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L124

[2]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L121

sentry-7423121981

### Issue before this commit:
When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic.

### Steps to Reproduce:
Create a computed many2many field.
Add it to a form view (can be invisible).
Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field.

### Cause of the Issue:
In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity.
When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity.

### With This Commit:
Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets.

opw-6122024

Forward-Port-Of: odoo/odoo#260993

# Setup
You'll need a User with :
- An active contract (for easiness of testing, a contract that started long ago with 8hrs/day)

# How to reproduce
- Create a new Time Off type with "Ignore Public Holidays" enabled
- Create a Public Holiday for Period X
- Create A Time Off request for the User for a Period Y that contains Period X
- Go to the Time Off Ledger
- Remove the Missing Hours filter and search for the dates in Period Y

Exemple of periods :
- Period X => Feb 10 2026 - Feb 10 2026
- Period Y => Feb 9 2026 - Feb 11 2026

# The problem
The "Approved Time Off" and "Difference" values are wrong.

With the given exemples, we'll see Feb 9 and Feb 11 with "Approved Time Off" values of 12hrs, which is wrong since the employee is supposed to work 8hrs a day, so he should have a time off of also 8hrs.

# Cause
The calculation for "Approved Time Off" is the following :
Divide the `number_of_hours` of a hr_leave
By the number of working days during the period of the leave

Using our exemple, we get :
`number_of_hours` = 24hrs
number of working days = 2
Approved Time Off = 24hrs / 2 => 12hrs, but we expect 8hrs

The `number_of_hours` is correct since we checked "Ignore Public Holidays" (which actually means : include the public holidays in the number of hours of a leave)

The problem is that the aggregation for the number of working days excludes automatically
public holidays, without paying attention to the value of "Ignore Public Holidays" :
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L193-L202
Explanation for this part of the query : we only keep days where there is no record in
resource_calendar_leaves (`WHERE rcl2.id IS NULL`)  that contains that day
and that are considered public (`AND rcl2.resource_id IS NULL`)

# Proposed Solution
We add a `JOIN hr_leave_type` to be able to get the value for
`include_public_holidays_in_duration` ("Ignore Public Holidays").

Then, we make it so we exclude the Public Holidays only if that value is
false (`AND NOT lvt.include_public_holidays_in_duration`)

opw-6082422

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

Forward-Port-Of: odoo/odoo#258963

When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times.

Steps to reproduce:
-------------------
* Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule"
* Create three products : final, semi, component
   - final: mtso, manufacture
   - semi: mtso, manufacture
   - component: mtso, buy, on hand quantity to 4
* Create a bom for final:
   - 10 components
   - 1 semi
* Create a bom for semi:
  - 10 components
* Create and confirm a MO for 1 "final"
-> Issue the purchase order is only for 12 components and not 16.

Observation:
-------------
When confirming our MO, it will create a manufacture procurement for the products.
The procurement will recursively create procurements and stock moves for each of its components.
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571
Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity:
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663
And each procurement, if it is of the manufacture type, will create corresponding procurements for their components.

Once all the procurements and stock moves have been created, the stock move will confirmed and assigned.
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629


-> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels.

opw-5514788

Forward-Port-Of: odoo/odoo#253958

### Issue before this commit:
When sending a payment reminder email for a subscription using the email composer, the template  was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing.

### Steps to reproduce the issue:
1. Install subscription and go to that app
2. Open one subscription
3. Send message > Load template: "Subscription: Payment Reminder"
4. Sentence is incomplete: missing end date of the subscription

### Cause of the issue:
The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template.

### Reason to introduce the fix:
The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer.

opw-6031613

Forward-Port-Of: odoo/enterprise#111801

Some countries lile Estonia, Nederlands or France apply a rounding from
the tax report by adding a line to the end of the query results representing
the sum of the roundings on each line of the tax report.

When having a company with branches, the rounding is applying in each
closing move (one per company/branch) but the value is coming from the
aggregated report lines, this leads to wrong computation of the closing
entries.

Cause:

In `_generate_tax_closing_entries` we loop over each company, therefore
`_compute_tax_closing_entry` is called one time for each company, but it
uses the report options containing all companies

Fix:

Use options with only the current company in
`_compute_tax_closing_entry`

Steps:

- Install FR localisation
- Select FR company and create two branches
- Create, for last month:
  - 1 bill for parent company (100 with tax 20% G)
  - 1 invoice per branch (200 and 300 with tax 20% G)
- Create a tax return with opining date at the beginning of the current
  month
- Submit the last return and go to the created closing entries
-> See that closing entries are wrong

opw-5976359

Forward-Port-Of: odoo/enterprise#110652

Since the Accounting Returns refactor https://github.com/odoo/enterprise/pull/81569 the “Returns” button and the Return-Period date mode only appear when the current `account.report` carries at least one return type (i.e., `self.return_type_ids` is non-empty). Localization modules (e.g., PE) attach `account.return.type` to the filing (root) VAT report, while ledger/variant reports (e.g., VAT Report (RCE Purchase 8.5) (PE)) are presentation variants and usually do not repeat that configuration.

As a result, opening a variant report yields:
No Returns button, because _init_options_buttons() checks only `self.return_type_ids`. No Return Period chip and wrong/no return-period boundaries, because the date initializers also check/use only `self.return_type_ids`. Even if the button is shown by a downstream customization, `action_open_returns() would still open an empty list because it filters on `self.return_type_ids.ids`.

Why the issue happens:
Variant reports (like RCE 8.5) have `self.root_report_id` pointing to their root VAT report, which does carry `return_type_ids`. But the in odoo we  checks/uses only the current report’s`return_type_ids`, which is empty on variants. Hence: missing Returns button, missing Return Period, and wrong/empty return filtering.

Fix:
Adopt the reporting engine’s existing “inherit from root when on a variant” pattern and its already used elsewhere for `variants_source_id`, custom handlers ...

Introduce a tiny helper: Prefer explicit types on the current report if present; otherwise fall back to the root’s types. Replace direct uses of self.return_type_ids by the effective types in: _init_options_buttons: show Returns on variants too. _init_options_return_periodicity: enable Return Period on variants when the root has exactly one type. _init_options_date(return-period branch):  compute correct boundaries from effective types. _get_shifted_dates_period(return-period branch): shift using effective types. _get_date_bounds_info(..., 'previous_return_period'): validate count and compute previous period from effective types. action_open_returns: filter the list view by the types of variants if present or the root  instead if the variant’s empty.

Before this commit:
On VAT Report (RCE Purchase 8.5) (PE): no Returns button is shown when you are in variant.

After this commit:
Returns button appears.
Return Period mode works
Open Returns action lists the correct returns (filtered by the effective type).

Steps to reproduce:
Install PE_reporting module
make sure dev move is on
Accounting -> Reporting -> tax reports
Click on reports and switch from `Report: Group by: Account > Tax` to `RCE Purchase 8.4` Return Button is not there any more :(

[opw-4973204](https://www.odoo.com/odoo/my-tasks/4973204)

Currently, a ParseError is arising when the user upgrades the `hr_payroll` module after deleting the `Worker` in Structure Types.

Steps to Reproduce:
---
- Install `Payroll` module (without demo data).
- Payroll > Configuration > Structures > Delete `Worker Pay`
- Configuration > Structure Types > Delete 'Worker'
- Now upgrade the `Payroll` module

Traceback:
---
```py
ValueError: External ID not found in the system: hr.structure_type_worker

ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/hr_payroll/data/hr_payroll_structure_data.xml:15, somewhere inside <record id="structure_worker_001" model="hr.payroll.structure">
            <field name="name">Worker Pay</field>
            <field name="type_id" ref="hr.structure_type_worker"/>
```

At [1], we reference the ID of the `Worker` record. After deletion, that record no longer exists, which results in a ParseError.

Solution:
---
Users are restricted from deleting the Structure Type.

[1]- https://github.com/odoo/enterprise/blob/92ad37e25deeb1f9f1f24f85b085b575e70c0a5d/hr_payroll/data/hr_payroll_structure_data.xml#L15-L20

sentry-6377659355

### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#253948
Forward-Port-Of: odoo/odoo#253406

Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee.

It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have:
```
+--------------+
| Shift1 User1 |
+--------------+
```
Add another shift (Shift 2) with User2.
We'll have:
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User1 |
+--------------+
```
instead of
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User2 |
+--------------+
```

Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value.

This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by
```html
<span>Employee</span><span class="..">(Department)</span>
```
in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it,
```xml
<span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/>
```
since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change.
Therefore, whenever a component's value changes
(in our case, Shift1 becomes Shift2), it is never updated.

In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution.

To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render.

opw-6128168

When a menu item URL contains a space and has no leading slash (e.g.,
"some url"), creating a page from its 404 screen does not link the menu
to the newly created page. The menu keeps pointing to a 404.


**Steps to reproduce**:
1. Create a menu item with a URL containing spaces and no leading slash
   (e.g., "some url").
2. Click the menu item -> a 404 page is displayed (expected).
3. Click "Create Page" -> the page is created and saved.
4. Click the menu item again -> it still returns a 404 (unexpected).


**Issue**:
During page creation, the path is slugified (e.g., "some url" ->
"/some-url"). The controller then tries to link the menu to the new page
by setting `page_id`. However, `pagenew()` only searches for menu URLs
with a leading slash, so a menu saved as "some url" is not found when
searching for "/some url". As a result, `page_id` is never set, and
`_clean_url()` keeps resolving the menu to "/some url" instead of the
page's actual URL "/some-url".

Menus without spaces (e.g., "mypage") have the same issue where
`page_id` is not set, but since `_clean_url()` prepends "/" and renders
"/mypage", which matches the new page URL, the menu still resolves
correctly.


**Fix**:
Match both URL formats (with and without leading slash) when linking a
menu to a newly created page.

Additionally, a warning is now shown in the menu editor when a URL
contains spaces, since spaces are slugified during page creation,
which could cause confusion. (Note: this is only a warning - URLs with
spaces are still allowed.)

task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646)

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

Forward-Port-Of: odoo/odoo#260726
Forward-Port-Of: odoo/odoo#248967

Before:
When a document template is signed using "Sign Now" on behalf of another user,
the certificate should show the line “Connected as ” for internal and portal
users. Previously, the Email verification note under Participants could appear
even when no email verification was actually done, for example when using
"Sign Now".
Additionally, the signature confirmation email did not clearly reflect when the
document was signed locally on behalf of others.

After:
When a document is signed using Sign Now on behalf of another user, the
certificate now shows the line "Connected as <LoggedUser>" for all users.
The Email verification note under Participants is shown only when email
verification actually happens Otherwise show  `Document was signed locally for
all signers using UserName's account`
- The signature confirmation mail is updated for local sign cases
 `..., while connected as <LoggedUser>`.

Impact:
- Clearly shows in the certificate when a document is signed by user for
  another user.
- Avoids showing Email verification information when it did not happen and
  displays the correct message instead.
- Improves clarity and accuracy of signature confirmation emails.

taskid-5343749

Steps to reproduce:
-------------------
1. Upload a logo on the company (Settings > Companies)
2. Go to Accounting > Review > Control > Journal Audit
3. Select a period having journal entries
4. Export the PDF

-> The company logo appears huge, taking almost the entire cover page, which shrinks the report content and makes it hard to read.

Why the bug
-----------
In e8d2084369d the logo was added to the `company_information` template with a global css rule `.o_company_logo { max-height: 4rem }`, so the size was correct on every pdf using this template, including the journal report pdf.

Later, 684f741120e scoped that rule under `.o_content`. From that point, the rule only applies when the pdf wrapper has the `o_content` class, which is not the case for the journal report, which wraps its content with `journal_report_pdf` instead.

The fix
-------
Add the same max-height rule directly under `.journal_report_pdf`. That way, we keep the changes minimal and well targeted for the journal report, to not risk breaking any other styles.

opw-6102598

Steps to reproduce
==================

- Install hr_payroll
- Use a mobile viewport
- Go to Employees
- Open a record
- Switch to the Salary Adjustments notebook tab

=> TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)'

Cause of the issue
==================

The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used)

See

https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212

Solution
========

Since there is no delete action on the kanban view, there is no need for an override.

While we are at it, there was no kanban view defined. Thus a default view was used

https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846

It only contained the field description. Since that one is optional, records without a description were almost invisible..

Thus we also add a basic kanban view

opw-6047295

Currently, an error occurs when entering a URL for the Document on the website.

Steps to Reproduce:

 - Install the `Website` module.
 - Go to the `Website` and click `Edit`.
 - Insert an `image` block.
 - Double-click on the image > `Documents` > enter this URL: `file:///C:/Users/sagar/Downloads/op.webp`

`InvalidSchema: No connection adapters were found for 'file:///C:/Users/sagar/Downloads/op.webp'`

This error occurs when the user enters a URL that does not point to a valid document or does not follow a valid schema. This caused an exception in the HEAD request during header retrieval [1].

[1] https://github.com/odoo/odoo/blob/07626050bd0104fecd8799b56d30245d00da3f27/addons/html_editor/controllers/main.py#L255

This commit ensures that the URL is evaluated safely during the HEAD request. If the user enters a document URL with a invalid schema, a UserError is raised.

sentry-6726490037


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

The system crashes with the error because a certificate record exists (cert_sudo is not None), but the pem_certificate field is False. This is because of a user uploaded invalid format certificate.

**Steps to Produce:-**
1. Install `l10n_co_edi` then change the company to `co company`.
2. `Settings > Certificates and Keys > Manage Your Certificates > Certificates`.
3. Add a new certificate using an invalid file (`other than .der, .pkcs12, or .pem content format`)and fill in the other required details.
4. Open any journal of type Sales or Purchase.
5. Go to `Advanced Settings` and click the `Reload DIAN Configuration` button.

**Traceback:-**
```py
  File "/home/odoo/odoo18/community/odoo/http.py", line 2554, in __call__
    response = request._serve_db()
  File "/home/odoo/odoo18/community/odoo/http.py", line 2081, in _serve_db
    return self._transactioning(
  File "/home/odoo/odoo18/community/odoo/http.py", line 2144, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 156, in retrying
    result = func()
  File "/home/odoo/odoo18/community/odoo/http.py", line 2111, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo18/community/odoo/http.py", line 2359, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo18/community/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo18/community/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo18/community/addons/web/controllers/dataset.py", line 42, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo18/community/odoo/api.py", line 535, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "/home/odoo/odoo18/enterprise/l10n_co_dian/models/account_journal.py", line 129, in button_l10n_co_dian_fetch_numbering_range
    response = xml_utils._build_and_send_request(
  File "/home/odoo/odoo18/enterprise/l10n_co_dian/xml_utils.py", line 133, in _build_and_send_request
    'binary_security_token': cert_sudo._get_der_certificate_bytes(formatting='base64').decode(),
  File "/home/odoo/odoo18/community/addons/certificate/models/certificate.py", line 282, in _get_der_certificate_bytes
    cert = x509.load_pem_x509_certificate(base64.b64decode(self.with_context(bin_size=False).pem_certificate))
  File "/usr/lib/python3.10/base64.py", line 80, in b64decode
    s = _bytes_from_decode_data(s)
  File "/usr/lib/python3.10/base64.py", line 45, in _bytes_from_decode_data
    raise TypeError("argument should be a bytes-like object or ASCII "
TypeError: argument should be a bytes-like object or ASCII string, not 'bool'

```
        
**Solution:-**
- We added a constraint method to ensure that the `content_format` of a certificate is one of the allowed types: `'der', 'pkcs12', or 'pem'`. This helps prevent saving records with unsupported or invalid certificate formats.

**Sentry - 6373511231,6842736554,6851901831**

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

Flexible calendar intervals are computed with date-only boundaries, which can shift the range used for worked time calculations.

### **Steps to reproduce:**
1) Install hr_payroll
2) Create a flexible working schedule with 56 hr per week and 8hrs avg per day 
3) Create an employee with this working schedule and joined from `16th Feb 2026`. 
4) Create a payslip for this employee for the February period.

### **Observed Behavior:**
"out of contract"  working hours are 120:59hr
<img width="1213" height="406" alt="image" src="https://github.com/user-attachments/assets/3f7104fb-3a59-48e3-aaf6-052dcf18c0c0" />

### **Expected Behavior:**
"out of contract"  working hours should be 120hr
<img width="1225" height="429" alt="image" src="https://github.com/user-attachments/assets/98898b16-4e36-4a30-9460-633f32c53ec3" />


### **Root Cause:**
The flexible calendar interval computation trims the interval boundaries by converting them to dates at [1], and assumes `end_datetime` is always midnight at [2]. This ignores timezone effects, depending on the user timezone, `end_datetime_adjusted`, may still fall on the same day, so an extra day can be included in the computation. This produces incorrect worked-hours totals for flexible calendars.

[1]- https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/resource/models/resource_calendar.py#L387-L389

[2]- https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402

### **Fix:**
Keep the full datetime values when computing flexible calendar intervals.

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

**opw-6017569**

Currently, an error occurs when closing a tab with a new (unsaved) record.

**Steps to replicate Error- 1:**
- Install `hr`.
- Open Employees and click new.
- Give a name and close the tab (without saving).

**Error:**
`KeyError: 'name'`

----

**Steps to replicate Error- 2:**
- Install the `Time Off` module.
- Go to `Time Off > Management > Time Off`.
- Click on New and select an employee and close the tab.

**Error:**
`KeyError: None`

---

**Cause:**
- When closing the tab, the browser triggers both `visibilitychange` [1] and `beforeunload` [2].
- Both attempted to save, resulting in duplicate create calls — one with a valid payload and the other empty which leads to error at line [3].

**Solution:**
- Skip the `beforeunload` urgent save if the record has no `resId`. This ensures that only existing records are saved at tab close.
- Because `beforeunload` is called after `visibilitychange` so we let `visibililitychange` handle the save for new records.

[1]: https://github.com/odoo/odoo/blob/6e6f2a0bc8b6b1dc3ef5f203530c6fb82a67132a/addons/web/static/src/views/form/form_controller.js#L467-L471

[2]: https://github.com/odoo/odoo/blob/6e6f2a0bc8b6b1dc3ef5f203530c6fb82a67132a/addons/web/static/src/views/form/form_controller.js#L482-L488

[3]: https://github.com/odoo/odoo/blob/6e6f2a0bc8b6b1dc3ef5f203530c6fb82a67132a/addons/hr/models/hr_employee.py#L476

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

Currently, an error occurs when user writes an invalid model name in snailmail.

Steps to replicate:
- Install mail and open snailmail letters.
- Type `test` in the model field, add a recipient and save.

Error:
`KeyError: 'test'`

Cause:
- As the model name was given as `test` the [line] throws error as no model with the name 'test' exists in the environment.

Solution:
- Added a function to check if the model exists in the environment, along with an existence check for the document ID.
- Also added a compatibility check to ensure the model works with snailmail.

Note:
- In this scenario where the `create()` method is overridden and the error occurs before the `super()` call, we cannot add a python constraint as the constrains are called by the `_create()` in the orm. 
[1] -> [2]
[2] -> [3]
[3] -> [4]

[1]: https://github.com/odoo/odoo/blob/9d965abb992d558ea4235ef5f87a7654c6f1ceae/odoo/orm/models.py#L4705-L4706

[2]: https://github.com/odoo/odoo/blob/d088dbad84492234ae792b76545497c6cd62e4f4/odoo/orm/models.py#L4943-L4944

[3]: https://github.com/odoo/odoo/blob/d088dbad84492234ae792b76545497c6cd62e4f4/odoo/orm/models.py#L1253-L1258

[4]: https://github.com/odoo/odoo/blob/d088dbad84492234ae792b76545497c6cd62e4f4/odoo/orm/models.py#L518-L520

[line]: https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/snailmail/models/snailmail_letter.py#L92

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

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Currently, an error occurs when importing the SAF-T file into accounting.

Steps to Reproduce:

 - Install the `account_saft_import` and `accountant` modules.
 - Create a `new company` with the country set to `Denmark`, and `switch` to this company.
 - Go to `Settings` > `Accounting`, and click `Import` under Accounting Import.
 - Click `Import SAF-T`, enable Import account opening balances, and upload [this file](https://drive.google.com/file/d/177zf_w3B8m3g2VlJkbDB-Zp61TbZuV5r/view)

`AttributeError: 'NoneType' object has no attribute 'update'`

This error occurs when importing the SAF-T file in accounting. The SAF-T XML does not include any <saft:Account> entries, so map_accounts is empty [1]. As a result, based on map_accounts here [2], it got None in data['account.move'], which causes the error in [3].

[1]
https://github.com/odoo/enterprise/blob/2f59dc2443833b0308fcd774a8008b8ebdce48fd/account_saft_import/wizard/import_wizard.py#L436

[2]
https://github.com/odoo/enterprise/blob/2f59dc2443833b0308fcd774a8008b8ebdce48fd/account_saft_import/wizard/import_wizard.py#L447

[3]
https://github.com/odoo/enterprise/blob/2f59dc2443833b0308fcd774a8008b8ebdce48fd/account_saft_import/wizard/import_wizard.py#L467

This commit ensures that it uses an empty object if it gets None.

sentry-6714182871

Currently, an error occurs when the `Snailmail: process letters queue` scheduled action is triggered.

Steps to reproduce:

 - Install the `website` and `account` modules.
 - Create a `Invoice` > `Confirm` > `Send` > check the `By Post` checkbox.
 - `Reset to Draft` newly created invoice and delete it.
 - Run the `Snailmail: process letters queue` scheduled action.

`MissingError: Record does not exist or has been deleted.
(Record: account.move(27,), User: 1)`

This error occurs when the user sends the invoice by post, which creates a Snailmail letter record related to the invoice. 
If the invoice is subsequently deleted, the Snailmail: Process Letters Queue scheduled action run and attempt to fetch 
the attachment of related snailmail letter and invoice[1] but the invoice is not exists [2] and raise a MissingError.

[1] https://github.com/odoo/odoo/blob/cc368d553cd94bee8b09d4981cb8f1dbc27a34b3/addons/snailmail/models/snailmail_letter.py#L149

[2] https://github.com/odoo/odoo/blob/420765c787b33f79ee8814f799de721508858319/addons/account/models/account_move.py#L3605

This commit ensures that the system evaluates the attachment only if the invoice also exists.

sentry-6635629791

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

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333