### Purpose:
   The main objective of this task is to allow stakeholders to efficiently manage shared projects assigned by the project manager.

### Changes Implemented:
- Added Gantt view in project sharing.
- Stakeholders can schedule multiple tasks.
- Drag-and-drop is enabled when grouped by stage or tag.
- Dependency lines are visible only in read-only mode.
- Editing a task opens the project sharing form view.

###  Technical Details:
- Mail-related dependencies are not loaded in project sharing and require a common renderer.

     Updated Renderer Structure:

				GanttRenderer
				     |
			   TaskGanttRendererCommon
			             |
	      -------------------------------------------
	      |                                          |
	TaskGanttRenderer             TaskSharingGanttRenderer

-----------------------------------------------------------------------------

    Updated Model Structure:

				        GanttModel
                                         |
                               TaskGanttModelCommon
                                         |
                  -----------------------------------
                  |                                 |
            TaskGanttModel             TaskSharingGanttModel

------------------------------------------------------------------
   
 Updated GanttArchParser Structure:

			   GanttArchParser
			           |
		       TaskGanttArchParserCommon
		                  |
             ---------------------------------------------------
                 |                                            |
    TaskGanttArchParser                 TaskSharingGanttArchParser

task-4489162

With the French fiscal localization:
When an employee has a different working schedule than the company’s default one. If the employee’s daily working hours are greater than the company’s default hours. The timesheet for paid time off only displays the company’s default hours instead of the employee’s actual hours.

Steps to reproduce:
-------------------
* Install l10n_fr_hr_holidays
* Set the French fiscal localization
* Working schedule of the company -> 7:30 per day
* Working schedule of the employee -> 8 per day
* Create a paid time-off with this employee
* Check the Timesheet of this employee

> Observation:
Timesheet shows 7:30 instead of 8

Why the fix:
------------
We needed to ensure the hours are always calculated correctly (using the employee’s or company’s calendar when appropriate) while still forcing the correct day count (1 or 0.5) and extending it according to French law.

✅ Day count is forced (0.5 or 1) depending on the leave type.
✅ Hours are fetched from  `super()._get_durations()` so the timesheet keeps accurate hours.

This prevents timesheets from showing incorrect hours when the employee's work schedule differs from the company's work schedule.

opw-4744516

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

Issue: Inconsistent mimetype vs filename for documents shared by portal users.

1. Share a ms office document logged in as a portal user.
2. filename is correct, but mimetype is `application/zip`.
3. User can't interact with the file to open the file in the Odoo spreadsheet because the mimetype is zip.

<img width="387" height="192" alt="image" src="https://github.com/user-attachments/assets/be31f05f-e4e3-44d9-b12a-66f96feba950" />

<img width="274" height="67" alt="image" src="https://github.com/user-attachments/assets/93064e5c-c028-41ce-8e79-1b9c9447c018" />


With `fix_filename_extension()`, the following two commits fixed the issue of Odoo's `guess_mimetype` function incorrectly guessing extensions such as `.xlsx` as `.zip` extension.
https://github.com/odoo/odoo/commit/8842b6b43e7c3d1cc67d7d399bb210e4009e23b2 https://github.com/odoo/odoo/commit/34d9375e2efb604f8e7036cb710f44b01f9ccaee

However, the `_from_request_file()` still uses the incorrectly guessed mimetype to create an attachment, leading to inconsistent extension from the filename (.xlsx) vs attachment record's mimetype (.zip).

This commit fixes the issue by using the mimetype from the filename's extension.

This is safe if the following assumption is correct:

At the point where the `from_request_file()` attempts to create the attachment record, the `filename` contains correct extension name, presumably fixed by the `fix_filename_extension()`.

Commit message to be changed after with Julien's confirmation;

opw-4753670


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

Steps to reproduce the bug:
- Create a storable product “P1”
    - Under the Purchase tab:
        - add two vendor pricelist entries:
        1:/
        - Vendor: Azure Interior
        - min_qty: 1
        - Price: $5 
         2:/
          - Vendor: Azure Interior
          - min_qty: 100
          - Price: $2

- Create a purchase order:
    - vendor: Azure Interior
    - Try to add the product P1

**Problem:**
When adding a product to a purchase order, if multiple supplier info
lines exist for the same vendor,  the one with the lowest price will be
selected, instead of the one matching the smallest applicable quantity
(min_qty).

This regression was introduced by the following commit, which
tried to fix an unrelated bug with supplier info date matching:
https://github.com/odoo/odoo/commit/7eabfcff402993f32f5c835e18e07c91782a7b33#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224L470

As part of that fix, the logic was changed to use the _select_seller
method, which by default sorts supplier info lines by price_discounted
and returns the first one — regardless of whether the min_qty is met.

Previously, the logic correctly selected the supplier line based
on min_qty when multiple lines existed for the same vendor.

**_Note:_** This bug is no longer present as of version 18.1, because
the date-related issue was fixed differently in the following commit:
https://github.com/odoo/odoo/commit/19c65c4884a3746b44b6272694662eb32a6bf32f

That later fix preserved the original behavior of respecting min_qty.

**Solution:**
Explicitly pass ordered_by='min_qty' when calling _select_seller.
This ensures that supplier info lines are prioritized based on the
lowest applicable min_qty, not the lowest price, when the vendor is the
same.

opw-4942819

Forward-Port-Of: odoo/odoo#221764

**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
   - Pricelist A with two fixed-price rules: 
     - `0.75` for quantity ≥ 0
     - `0.50` for quantity ≥ 1000
   - Pricelist B with a `-10%` discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.

**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.

**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since PR [#21392](https://github.com/odoo/odoo/pull/213912), `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.

**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.

opw-4944644

**Steps to reproduce:**

1) Create a flexible working schedule.
2) Assign this schedule to an employee.
3) Create a public holiday.
4) Create a leave request for the flexible employee on the public holiday. 
5) Notice that the duration of the leave is 1 instead of 0.

**Issue:**
Due to recent changes in the [commit](https://github.com/odoo/odoo/commit/a826f65c2d95b796f919023d560ec9f0801090d8#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R427-R433) ,

When a single-day flexible leave is taken, the duration is always set to the real duration. 
However, we do not check if the leave falls on a public holiday, 
which results in the leave being set to 1 day, even on holidays.
https://github.com/odoo/odoo/blob/8f24da78f60529ea0b1840e48de30e15d17ddb77/addons/hr_holidays/models/hr_leave.py#L427-L433
**For example:**

If Christmas is marked as a public holiday and an employee with a flexible schedule 
requests a one-day leave on Christmas, the leave is recorded with a duration of 1 day.

**Fix:**
Check for a public holiday on leave date; if yes, set leave duration to 0.

opw-4963122

Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate records , resulting in an “Access Error” popup. This changes Wrap the certificate lookup in company.sudo().

It's handled the same in
https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L140 https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L770

install l10n_es_edi_facturae
Go to Contacts and create an new contact with Spain as country in the same page (creating contact page) click on Accounting scroll down and set eInvoice format as facturaE
Go to Accountant and create an invoice with that client pay the invoice
log out and log in with a user with no administration (e.g. Marc demo) try to send the create invoice

OPW:4989007



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

**Issue**
When using the Portuguese localization (`l10n_pt`), manually changing and resetting a tax amount on a vendor bill can incorrectly alter the base (untaxed) amount.

**Steps to Reproduce**
1. Install Accounting and Portuguese localization (`l10n_pt`)
2. Create a vendor bill with a line: price = 123, tax = 23%
3. Manually change the computed tax amount from 28.29 to 28.30
4. Change it back to 28.29
5. Save the invoice
6. Observe that the untaxed amount becomes 122.99 instead of 123.00

**Root Cause**
In the Portuguese localization, the tax delta logic compares `raw_total_amount` instead of `raw_base_amount` to detect rounding differences. However, the `raw_total_amount` field is not recomputed when the tax amount is manually edited. As a result, the system detects a false positive delta (0.01) and incorrectly subtracts it from the base amount to force reconciliation of totals.

**Fix**
Extend the delta correction loop to also update `raw_total_amount` and `raw_total_amount_currency`, not just `tax_amount` and `tax_amount_currency`. This ensures all totals are correctly adjusted after a manual tax change, and prevents the base amount from being unintentionally altered.

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

**Description**
When syncing a calendar event to Google, the system impersonates the event organizer in a multi-company context, this causes an access error
if the current context includes companies the organizer does not have access to.

---

**Steps to Reproduce**
- Create Company B and organizer user (Company A access only)
- Set current user to have access to both companies
- Login as the organizer user
- Go to Calendar app
- Create a new event with Google sync enabled
- Login as multi-company user
- Select both companies in company switcher
- Navigate to the event created by organizer
- Trigger Google Calendar sync (accept/decline event)

---
**Before**
  ` Access to unauthorized or invalid companies`

**Root cause:**
   - The sync switches to the organizer's identity but keeps the original multi-company context
   - This creates a mismatch where the organizer doesn't have access to all companies in the context
   - Results in access violation when trying to sync

**After:**
   - Properly scope the company context to match the organizer's company when switching user identity
   - This ensures the sync operation runs within the correct company boundaries

opw-4911040

Forward-Port-Of: odoo/odoo#221193

Issue description:
The profitability items for projects were not matching the numbers from analytic accounting reports due to discrepancies in currency rate calculations. This issue was traced to two main causes:

1. Profitability items were using the currency rate of today, even for old move lines.
```rates = self.env['res.currency'].browse(list(currency_ids))._get_rates(self.company_id, date.today())```
 While this was deemed acceptable for performance reasons in #113146,
 it caused mismatches with analytic accounting reports.

2. Some move lines use a changed currency rate that differs from
the rate stored in the currency table for the same date
(due to manual change in the currency rate), leading to further mismatches.

To resolve this:
- The `balance` is now used instead of `price_subtotal` for calculations.
This ensures accurate amounts without relying on conversion rates
when the project currency matches the company currency.

Steps to Reproduce:
1. Create a project with an associated analytic account.
2. Enable any foreign currency and add different rates for it for today and yesterday.
3. Create a new vendor bill with:
   - Date = yesterday
   - Currency = the new foreign currency
   - Analytic distribution set to the created project's analytic account.
4. Check the project dashboard profitability. You will see the numbers
are incorrect because it uses the currency rate of today.

opw - 4881380

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

Forward-Port-Of: odoo/odoo#221168
Forward-Port-Of: odoo/odoo#217337

Issue
-----
Incoming return slips have a "Demo Address and Name" text instead of the correct destination address.
<img width="928" height="658" alt="image" src="https://github.com/user-attachments/assets/6ff0a5e7-f1ee-4faa-a22b-76ec8f2f7a28" />

Steps to reproduce
-----
- Create a receipt for a product
- Print its return slip

Cause
-----
By default, the address is taken from the pickings location_id -> warehouse_id -> partner_id. For incoming pickings, the warehouse is the vendor one, with no associated partner. In such cases, the partner can be found directly on the picking itself with the partner_id field.

Note
-----
To render t-fields, qweb first applies a `rsplit` before evaluating the expression, see
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/odoo/addons/base/models/ir_qweb.py#L2015-L2016

With this in mind, using parentheses and moving `.partner_id` outside of them seems like the most readable way to go about it.

-----
Ticket:
opw-4660716

Forward-Port-Of: odoo/odoo#219011

Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE

When using the Odoo VAT book (location Spain) and we have an invoice with the taxes
0.26% SE (0,26% Recargo Equivalencia Compras)
1% SE (1% Recargo Equivalencia Compras).
a KeyError error occurs 

<img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" />


Steps to Reproduce this error:
1. Create a new database using Odoo version 18.
2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es).
3. Create a new company and set Spain as the country.
4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge".
5. Create a new quotation and select the company created in step 3.
6. Add a product with the following taxes: 0.26% and 2% VAT (G).
7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G).
8. Confirm the invoice generated from the quotation.
9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report".
10. Click the gear icon and select "VAT Record Books (XLSX)".

OPW https://www.odoo.com/es_ES/my/tasks/4981807

@jco-odoo please review. Thank you!

MT-10457 @moduon

Let's say a Document Folder is shared with a portal user with 'edit' access. The portal user shares a .xlsx file to the folder, and an internal user later try to convert the file to odoo spreadsheet. During the conversion, the portal user has 'edit' role on the folder, which is copied to the documents.access records of the converted sheet. Since Odoo prevents Spreadsheets from being shared in edit mode to portal users, _check_spreadsheet() raises a Validation Error.
<img width="702" height="527" alt="image" src="https://github.com/user-attachments/assets/efee9a8b-161f-4def-9597-cf03ac4c54e3" />


To improve the user experience, this commit overrides `copy_data` of `documents.access` model to assign `view` access to portal users for an odoo spreadsheet.

Maybe we can extract the if-conditions, and make it an API to reduce repeated code, as the same logic is being used in `_check_spreadsheet()` on the same file.
However, looping through the copied vals_list only when handler is spreadsheet might have more value in terms of performance.

opw-4753670

Issue
-----
In a SO, changing the quantity for a product with packagings through the catalog correctly updates the SOL's packaging but not the move's. Instead, it creates a new move for the difference in quantity (with the correct new packaging) while
leaving the existing one unchanged. The user ends up with 2 moves with different packagings.

Steps to reproduce
-----
- Install both Sale and Stock
- Enable "Product Packagings" under Settings > Sales
- Create a new product with a custom packaging for 2 units (inventory tab)
- Create a SO
- Add the product to the SO
- Confirm SO
- Open product catalog
- Update the product quantity to 4
- Go back to the SO
- Go to the linked delivery

-> The delivery has 2 lines instead of 1

Cause
-----
The logic flow is different between when in form or catalog view.

When changing the quantity of a sale line through the form, the quantity update is done on a temporary record. This triggers a change of the packaging through

https://github.com/odoo/odoo/blob/0a0dc2f1bd54f44356a5959b8bcd52aaddcf1261/addons/sale/models/sale_order_line.py#L649-L650

When saving the changes, both the quantity and packaging are present in the write `values` as both fields have to be updated on the real record. This allows to enter the following block, which updates the packaging on the existing move.

https://github.com/odoo/odoo/blob/0a0dc2f1bd54f44356a5959b8bcd52aaddcf1261/addons/sale_stock/models/sale_order_line.py#L198-L201

Later on in the write, we trigger a replenishment.

https://github.com/odoo/odoo/blob/0a0dc2f1bd54f44356a5959b8bcd52aaddcf1261/addons/sale_stock/models/sale_order_line.py#L205-L206

This replenishment creates a new move for the rdifference in quantities, using the SOL's new packaging. Since both the new and existing line have the same packaging, they are merged together. Everything works as expected.

When making changes through the catalog, we are directly writing the new quantity on the existing SOL. We directly enter the SOL's `write` method with only the new quantity in `values`.

This means we don't update the packaging on the existing move since `product_packaging_id` is not in `values` so we can't enter the block

https://github.com/odoo/odoo/blob/0a0dc2f1bd54f44356a5959b8bcd52aaddcf1261/addons/sale_stock/models/sale_order_line.py#L198-L201

The write then goes on to trigger a replenishment. When preparing to create the procurement, we access the SOL's `product_packaging_id`

https://github.com/odoo/odoo/blob/0a0dc2f1bd54f44356a5959b8bcd52aaddcf1261/addons/sale_stock/models/sale_order_line.py#L248

Since it's dependency (the quantity) changed, the compute is triggered. The SOL packaging is updated and the newly computed packaging is used to create the procurement (and subsequent move).

We end up with two moves with different packagings,
- the existing move with the old packaging
- the new move with the new (correct) packaging
They can not be merged together because their packagings differ -> bug.

Version constraint
-----
The bug is only present in 17.X versions, as packagings have been deprecated in 18.0.

Making the field computed
-----
We could make the move's packaging a *computed* field. This seems like the most logical and practical solution. However, this approach has some problems:

- the field is used for both sales and purchases so we'd have to adapt the  behaviour there as well.
- we have to consider multi step routes. In such cases, the moves are linked  between themselves but not to the SOL. This means we can't make the dependence be on the SOL packaging, we have to make it on the other move's. So we would have to make the field recursive, so that an update on the first move's packaging can propagate along the chain.
- adding onto the previous point, sale and purchase multi step routes use different rules, so we would depend on the origin's product_packaging_id in one and on the destintation's in the other.

This leads to us propagating changes both ways across move chains, so we don't know whether the origin or the destination has the correct packaging.

Solution
-----
Update the packaging of existing moves through the SOL's write method before it launches the replenishment.

Why this works
-----
We first store the existing packaging (or lack thereof) of the SOL

> old_packaging = {sol: sol.product_packaging_id for sol in self}

We then write the content of `values` on the record.

> res = super(SaleOrderLine, self).write(values)

This only updates the quantity of the SOL.

We then force the recomputation of the SOL's packaging

> if sol.product_packaging_id != old_packaging[sol]:

If the new packaging differs from the previous, we update the existing move(s) so that they use the new packaging of the line

> sol.move_ids.filtered(
> 	lambda m: m.state not in ['cancel', 'done']
> ).product_packaging_id = sol.product_packaging_id

Only then does the write launch the replenishment

> lines._action_launch_stock_rule(previous_product_uom_qty)

Since the existing moves' packaging has been updated, they will correctly be merged with the new ones.

-----
Ticket:
opw-4603600

Forward-Port-Of: odoo/odoo#206973

Modifications are made around read, filtered, list comprehension.

The read function usually does not prefetech fields other than stated. But in this case, since the fields are related fields from another model, The fields of the other model are prefeteched. This includes the body which can be very big in size and cause an out of memory error.

Filtered does not need other fields and keeps them unnecessarily in cache.

List comprehension where it has a reference to specific field inside the model also triggers the prefetecher.

Benchmark:
|        |Number of queries| SQL time| Python time||
|-------|----------------------------|----------------|---------------|-|
|with prefetch| 82| 1.887 | 7.898| Out of memory|
|Without prefetch| 120| 0.385 | 5.973| |

The benchmark with the prefetch was done locally with increasing the memory limit.






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

Forward-Port-Of: odoo/odoo#206125
Forward-Port-Of: odoo/odoo#183893