Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation.

This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance.

This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase.

A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here.

#### speedup

In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s

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

****Behavior:****

**Current:**
When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view.
- If the selected timesheets come from only a single private project : an Access Error is raised
- If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised

The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error.

**Expected:**
Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell.

So now when printing or exporting a timesheet from a single private project, no Access Error is raised.

**Steps to reproduce:**
- Create 2 different projects
- Create a task in each
- Assign it to another user (Make sure the other user only has user access to timesheets and projects)
- Set each project's visibility setting to private
- Log in with the other user
- Go to Timesheets --> List View

Single projects:
- Select one or multiple timesheet entries from one of the private projects
- Select Print -> Timesheets
- You should see an Access Error 

Multiple projects:
- Select one or multiple timesheet entries from a combination of both private projects
- Select Print -> Timesheets
- You should not have any Errors

opw-5127526

Forward-Port-Of: odoo/odoo#231188

## Description of the issue/feature this PR addresses:

When obtaining the previous order for pos.order records, all orders with l10n_fr_secure_sequence_number == NULL will be recognised as the previous order for those where l10n_fr_secure_sequence_number == 1, as if their sequence value was zero.

## Current behavior before PR:

Since there can be more than one orders without sequence number, this behaviour will trigger an UserError exception, as the ORM will mistakenly deduce that there are multiple previous orders for a single one, which is not necessarily correct.

### Examples:

upg-3170341

```sql
lare_3170341=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
 count
-------
 67281
(1 row)
```

```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, [])    # len(match) == 67281
if len(match) > 1:
    raise UserError(_('An error occurred when computing the inalterability...'))
...
```

upg-3170341

```sql
lare_3167621=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
 count
-------
   294
(1 row)
```

```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, [])    # len(match) == 294
if len(match) > 1:
    raise UserError(_('An error occurred when computing the inalterability...'))
...
```

---

Traceback group: https://upgrade.odoo.com/odoo/tbg/1869

```
2025-09-30 07:48:30,945 329 INFO db_3167621 odoo.modules.loading: Loading module l10n_fr_pos_cert (110/131) 
2025-09-30 07:48:31,375 329 INFO db_3167621 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 
2025-09-30 07:48:31,432 329 INFO db_3167621 odoo.models: Prepare computation of pos.order.previous_order_id 
2025-09-30 07:48:31,597 329 WARNING db_3167621 odoo.modules.loading: Transient module states were reset 
2025-09-30 07:48:31,597 329 ERROR db_3167621 odoo.modules.registry: Failed to load registry 
2025-09-30 07:48:31,597 329 CRITICAL db_3167621 odoo.service.server: Failed to initialize database `db_3167621`. 
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
    registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 618, in init_models
    func()
  File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_model.py", line 2007, in _reflect_relation
    self.env.invalidate_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 839, in invalidate_all
    self.flush_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 857, in flush_all
    self._recompute_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 850, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7359, in _recompute_field
    field.recompute(records)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1463, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1436, in apply_except_missing
    func(records)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 427, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5296, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/18.0/addons/l10n_fr_pos_cert/models/pos.py", line 79, in _compute_previous_order
    raise UserError(_('An error occurred when computing the inalterability. Impossible to get the unique previous posted point of sale order.'))
odoo.exceptions.UserError: Une erreur s'est produite lors de la vérification de l'inaltérabilité. Impossible de récupérer la dernière commande de caisse unique et comptabilisée.
```

## Desired behavior after PR is merged:

The method `pos.order._compute_previous_order` already only checks orders with a sequence number != NULL, so to address this issue, we will use the same condition to retrieve only orders with a valid sequence. This will result in no more exceptions created by incorrect data.

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/0216b0643 [REL] 18.0.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/41a767864 [FIX] clipboard: paste as value with empty format string [Task: 5156459](https://www.odoo.com/odoo/2328/tasks/5156459)
https://github.com/odoo/o-spreadsheet/commit/4bf3363b5 [FIX] data_validation: selecting range from another sheet [Task: 4948201](https://www.odoo.com/odoo/2328/tasks/4948201)
https://github.com/odoo/o-spreadsheet/commit/af36b2666 [PERF] evaluation: stop the dependencies search early [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710)
https://github.com/odoo/o-spreadsheet/commit/b796c32c0 [FIX] functions: fix LINEST error massage [Task: 5059375](https://www.odoo.com/odoo/2328/tasks/5059375)
https://github.com/odoo/o-spreadsheet/commit/ff8bba956 [FIX] chart: clip show value text to chart area [Task: 5125970](https://www.odoo.com/odoo/2328/tasks/5125970)
https://github.com/odoo/o-spreadsheet/commit/a828d6c76 [FIX] chart: tooltip has wrong format for date chart [Task: 5126261](https://www.odoo.com/odoo/2328/tasks/5126261)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.

When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.

This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```

From the above error, it's clear that Twitter only accepts specific MIME types.

This fix ensures the image has the correct MIME type so it can be uploaded without issues.

-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======

Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.

Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.

After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.

[1]  https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852


Task-4845385

Forward-Port-Of: odoo/enterprise#91995

To reproduce:
=============
- create accrual plan to get 1 day of WFH every week on monday, no carry over
- create allocation with this plan for an employee
- in the actual week you can see on dashboard that you have 1 day of WFH
- let's say we are a Monday, take 1 day of WFH on Wednesday (don't approve it)
- before Wednesday dashboard shows 1 day of WFH
- after Wednesday in same week dashboard shows 0 day of WFH
- in next week dashboard shows 0 day of WFH which is wrong

Problem:
========
The computation of virtual accrual leaves was wrong because it took into account the leaves already taken in the current week, while they should be ignored.

Solution:
=========
as we already check if the allocation we are computing virtual accrual for is in same time range as the current one here : https://github.com/odoo/odoo/blob/4c9eadc3c1b2d5ef6a495b89ab33481d5d545ec4/addons/hr_holidays/models/hr_leave_allocation.py#L625 we don't need to subtract the number of days/hours of the current allocation

opw-4712586

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

**Steps to reproduce:**
1. Install the *Fleet* and `accounting` modules.
2. Create a new purchase tax.
3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund.
4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines.
5. Check the *Tax Report*(account>tax), including the date of this vendor bill.

**Observed behavior:**
* Tax lines linked to the current asset account are merged.
* Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`).
* This mismatch triggers an error in the tax report.

**Root cause:**
The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles.

**Solution:**
Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error.

opw-5013757

To reproduce:
1. Ensure Analytic Accounting is activated in the accounting settings
2. Uncheck the option Auto-Check on Post in the Vendor Bills journal
3. Create a vendor bill and set analytic accounts in at least one line
4. Post the vendor bill
5. Go to Accounting > Analytic Items
6. No analytic item was created for the vendor bill

In some cases, such as when the vendor bill journal has `Auto-check on Post` disabled or a there is a lock date set, the analytic items are not created when posting the move, even if analytic accounts were set on the move lines.

Cause:
In #222196, a check is performed when writing an account.move.line, which unlinks analytic lines created for draft moves. However, this condition is too general, and if additional writes happen in between the analytic line creation and changing the move state to `posted`, the analytic lines are deleted.

Solution:
The unlinking on analytic lines should only be performed if `analytic_line_ids` are in vals.

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

**Problem:**
When confirming the invoice of an order delivered via dropship for some kit bom 
product with fifo/avco comp, if the price was manually set on the purchase order, 
the invoice lines generated for the cogs are inaccurate

**Steps to reproduce:**
- In settings enable dropshipping, automatic account and anglosaxon accounting
- Create a kit product with one component.
- Set the route as Dropship for the component.
- add a vendor in the purchase tab of the component.
- set the cost of the component at 2
- Set the product category to AVCO (Automated) for the component and the product.
- Create and confirm a sales order with a quantity of 2 for the product.
- On the purchase order set the unit price at 20 for the component.
- Confirm the purchase order, then validate the delivery and create the customer invoice.
- Confirm the invoice

**Current behavior:**
In the journal items tab of the invoice the lines for the cogs (expenses and stock interim) have a value of 22

**Expected behavior:**
The value should be 40, in accordance with the purchase order

**Cause of the issue:**
In the mrp_account override of _compute_average_price,
the stock move has no bom because it was generated from the purchase order, 
so this condition will be true
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L67
This is not a problem, however the problem comes from the fact that
move.product_id is already equal to qty_to_invoice \*component_quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L73
Multiplying it a second time by qty_to_invoice is an error.
For instance in our steps, qty_to_invoice is 2, compenent_quantity is 1 
and move.product_qty is 2.
So when calling _compute_average_price for the comp, we call it with a 
qty_to_invoice parameter of 4 instead of 2.
As a result, because the candidates svls only have a quantity of 2, there will 
be we a missing quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/stock_account/models/product.py#L927-L934
So the result will be the average between the quantity on the purchase order (20)
and the standard price (2).
Which is why the account line has a value of 22 (2*11)

opw-4985440