### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#102495
Forward-Port-Of: odoo/enterprise#96007

Following https://github.com/odoo/enterprise/pull/96974, we are doing the filtering of rows much later which shows a lot more areas to improve.

First 2 optimizations can be done for *every* report:
<img width="1920" height="296" alt="image" src="https://github.com/user-attachments/assets/6d7e57ce-8b57-4f1c-9ab7-6212495993d3" />
The (1) optimization is to remove the second safe_eval I forgot to remove before :sweat: 
The (2) optimization consist to hash less keys as well as to not iterate over all the lines in _build_lines_columns

Another 2 smaller optimizations are possible on the general ledger:
<img width="1919" height="362" alt="image" src="https://github.com/user-attachments/assets/61d012ee-1014-4d95-82f7-22b0d9c06500" />
<img width="1919" height="426" alt="image" src="https://github.com/user-attachments/assets/eb7e756c-6d3e-4d6b-a445-e0a28aca553c" />
The (3) is outdated
The (4) is `self.env.company.currency_id.id` being accessed

<img width="1919" height="384" alt="image" src="https://github.com/user-attachments/assets/7b945f64-88ac-4ca5-8552-50bdfe17e849" />
(1) is down from 55.42s to 489ms  

(2) is down from ~26s to ~0.55s    
(4) is down from ~4.14s to ~1.9s

*Tests were done on a demo db populated on models res.partner,account.move with a factor of 20000 and opening the Tax Received line of the general ledger which contained about 150,000 lines and a limit_to_load at the default 80*

**Current behavior before PR:**
When a user has previously denied camera or microphone access, the system only shows a warning notification. This makes it unclear for the user how to resolve the issue or where to enable permissions again.

**Desired behavior after PR is merged:**
If the user has already denied access and attempts to use camera or microphone features again, the system now displays a dedicated dialog with an illustration and clear, step-by-step instructions explaining how to re-enable the required permissions from the browser address bar.

Before
<img width="486" height="132" alt="image" src="https://github.com/user-attachments/assets/10a0f7ee-fc50-4e36-bbcc-a6a880d33ca3" />

After
<img width="938" height="488" alt="image" src="https://github.com/user-attachments/assets/da4e361b-7f09-4b06-bb5d-1170c682b4d7" />


task-[5379164](https://www.odoo.com/odoo/project/1519/tasks/5379164)

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

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


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

Forward-Port-Of: odoo/odoo#237599

revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like

even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL:  Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```

due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files

so we need to avoid to fetch archived warehouse's picking type.

ref:
odoo/upgrade#6631

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#191652
Forward-Port-Of: odoo/odoo#185244

Follow-up of https://github.com/odoo/odoo/issues/239537

PR Above improve style of category title. One of the change is reduce opacity of title when not hovered.

The chevron icon was not taken into account, which makes the category title line more visible than intended.

This commit put same condition to reduce opacity of category title when not mouse-hovering on the chevron icon.

Before / After
<img width="297" height="854" alt="Screenshot 2025-12-18 at 15 59 43" src="https://github.com/user-attachments/assets/90e9c49f-7105-4f35-965c-0be5c5822a39" /> <img width="297" height="853" alt="Screenshot 2025-12-18 at 15 58 59" src="https://github.com/user-attachments/assets/65246008-b5b8-4d94-b095-544c99e1e3aa" />


<img width="304" height="858" alt="Screenshot 2025-12-18 at 16 00 30" src="https://github.com/user-attachments/assets/9c5bdaac-b113-45f3-9bd6-fb9171eaa260" /> <img width="300" height="858" alt="Screenshot 2025-12-18 at 16 00 51" src="https://github.com/user-attachments/assets/47f26fe0-bdb4-45f8-af2d-125dfe72f59a" />

Commit 8f3e242e197b2f26982749 added an Etag to reduce the load on the network when loading a spreadsheet.

Now, this commit ensures the Etag is computed as fast as possible to also reduce the load on the server.

The Etag is based on the latest revision (field `current_revision_uuid`). When computing `current_revision_uuid`, we look at the lastest revisions. However, the current code only look at *active* revisions, and fallback on the snapshot.
The snapshot is a json file (potentially large) that needs be parsed. This is not fast.

To make it worse: spreadsheets are snapshotted as often as it can be, which means we almost always fall in the slow path when computing the Etag.

With this commit, we consider all revisions (active or not). We also load in memory only the latest instead of fetching multiple revisions for each spreadsheet (the work is done by postgres through `_read_group`)

On a spreadsheet with a snapshot of 9.8MB, server time
`"GET /spreadsheet/data/documents.document/17 HTTP/1.1" 304`

before: ~310ms
after:    ~5ms


Task-5431940

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#101919
Forward-Port-Of: odoo/enterprise#95111

When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions.

### Steps
1. Create a new Company with country Uruguay
2. Change current logged company to new Company
3. Change the currency to USD
4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank
5. Click manual synchronization
6. Check rates  

### Current behavior before PR

All currencies except UYU currency has created taxes with date today.
Only one error in UYU currency that is created with yesterday rate
![image](https://github.com/user-attachments/assets/adfdf9a1-f0cf-4825-bfe4-47ff5c8da2c4)

### Desired behavior after PR is merged:

All the currencies are created with the same date, the correct day that is today rate.

References: LATAM 1341 / ADHOC Task 51716

Forward-Port-Of: odoo/enterprise#85065

*: calendar, html_editor

Fixes an issue where the calendar event popover was positioned incorrectly for long events displayed in the day scale.

The fix updates the general positioning logic to test a wider range of placement possibilities, including center positioning. This applies to any positioned element that can be flipped but is not shrinkable.
Consequently, the `shrink` behavior is moved from the popover default to an optional parameter (currently enabled only for dropdowns), ensuring that calendar popovers maintain their size while finding a valid position.

Additionally, this commit:

- Restores the default calendar popover position back to 'right', as the previous change (https://github.com/odoo/odoo/pull/236503) did not properly address the root issue.
- Removes an unnecessary useEffect hook from the Many2ManyAttendeeExpandable component.
- Removes the concept of variant flipping because variant shifting was making it pointless.
- Adjusts rules that hide html_editor overlays when they overflow: this should now only apply to non flippable overlays and when the selection is out of the view port.

task-5401647

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Forward-Port-Of: odoo/enterprise#102130

Dropping a custom "Form" snippet onto the checkout page would prevent the user from completing their order.

Steps to reproduce:
===================
1. On a website with eCommerce, add a product to the cart.
2. Proceed to the checkout page.
3. Enter Edit mode and drag a "Form" snippet onto the page.
4. Save and exit Edit mode.
5. Click the main "Process Checkout" button. -> The checkout process is blocked, and the custom form  show validation errors.

Cause:
======
A Extra info patch is intended for the "Extra Info" checkout form only, but It was applied to all `s_website_form` instances on the checkout page.

This caused any dropped form snippet to listen for a click on the main checkout button. When a user tried to proceed, the custom form would incorrectly intercept the event and trigger its own validation. If the form had required fields, this validation would fail and block the entire checkout process.

Solution:
=========
The patch has been refined to be more specific. It now only targets forms that have the `data-force_action="shop.sale.order"` attribute.

note: issue introduced in this commit: [1]

[1]:https://github.com/odoo/odoo/commit/a6489b9a2f84efa270b3b1951b8c542355de291b

opw-5391286

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

Forward-Port-Of: odoo/odoo#240244