When checking if a stock.move.line can use a location as destination with the method `_check_can_be_used()`, we start by checking if the incoming products can be stored without exceeding the maximal weight of the location.

This needs to call the `_get_weight()` method to compute the forecasted weight for the location. This method relies on heavy computations and can become a bottleneck when we need to loop over a high number of locations.

In some cases, we can rule out the location based on less expensive conditions that are verified after the weight one.

We propose to invert the conditions check order to avoid computing the location weight when other conditions are not met.

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

- Install stock and purchase modules;
- Enable storage locations and categories in the settings;
- Create a storage category: allow_new_product = same, max_weight=10.0 kg;
- Create N locations using this category, parent_id=WH/stock;
- Create a putaway rule to each location from WH/stock, for the new storage category and using a product A with a weight of 2 kg;
- Create a stock.quant per location to store a product B, weight=2kg;
- Create a purchase order with X lines for 1 unit of product A;
- Validate the purchase order.

The validation should take several seconds to execute
as every locations will be rejected due to the storage
category, but it will call _get_weight() first.

Benchmark
---------------

This improvement is very data specific and will be most useful when a lot of locations are using a storage category of type "empty" or "same".
In addition, it also relies on the order in which we are treating the locations, if the acceptable locations are the first to be received in the method, it won't need to loop over all of them.

The following benchmark was established in a production database in which every 6068 locations are using a category of type "same".

| No stock.move.lines | Before PR | After PR |
|---------------------|-----------|----------|
|                  40 |     168 s |   7.3  s |
|                  72 |     264 s |  12.33 s |

When the only condition that can reject locations is the exceeding weight, this modification will slow down the process. However, the time loss in this case is smaller than the gain in the first case.
The following benchmark was obtained by validating a purchase 1 line order with only fully filled locations.

| No locations | Before PR | After PR |
|--------------|-----------|----------|
|          500 |     2.02s |   2.37 s |
|         2000 |     7.85s |   9.76 s |
|        10000 |   39.16 s |  48.86 s |

opw-5949370

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

Forward-Port-Of: odoo/odoo#270125
Forward-Port-Of: odoo/odoo#266872

**Problem:**
Two linked errors occur in the Phone (VoIP) softphone when a call is made to or received from a number that is not linked to any contact.

**Steps to reproduce:**
1. Receive or make a call from the softphone using a phone number that is not linked to any existing contact.
2. Open the call's actions and click "Create" > "Task". -> A client error appears and the task is not created.
3. On a voip.call form whose Contact has been removed, click the "Tasks" smart button. -> A server error is raised.

**Current behavior:**
Step 2 raises "Cannot read properties of undefined (reading 'id')" and step 3 raises "ValueError: not enough values to unpack (expected 1, got 0)".

**Expected behavior:**
Creating a task from a contactless call should open the task form without a default contact, and the Tasks smart button should not be reachable when the call has no contact.

**Cause of the issue:**
Both code paths assume a call always has a linked partner. In `action_list_patch.js`, `getCreateTaskAction` only checks `shouldShowTaskButton` in its predicate but reads `this.contact.id` in its `onClick`; for a contactless call `this.contact` is undefined. In `voip_call.py`, `action_view_tasks` delegates to
`self.partner_id.action_view_tasks()`, whose `ensure_one()` fails on the empty partner recordset. Unlike the softphone "view tasks" action, which is gated by `this.contact?.task_count`, the form stat button had no visibility guard.

**Fix:**
The create-task action now mirrors the existing contact and lead actions, which already build their context conditionally on `this.contact`, so a contactless call simply opens the task form with no default partner. The Tasks stat button is hidden when there are no tasks, matching the softphone predicate and ensuring the partner-less code path is never reached.

opw-6246641

Forward-Port-Of: odoo/enterprise#119412

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

Customers placing an order without logging in and with the "Pick up in store" delivery method are not notified when the delivery is confirmed

Steps to reproduce:
1. Install eCommerce and Sales
2. Go to Settings > Website > Delivery and enable "Click & Collect"
3. Go to Settings > Inventory > Shipping and enable "Email Confirmation"
4. Go to Website > Configuration > Payment Providers and Install Demo
5. Go to Website > Configuration > Delivery Methods and open "Pick up in store", set YourCompany as warehouse and publish it
6. Go to Sales > Products, open product "Office Lamp", click on "Update Quantity" in the status bar and add 5 units
7. Log out
8. Go to the shop, add product "Office Lamp" to the cart and checkout
9. Fill in the address form and continue checkout
10. Select "Pick up in store" as delivery method and select a location
11. Confirm the order and pay with Demo
12. As user Mitchell Admin, go to Sales, remove the default filter and open the newly created sale order
13. Open the related delivery with the smart button and validate it
14. No delivery order confirmation was sent to the customer (check emails)

Issue:
Pickup addresses are always inactive, preventing the partner from receiving email confirmation

Solution:
Disable archiving of pickup addresses

opw-6095396

Forward-Port-Of: odoo/odoo#265392
Forward-Port-Of: odoo/odoo#263005

In this commit:
------------------
- Maintain separate Fiskaly transaction flows for retail (short tx) and restaurant (long tx)
  orders as discussed with the Fiskaly team.
- `Initialize order transactions` with an empty payload when the `first product` is added.
- Start `receipt transactions` with an empty payload when the `first payment line` is added.
- For retail flows, no intermediate order updates are sent to Fiskaly before finalization.
- For restaurant flows, create additional transaction updates during kitchen synchronization.
  Ensure already synchronized products are not resent, and only newly added or updated
  quantities are included in the payload.
- `Finalize order and receipt transactions` with complete order lines and payment details
  when we validate the order.

task: 6208963

Reference:
<img width="1863" height="1285" alt="de_tss_flow" src="https://github.com/user-attachments/assets/9140788e-7948-4a08-9f11-27197b22ca8b" />

Forward-Port-Of: odoo/enterprise#120218
Forward-Port-Of: odoo/enterprise#117526

Version:
----------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Enable `Storage Locations` from Inventory settings
- Create a tracked storable product with on-hand 8 units in `Shelf 1`
- Create Delivery 1 for 5 units and click `Mark as To Do`
- Create Delivery 2 for 5 units and click `Mark as To Do`
- Verify reservations:
  - Delivery 1 reserves 5 units
  - Delivery 2 reserves remaining 3 units
- Relocate all 8 units from `Shelf 1` to `Shelf 2` using the `Relocate` action from `stock quant`
- Reopen both deliveries

Issue:
------
After relocating stock between internal locations, reservations are reassigned
in the wrong order:
- Delivery 2 becomes fully reserved with 5 units
- Delivery 1 is reduced to 3 reserved units

This incorrectly swaps the original reservation priority between deliveries.

Cause:
------
The relocation wizard starts from:
`stock.quant.relocate.action_relocate_quants()`
which calls `move_quants()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/wizard/stock_quant_relocate.py#L70

`move_quants()` validates an internal stock move through `_action_done()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_quant.py#L1572

During validation, `_synchronize_quant()` moves the stock quantity from
`Shelf 1` to `Shelf 2`.

However, the already reserved delivery move lines still reference `Shelf 1`.
This temporarily makes the source quant negative (`available_qty < 0`),
triggering `_free_reservation()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L695-L700

Inside `_free_reservation()`, move lines are ordered using
`current_picking_first`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L816-L821

Since both deliveries share the same scheduled date, the fallback ordering
uses `-cand.id`, causing Delivery 2 (higher id) to be processed before
Delivery 1 (lower id).

The reservation cleanup therefore happens in this order:
- Remove Delivery 2 reservation (3 qty)
- Remove Delivery 1 reservation (5 qty)

The corresponding moves are then added to `move_to_reassign`
in the same order:
`[Delivery 2, Delivery 1]`
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L849

Later, `move_to_reassign._action_assign()` processes the moves in recordset
order:
- Delivery 2 reserves 5 units first
- Delivery 1 only gets the remaining 3 units

As a result, reservation priority is unintentionally reversed after relocation.

Fix:
----
Before calling `_action_assign()`, reverse `move_to_reassign` 

This ensures reassignment preserves the original reservation order:
- Delivery 1 is reassigned first and recovers 5 units
- Delivery 2 receives the remaining 3 units

The reservation state therefore remains consistent before and after
internal stock relocation.

---

opw-6218256

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

Forward-Port-Of: odoo/odoo#269973
Forward-Port-Of: odoo/odoo#265169

When checking if a stock.move.line can use a location as destination with the method `_check_can_be_used()`, we start by checking if the incoming products can be stored without exceeding the maximal weight of the location.

This needs to call the `_get_weight()` method to compute the forecasted weight for the location. This method relies on heavy computations and can become a bottleneck when we need to loop over a high number of locations.

In some cases, we can rule out the location based on less expensive conditions that are verified after the weight one.

We propose to invert the conditions check order to avoid computing the location weight when other conditions are not met.

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

- Install stock and purchase modules;
- Enable storage locations and categories in the settings;
- Create a storage category: allow_new_product = same, max_weight=10.0 kg;
- Create N locations using this category, parent_id=WH/stock;
- Create a putaway rule to each location from WH/stock, for the new storage category and using a product A with a weight of 2 kg;
- Create a stock.quant per location to store a product B, weight=2kg;
- Create a purchase order with X lines for 1 unit of product A;
- Validate the purchase order.

The validation should take several seconds to execute
as every locations will be rejected due to the storage
category, but it will call _get_weight() first.

Benchmark
---------------

This improvement is very data specific and will be most useful when a lot of locations are using a storage category of type "empty" or "same".
In addition, it also relies on the order in which we are treating the locations, if the acceptable locations are the first to be received in the method, it won't need to loop over all of them.

The following benchmark was established in a production database in which every 6068 locations are using a category of type "same".

| No stock.move.lines | Before PR | After PR |
|---------------------|-----------|----------|
|                  40 |     168 s |   7.3  s |
|                  72 |     264 s |  12.33 s |

When the only condition that can reject locations is the exceeding weight, this modification will slow down the process. However, the time loss in this case is smaller than the gain in the first case.
The following benchmark was obtained by validating a purchase 1 line order with only fully filled locations.

| No locations | Before PR | After PR |
|--------------|-----------|----------|
|          500 |     2.02s |   2.37 s |
|         2000 |     7.85s |   9.76 s |
|        10000 |   39.16 s |  48.86 s |

opw-5949370

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

Forward-Port-Of: odoo/odoo#270125
Forward-Port-Of: odoo/odoo#266872

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

*= test_l10n_us_hr_payroll_account

The employer matching cap for pre-retirement plans (401KMATCHING) evaluates to zero for hourly wage employees if wage is set to zero.

### **Steps to Reproduce:**
1) Install l10n_us_hr_payroll.
2) Create an employee with an hourly wage and set the fixed wage to 0. 
3) Configure the retirement plan parameters as follows:
  - 401(k) = 3%
  - Matching Amount = 100%
  - Matching Yearly Cap = 100% 
4) Generate a payslip for this employee and compute the sheet.

### **Observed Behavior:**
The "Benefits Matching to Retirement Plans" line computes as zero for the hourly employee.

### **Expected Behavior:**
The employer matching contribution should dynamically scale based on the actual gross pay period earnings instead of evaluating to zero.

### **Root Cause:**
The calculation of `partial_cap` uses `version.wage` directly at [1]. For hourly employees, the fixed 'wage' field defaults to zero, causing the entire multiplication to cancel out.

[1]- https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L167

### **Fix:**
This commit computes the retirement matching eligibility cap from
`gross annualized wages` and applies the employer matching percentage on
the eligible contribution amount. This ensures retirement matching is
calculated consistently regardless of the employee's contract type.

**opw-6181024**

Forward-Port-Of: odoo/enterprise#120483
Forward-Port-Of: odoo/enterprise#119370

resource_calendar was not being when calculting virtual leaves, it leads to a singleton error here:
https://github.com/odoo/odoo/blob/11b0195dddad5055fc33fa3e28b2d2ca60f24935/addons/l10n_fr_hr_holidays/models/hr_leave.py#L163

```
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 519, in _table_sql
    table_query = self._table_query
                  ^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 40, in _table_query
    self._compute_leave_duration(report_records)
   File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 94, in _compute_leave_duration
    leaves_durations = virtual_leaves._get_durations(additional_domain=[('holiday_id', 'not in', leave_ids)])
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/l10n_fr_hr_holidays/models/hr_leave.py", line 160, in _get_durations
    while not leave.resource_calendar_id._works_on_date(date_start):
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/resource/models/resource_calendar.py", line 877, in _works_on_date
    self.ensure_one()
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5253, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
 ValueError: Expected singleton: resource.calendar()
```

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

Summary
=======

`_check_if_used_in_website_form`, the ondelete hook on
`ir.model.fields` that guards against deleting a field referenced by
a website form, performs poorly on realistic databases. It can take
multiple minutes to validate a single field deletion, blocking user
actions such as removing a Studio field.

This commit restricts the scan to columns that can actually contain
website form markup, bringing the hook from multi-minute to
sub-second without any loss of coverage.

The Problem
===========

Deleting any `ir.model.fields` record triggers this validation hook,
which must ensure the field is not referenced inside any website
form. The implementation iterates every stored HTML column returned
by `website._get_html_fields()` and runs one case-insensitive
`ILIKE '%data-model_name="<model>"%'` search per column against
`<model>.<html_field>`, then parses each match with `lxml` and
validates it with XPath.

Two root issues cause the multi-minute cost:

- **Unbounded scan surface**: all stored HTML columns are scanned
  (~95 on realistic databases), even though the vast majority of them
  declare `sanitize=True` and `sanitize_form=True` (the defaults).
  When both flags are True, `<form>` tags are stripped on write and
  the column can never physically contain website form markup.
- **Per-column `ILIKE` cost**: `ILIKE` on large TEXT/JSONB columns
  performs a sequential scan. A single large HTML column is enough
  to make the hook run for several minutes on its own.

Improvements
============

- Scan only columns that can actually contain forms:
  - `ir.ui.view.arch_db` , primary target; all website forms are
    stored there.
  - HTML fields whose sanitization either is disabled
    (`sanitize=False`, e.g. `blog.post.content`,
    `website.custom_code_head`) or explicitly allows forms
    (`sanitize_form=False`, e.g.
    `product.template.website_description`, `hr.job.description`,
    `event.event.description`). Any other HTML field strips `<form>`
    on write and will never contain a form.
- Batch searches: group the deleted fields by model once and emit a
  single `OR`-domain search per candidate column, instead of one
  search per (field, column) pair.
- Parse each returned record with `lxml` and validate with XPath
  directly. The `ILIKE` domain already filters out non-matching rows
  DB-side.

Benchmarks
==========

Profiled on a database containing ~95 stored HTML columns and ~5.2k
views. The hook was invoked read-only via
`field._check_if_used_in_website_form()` on a custom field.

| Metric                         |     Before |      After |
| :----------------------------- | ---------: | ---------: |
| Hook wall time                 |     ~444 s |    ~173 ms |
| HTML columns scanned           |         95 |          5 |
| SQL queries issued             |         96 |          6 |

Key results:

- Hook wall time reduced from multi-minute to sub-second
  (~2,570× faster on the profiled database).
- Scan surface reduced from ~95 columns to a handful (1 +
  the form-capable HTML fields installed on the database, typically
  under 10).

opw-6086536

Forward-Port-Of: odoo/odoo#268666
Forward-Port-Of: odoo/odoo#259846

Steps to reproduce:
--------------------------------------------
1. Install `website_project` module
2. Create a new project
3. Add a customer to the project
4. Go to customer > add email and phone
5. Create a new task in that project:
    * Observe that the customer is the same as the project
6. Go to Website > Contact Us > Edit > Click on submit button
7. Set action to 'Create a Task' and select the created project in 'Project'
8. Click on Save and Open the URL in Incognito Mode
9. Go to the Contact Us page > Fill in the details > Submit
10. Comeback to our window and open tasks of the created project

Observation:
--------------------------------------------
1. A new task is created using the customer details entered in the form.
2. The existing task’s customer and the project’s customer are also incorrectly updated to this new customer.

Issue:
--------------------------------------------
The bug is in the `extract_data` method of the website form controller for projects.
A non-logged-in user submits the Contact Us form with name and an email that doesn't match any existing partner. The old code's `else` branch would set `partner_name` in the task record values without setting a `partner_id` https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/controllers/main.py#L65-L66

During task creation, the computed field `_compute_partner_id` automatically sets `partner_id` to the project's partner
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/project/models/project_task.py#L1440-L1441

`partner_name` is defined as
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/models/project_task.py#L12

In Odoo, a related field is essentially a shortcut to a field on a linked record The key attribute here is `readonly=False`. This tells Odoo:
    * On read: Get the value from `self.partner_id.name`
    * On write: Propagate the write back to `self.partner_id.name` (this is the inverse). So writing `task.partner_name = 'TEST'` is equivalent to writing `task.partner_id.name = 'TEST'`. It modifies the partner record itself, not just the task.

So, the partner record itself was renamed. Every record that references a partner now sees the new name

Solution:
--------------------------------------------
The fix passes `False` to `partner_id`, this way:
    * The existing partner is untouched
    * All other tasks and the sales order keep their correct customer

opw-6206080

Forward-Port-Of: odoo/odoo#264738

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Forward-Port-Of: odoo/enterprise#119754
Forward-Port-Of: odoo/enterprise#118813

Version:
- 19.0

Steps to reproduce:
- Install Attendances and Time Off
- Create an internal user.
- Give the user: Attendances Officer access & No Time Off Officer/Manager rights
- Create an employee linked to the user.
- Configure the employee with a Flexible Working Schedule.
- Create and approve a Time Off request for the employee.
- Open: Attendances -> Gantt View
- Navigate to the month containing the employee's approved leave.

Issue:
- An access error is raised when opening a month that contains the employee's
  approved leave.

Cause:
- In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id`
  to read fields such as `request_unit_half`, `request_unit_hours`, and
  `request_hour_from/to` on the `hr.leave` model.
- When the current user has Attendances Officer rights but no Time Off
  access(rare cases), the ORM access check on `hr.leave` raises an AccessError,
  even though this read is purely for internal calendar computation and
  does not expose leave data to the user interface.
 
Fix:
- Added sudo() on holiday_id to access the employee's leave details
  and compute the work interval as expected.

Task-6264510

Forward-Port-Of: odoo/enterprise#119116

**Description**
Opening the Budget Report from any budget record times out on databases
with significant data volume. The request to
`budget.report/formatted_read_grouping_sets` consistently times out,
making the Budget Report completely unusable.

**Root cause:**
`budget.report` is an SQL view that consists of 5 UNION ALL branches.
When the list view loads, the ORM translates the `budget_analytic_id`
domain into a WHERE clause on the outer query wrapping the full UNION
ALL subquery. PostgreSQL cannot push this filter through a UNION ALL as
it's a hard optimization barrier. It must fully materialize the subquery
regardless of which budget is being viewed.

**Fix:**
Override _search on budget.report to extract budget_analytic_id and
budget_line_id conditions from the incoming domain using the Domain API.
budget_line_id is rewritten as Domain('id', op, value) so _to_sql()
correctly emits bl.id in the raw SQL. The resulting domain is injected
in context under budget_line_domain and read in _get_bl_query,
_get_aal_query (base module), and _get_pol_query (purchase module) to
filter budget_line rows inside each branch's LEFT JOIN ON clause.
This also removes the budget_report_budget_line_ids context key from
budget_line._compute_all, unifying both filters under one mechanism.

---

On customer DB (568k `account_analytic_line`, 27k `budget_line`,
116k confirmed `purchase_order_line`, 114k posted vendor bill lines
with purchase link):

| Budget | Before | After |
|---|---|---|
| 8 lines, 730d span | timeout | 2.27s |
| 14 lines | timeout | 2.39s |
| 14 lines, 1095d span | timeout | 1.63s |

- Before: https://explain.dalibo.com/plan/ehed5eb8de251426
- After: https://explain.dalibo.com/plan/db8aef35cag9hg6f

opw-6098047

Forward-Port-Of: odoo/enterprise#114692

When checking if a stock.move.line can use a location as destination with the method `_check_can_be_used()`, we start by checking if the incoming products can be stored without exceeding the maximal weight of the location.

This needs to call the `_get_weight()` method to compute the forecasted weight for the location. This method relies on heavy computations and can become a bottleneck when we need to loop over a high number of locations.

In some cases, we can rule out the location based on less expensive conditions that are verified after the weight one.

We propose to invert the conditions check order to avoid computing the location weight when other conditions are not met.

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

- Install stock and purchase modules;
- Enable storage locations and categories in the settings;
- Create a storage category: allow_new_product = same, max_weight=10.0 kg;
- Create N locations using this category, parent_id=WH/stock;
- Create a putaway rule to each location from WH/stock, for the new storage category and using a product A with a weight of 2 kg;
- Create a stock.quant per location to store a product B, weight=2kg;
- Create a purchase order with X lines for 1 unit of product A;
- Validate the purchase order.

The validation should take several seconds to execute
as every locations will be rejected due to the storage
category, but it will call _get_weight() first.

Benchmark
---------------

This improvement is very data specific and will be most useful when a lot of locations are using a storage category of type "empty" or "same".
In addition, it also relies on the order in which we are treating the locations, if the acceptable locations are the first to be received in the method, it won't need to loop over all of them.

The following benchmark was established in a production database in which every 6068 locations are using a category of type "same".

| No stock.move.lines | Before PR | After PR |
|---------------------|-----------|----------|
|                  40 |     168 s |   7.3  s |
|                  72 |     264 s |  12.33 s |

When the only condition that can reject locations is the exceeding weight, this modification will slow down the process. However, the time loss in this case is smaller than the gain in the first case.
The following benchmark was obtained by validating a purchase 1 line order with only fully filled locations.

| No locations | Before PR | After PR |
|--------------|-----------|----------|
|          500 |     2.02s |   2.37 s |
|         2000 |     7.85s |   9.76 s |
|        10000 |   39.16 s |  48.86 s |

opw-5949370

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

Forward-Port-Of: odoo/odoo#270125
Forward-Port-Of: odoo/odoo#266872

*=l10n_ch_hr_payroll,hr_payroll_account_iso20022

When clicking the create payment report button on a payslip for a Swiss company,
a traceback occurs if the ``hr_payroll_account_iso20022`` module is not installed.

Steps to reproduce the error:
- Install ``l10n_ch_hr_payroll`` module
- Switch to CH Company
- Create an Employee and running contract for it
- Go to Payroll > Payslip > All payslips > Create a new payslip > Set the employee > Confirm > Create payment report

Traceback:
```py
ValueError: Wrong value for hr.payroll.payment.report.wizard.export_format: 'iso20022_ch'
```

https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip.py#L383 https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip_run.py#L13
Here, ``iso20022_ch`` is passed as ``export_format``,
However, ``iso20022_ch`` is added to the selection field in the ``hr_payroll_account_iso20022`` module at [1].
When that module is not installed, the selection value does not exist, leading to the above error.

[1]: https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L11

sentry-7391832811

Forward-Port-Of: odoo/enterprise#120295
Forward-Port-Of: odoo/enterprise#113277

Steps to reproduce:
--------------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company.
3. Create an employee and create a user with HR rights but without Payroll rights.
4. Log in with this new user.
5. Update any value on the employee form (e.g., marital status or add a tag).

Issue:
-----------
Updating the employee raises the following error:
```python
You do not have enough rights to access the fields "slip_ids" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 2
Fields:
- slip_ids (allowed for groups 'Payroll / Officer: Manage all contracts')
```

Cause:
---------
After this 4416eda, open payslips are recomputed automatically on every employee update:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L210-L213
`slip_ids` is restricted to payroll users:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/hr_payroll/models/hr_employee.py#L14 As a result, when an HR user without payroll rights updates an employee,
accessing slip_ids raises an **AccessError**.

Solution:
-----------
Use sudo() when accessing slip_ids so HR users can update employee records 
without issue.

**NOTE:**
The issue has been resolved from version saas~18.4 with the following commits:
279f09a9587674c035c514f966788a4dddfe9794 and  75d66d8

opw-6210358

Forward-Port-Of: odoo/enterprise#120019
Forward-Port-Of: odoo/enterprise#117387

Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead.

Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version.

Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug.

Upstream libmagic fixes:
- https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e
- https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e

Upstream python-magic issue:
- https://github.com/ahupp/python-magic/issues/354

runbot-938197

Forward-Port-Of: odoo/odoo#269506

Problem:
- `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled.
- Button padding, border radius, and background color are not rendered properly in Outlook Desktop.

Solution:
- Set the `height` attribute on `td.card-body` along with `valign` so columns keep the same height in Outlook Desktop.
- Use `v:roundrect` to support rounded corners (`arcsize`) and background colors (`fillcolor`), making buttons render consistently with the editor in Outlook Desktop.

Before:
<img width="1249" height="1297" alt="image" src="https://github.com/user-attachments/assets/828bc42b-1e21-404c-a5ae-81d4ee688802" />
After:
<img width="1249" height="1309" alt="image" src="https://github.com/user-attachments/assets/263a1c30-fe86-4e40-b3c2-476abc2bf84a" />

Steps to reproduce:
- Add the `s_three_columns` snippet with one card containing more content than the others.
- Add some buttons.
- Send or preview the email in Outlook Desktop.
- Observe that column heights and button styling are not rendered correctly.

opw-6044725

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

Forward-Port-Of: odoo/odoo#269791
Forward-Port-Of: odoo/odoo#269274

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120051

Follow-up of:
- https://github.com/odoo/enterprise/pull/119827
- https://github.com/odoo/enterprise/pull/120380

---

This PR review the overall frontdesk design to improve responsiveness and consistency across views.

task-6022341

| master | this PR |
|--------|--------|
| <img width="1021" height="765" alt="image" src="https://github.com/user-attachments/assets/d981f222-e3ce-42ae-9846-8eb05378fb46" /> | <img width="1022" height="769" alt="image" src="https://github.com/user-attachments/assets/4c49206b-3022-40bc-9ce6-e8e374156c6d" /> |
| <img width="1025" height="767" alt="image" src="https://github.com/user-attachments/assets/1b929595-c8fb-4863-9c02-2c4d8cd00376" /> | <img width="1023" height="766" alt="image" src="https://github.com/user-attachments/assets/750b4423-be14-4974-bdde-4a8e332e6f29" /> |
| <img width="1020" height="764" alt="image" src="https://github.com/user-attachments/assets/45cdad54-0654-4d86-a844-4b004400bab9" /> | <img width="1017" height="758" alt="image" src="https://github.com/user-attachments/assets/c848e800-5b4f-4a70-a718-d1d6d48ae411" /> |

### Steps to reproduce:

1. Create a product tracked by lot
2. Put 10 units in WH/Stock without lot
3. Inventory > Operations > Adjustments > Physical Inventory
4. Select the line referring to your product and request an inventory count + Show Expected Quantity
5. Open the barcode app > Count Inventory
6. Scan your product
#### > The line is not selected, in particular, next scans will be re-interpreted as product scans rather than new serial creation for your product.

### Cause of the issue:

Scanning your product search a line to select if any: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1432-L1435 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1630-L1632
However, the `findLine` will fail since this method calls the `_canOverrideTrackingNumber` to determine if the lot of the barcodData matches the one of the line:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1859-L1863
But, the override of the `_canOverrideTrackingNumber` method for the `BarcodeQuantModel` does not handle the absence of lotName in the barcodeData correctly as it does not consider that a line without lot can be overridden by an empty lotName:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_quant_model.js#L729-L731
Note however that the super call does:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L795-L798

### Issue 2:

### Steps to reproduce:

- Steps 1 -> 5
- Click on your product line to select it
- Scan a new lot to add one new unit referring to that lot
- Confirm (1)
- Apply Now
#### > User Error: Quant's editing is restricted, you can't do this operation

Since the line is selected, you have a currentLine during the `processBarcode` and hence the existing line will be updated using the `lotName``:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L1560-L1584 However, writing on the line will then try to write on the related quant during the validation process which will be forbiden since we are not allowed to change the lot of an existing quant:
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/stock/models/stock_quant.py#L351-L360 Now, the issue is that actually due to the nature of the line and of the barcode data, the line lot is not expected to be updated but rather a new line is expected to be created:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L795-L798

Additional issue:

Fixing issue 1 and 2 highlight and other issue of the validation process:

- Steps 1 -> 6
> The line gets selected
- Scan a newlot
> a new subline is added referring to 1 unit of your new quant
- Confirm (1) > Some serials where not counted, set them as missing
#### > Check your quants: the 10 unit lotless quant was not updated but a new quant for 1 units was created for your newlot

### Cause of the issue:

Applying all quantities is expecting to toggle them as counted before applying to update the existing quants:
https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L72-L82 https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L287-L296 However, only line tracked by serial numbers are set as counted: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L60-L63

opw-6212923

Forward-Port-Of: odoo/enterprise#118373

…unt number

When a provider returns an account without `account_number` (typical for Canadian banks, which do not use IBANs), the existing-journal search ran with `bank_account_number = False`. Because `bank_account_number` is a related field on `bank_account_id.account_number`, that search matched every bank journal in the user's allowed companies whose `bank_account_id` was unset.

If any of those journals was tied to a connected online link, the new sync was blocked with the misleading error "There's already a synchronized journal linked to this IBAN", even though no IBAN was involved.

Skip the search entirely when `account_number` is falsy: without an identifier there is nothing meaningful to dedup against, and the downstream code already handles `existing_journals` being empty by creating a fresh journal.

Note: when the provider omits `account_number`, a delete-and-recreate of the connection will now create a fresh journal rather than coincidentally reusing an unlinked empty-`bank_account_number` journal. That reuse path already failed (with a spurious "IBAN already connected" error) as soon as the user had more than one such journal, so the prior behavior was not reliable. The supported recovery path remains the reconnect button on the existing journal, which uses the `active_id` branch and is unchanged.

opw-6253563

Forward-Port-Of: odoo/enterprise#119848

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119760
Forward-Port-Of: odoo/enterprise#118759

[FIX] account_reports: only restore horizontal group from previous_options when it's available

The 'Ledger' group will only be available when in multicompany or using different journal groups. It was still restored from previous options, even when it shouldn't have been available.


=============================================


[FIX] account_reports: properly compute Ledger group when there's no journal group

To reproduce the issue

1) Populate the db with some data impacting the Balance Sheet
2) Delete all the journal groups that would be created by default
3) Open the Balance Sheet, with multiple companies active.
4) Select the "Ledger" horizontal group
====> The report is displayed horizontally grouped by company, but all amounts are 0.

This happens because, when no journal group exists, the "Ledger" horizontal group creates a column group per company, applying a domain doing ('journal_id', 'in', []), so nothing matches. This is caused by the fact that, in this case, options['journals'] will require to match all journals, and will hence be an empty list. We fix it by properly searching for all journals to build the horizontal group's domain when options['journals'] is empty.

Forward-Port-Of: odoo/enterprise#119418

Steps to reproduce
---
1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56").
2. Map the columns to Debit and Credit and import.

The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00.

Issue
---
This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed.

`account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`:

https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8

Because they are now real fields, the generic importer already converts those columns to floats:

https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285

The CSV statement wizard then parses the same columns a second time:

https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93

The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice.

Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present.

opw-6227083
---

Forward-Port-Of: odoo/enterprise#118979

[FIX] hr_appraisal: fix auto-fill of employee in appraisal

Bug production:
    1 - employee app -> department -> select employees -> select any employee -> use appraisal smart button in top -> employee_id is not coming

Bug cause:
    1 - When we press smart button of appraisal action_send_appraisal_request in hr_employee is called.
    2 - It send the self.env.context as a context and active_model and active_id.
    3 - In hr_appraisal, _get_default_employee function calculates the default employee_id by looking to context and especially by looking to active model and id.
        3.1 - If active_model is hr.employee and there is active_id, it finds the employee automatically (that is the case when we are coming directly from employee -> smart button hr_appraisal)
        3.2 - When we first click to department and then we click to employee and smart button, active_model is hr.department and default_employee_id cannot be calculated in default version.

Bug solution:
    1 - I have passed the default_employee_id to the context in action_send_appraisal_request function. Since we know the employee in the action_send_appraisal_request function we can pass it directly.

task - 6285434

Forward-Port-Of: odoo/enterprise#119737

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

Forward-Port-Of: odoo/enterprise#120492
Forward-Port-Of: odoo/enterprise#119084

## **Steps to Reproduce:**
1) Install `l10n_ch_hr_payroll`, `hr_payroll_account_iso20022` with demo data. 
2) Switch to the Swiss company and rename it.
3) create employee with address in switzerland and setup bank details with
   running contract.
4) Generate a payrun, validate it, then download the Swiss payment report.

#### **Note: Detailed video to generate this issue on v18 is attached on the ticket**

## **Obeserved Behavior:**
The report still uses the old company name instead of the renamed one.

## **Expected Behavior:**
The report should use the current company name.

## **Root Cause:**
In the payment report the `iso20022_initiating_party_name`, is set using
`iso20022_get_company_name` method at [1] and `iso20022_initiating_party_name`
was only initialized on `create` at [2], so later company renames did not
update the stored initiating party name when it matched the previous company name.

[1]- https://github.com/odoo/enterprise/blob/a86b98ea4fbc060cbe2666bc87f215a680ce54e7/account_iso20022/models/account_journal.py#L442-L446

[2]- https://github.com/odoo/enterprise/blob/7df2e86541a69d3160bc7165223227bde70d7291/account_iso20022/models/res_company.py#L16-L24

## **Fix:**
Update the stored ISO20022 initiating party name on company write whenever it still matches the previous sanitized company name.

**opw-6159675**

Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead.

Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version.

Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug.

Upstream libmagic fixes:
- https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e
- https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e

Upstream python-magic issue:
- https://github.com/ahupp/python-magic/issues/354

runbot-938197

Forward-Port-Of: odoo/odoo#269506

Problem:
- `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled.
- Button padding, border radius, and background color are not rendered properly in Outlook Desktop.

Solution:
- Set the `height` attribute on `td.card-body` along with `valign` so columns keep the same height in Outlook Desktop.
- Use `v:roundrect` to support rounded corners (`arcsize`) and background colors (`fillcolor`), making buttons render consistently with the editor in Outlook Desktop.

Before:
<img width="1249" height="1297" alt="image" src="https://github.com/user-attachments/assets/828bc42b-1e21-404c-a5ae-81d4ee688802" />
After:
<img width="1249" height="1309" alt="image" src="https://github.com/user-attachments/assets/263a1c30-fe86-4e40-b3c2-476abc2bf84a" />

Steps to reproduce:
- Add the `s_three_columns` snippet with one card containing more content than the others.
- Add some buttons.
- Send or preview the email in Outlook Desktop.
- Observe that column heights and button styling are not rendered correctly.

opw-6044725

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

Forward-Port-Of: odoo/odoo#269791
Forward-Port-Of: odoo/odoo#269274

Currently, access rights for `mail.message` rely on a set of layered rules. If an administrator attempts to manage (edit, delete, or duplicate) a message record—and fails all of these contextual evaluations, they are ultimately blocked by an AccessError.

For example:
- Mitchell Admin sends a mass mailing via CRM app.
- The email fails to send.
- Marc Demo (an administrator with no access to CRM) tries to edit, delete, or duplicate the failed email. Because he fails the specific contextual access rules for that message, he is blocked.

This behavior is overly restrictive. Administrators already possess the power to elevate their privileges, grant themselves access to any app, or log in as other users. Blocking them from managing critical communications (like a stalled mass mailing queue) forces them to use unnecessary workarounds.

This commit resolves the issue by short-circuiting the `_check_access` method. If the environment is in admin mode (`self.env.is_admin`), we bypass the complex rule evaluations entirely and grant immediate access.

We specifically implemented this via a Python override rather than modifying `ir.rule` records in `security.xml`. This ensures the fix can be safely backported to stable versions without requiring a forced XML data update on existing databases. It also keeps this specific security bypass centralized within the mail module's existing architecture.