## [FIX] l10n_fr_reports: fix missing lines in association balance sheet

### Issue:
The Active part of the Balance Sheet for associations shows an incorrect `TOTAL ACTIVE` — some accounts are not propagated to their parent aggregations

### Cause:
`ACTIF_IMMOBILISE` was missing `BIEN_PAR_DONATION` in its formula
`ACTIF_CIRCULANT` was missing both `DISPONIBILITES` and `INSTRU_FINAN` in its formula

### Steps to reproduce:
- Install `l10n_fr_reports` and `accountant`
- Create a new FR asso company and switch to it
- In Accounting Settings, select:
  France - Associations accounting plan
- Create a Journal Entry:
  Account: 240000, Debit: 100 (BIEN_PAR_DONATION)
  Account: 512001, Debit: 100 (DISPONIBILITES)
  Account: 520000, Debit: 100 (INSTRU_FINAN)
  Account: 509000, Credit: 300
- Open the Balance Sheet and select Balance Sheet for associations

Before the fix, `TOTAL ACTIVE` is 0 instead of 300

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

## [FIX] l10n_fr_reports: add force_date_scope to asso cross_report

### Issue:
The Passive part of the Balance Sheet for associations shows an incorrect `TOTAL PASSIVE` — the same move line is counted twice, once in `Retained earnings` and once in `Profit or loss for the year`

### Cause:
In 19.1, `cross_report` aggregations were refactored: https://github.com/odoo/enterprise/commit/e699a14a1922d6b8a5bc6b88ad9c02a411e4b073
By default, a `cross_report` no longer forces its `date_scope` to the terms it calls — `force_date_scope` must now be explicitly passed in the subformula
The association balance sheet was added in 19.1 without this parameter, so `RESULT_LEXERCICE` (`from_fiscalyear`) and `REPORT_NOUVEAU` (`to_beginning_of_fiscalyear`) both used the current report's `date_scope` instead of their own
This caused both expressions to match the same entries and double the `TOTAL PASSIVE`

### Steps to reproduce:
- Install `l10n_fr_reports` and `accountant`
- Create a new FR asso company and switch to it
- In Accounting Settings, select:
  France - Associations accounting plan
- Create a Journal Entry:
  Account: 512001, Debit: 100
  Account: 701100, Credit: 100
- Open the Balance Sheet and select Balance Sheet for associations

Before the fix, `TOTAL PASSIVE` is 200 instead of 100

opw-6520639

Two module manifests hold a `description` whose reStructuredText does not parse. Both are rendered by `ir.module.module._get_desc` (these modules have no `static/description/index.html`, so the RST path is the one used on the Apps page).

### `mail`

The line introducing the list of email-enabled documents is followed by a row of dashes. In reStructuredText an underline directly below a line of text makes it a section title, so docutils treats a 102-character sentence as a heading, then fails on the indented list that follows without a blank line:

```
<string>:38: (ERROR/3) Unexpected indentation.
<string>:43: (WARNING/2) Block quote ends without a blank line; unexpected unindent.
```

These are logged every time the description is rendered, and the bullet list ends up rendered as a block quote instead of a list. The dashes are dropped, since the line is a regular sentence and not a section title, and the list is surrounded by blank lines.

### `l10n_tw_edi_ecpay`

The whole description is indented, which makes reStructuredText read it as a block quote. A section title is not allowed inside a block quote:

```
<string>:3: (SEVERE/4) Unexpected section title.
```

At SEVERE level this reaches the default `halt_level`, so rendering raises instead of returning a document and `_get_desc` falls back to showing the raw description in a `<pre>` block. The indentation is removed.

---

Checked by rendering the `description` of every manifest under `addons/` and `odoo/addons/` with the same docutils settings `_get_desc` uses: these were the only two that reported anything, and both are clean after the change.

Forward-Port-Of: odoo/odoo#284360

Issue:
- The Knowledge and Documents cards are visible even when the portal user has no shared content.
<img width="1344" height="525" alt="image" src="https://github.com/user-attachments/assets/b3409ba1-ff1c-4967-8acb-01baa5243f69" />

- No option to hide them with editor
<table style="width: 100%;">
    <tr>
        <th>Before</th>
        <th>After</th>
    </tr>
    <tr>
        <td>
            <img src="https://github.com/user-attachments/assets/dfdd3d2e-a91b-4b9c-ab64-fdc6535d0fd1" alt="Before" width="280"/>
        </td>
        <td>
            <img src="https://github.com/user-attachments/assets/001f3f57-c926-4469-9ac2-767586c3ac2c" alt="After" width="280"/>
        </td>
    </tr>
</table>



Steps to reproduce:
1. Install website, documents, and knowledge
2. Create a portal user and make sure no documents and knowledge article are shared with him.
3. Log in as a portal user
4. The Knowledge and Documents cards are visible (Issue 1)
5. Again login as admin and go to `/my endpoint ex: http://localhost:3000/my`
6. Click on editor and then click documents card
7. documents card and knowledge are not avaialbe for visibility change  (Issue 2)

Cause:
- Commit https://github.com/odoo/odoo/commit/513931a5e540f22f37e317f80fd131701cbbc8f0 introduced portal.entry records to back portal
  cards. and Commit https://github.com/odoo/enterprise/commit/512c9e49d168a205b8fe2a5ff5384c6a178762e7 defined the Documents and Knowledge
  entries with `is_config_card=True` inside `<odoo noupdate="1">` records.
  Because these records are loaded with noupdate="1", updating the XML data in
  enterprise would not update existing databases.
  Now entries are marked as config cards, and config cards are always shown
  by should_show_portal_card().
https://github.com/odoo/odoo/blob/181f9aa238ae99e92ada4bc4e7064ea95d2f5b84/addons/portal/views/portal_templates.xml#L261-L264

- This is correct for real configuration cards such as Addresses or Connection & Security, but not for counter cards. A card with a `placeholder_count` represents content and should only be displayed when its counter is positive.

Solution:
- Do not force-display config cards that have a `placeholder_count`.

- Also include counter cards in the portal card visibility editor, even if they are marked as config cards in existing databases.

behavior change:

- Before: any portal.entry with `is_config_card=True` was always visible.
- After: it is always visible only if it has no `placeholder_count` and `is_config_card=True` or any records in them
- Cards with `placeholder_count`, like Documents and Knowledge, are hidden until their counter is positive.

- Before: cards with `is_config_card=True` were excluded from the portal visibility options in Edit.
- After: counter cards are included in the editor visibility options even if `is_config_card=True`

opw-6223044

According to LSS Art. 36, minimum wage workers are exempt from IMSS deductions. Previously, the system evaluated the period's total gross wage instead of the daily wage, which caused incorrect withholdings when a minimum wage employee received extra pay (like commissions). We now evaluate the `l10n_mx_daily_salary` directly to protect minimum wage workers while ensuring correct deductions for higher earners with unpaid leaves.

Since calculations rely on `schedule_days` retrieved from the schedule table, users commonly adjust these values (e.g., from 15 to 15.2, or 30 to 30.4). To prevent discrepancies caused by this practice, we now round the `schedule_days`.

Finally, this commit fixes the employment subsidy eligibility threshold. Previously, the limit was incorrectly reduced by unpaid absences. This caused a double-counting effect (since absences already lower the actual gross wage) and wrongly disqualified employees. The subsidy limit is now based strictly on the full payroll schedule length, while the ISR minimum wage exemption correctly continues to consider actual worked days.

target: 19.0
task-6370959

Forward-Port-Of: odoo/enterprise#125061

Steps to reproduce:
- open Discuss, open any chat, open the emoji picker (no 'Frequently used'
  emojis)
- search a term and select emojis without closing the picker (shift+click on
  desktop, plain click on mobile)
- clear the search with backspace

=> traceback: 'Cannot read properties of null (reading
`getBoundingClientRect`)' in adaptNavbar().

This happens because when we clear the search input it calls
`highlightActiveCategory()`, which sets `categoryId` to the topmost category of
the grid, which is now the 'Frequently used' category (sortId 0), added to the
picker since the emojis we just picked updated the recent state. To update the
navbar, `currentNavbarPanel` then looks for the panel holding it in
`emojiNavbarRepr`, but that representation is only built in `adaptNavbar()`,
which runs on mount and from the `ResizeObserver` only, so it was built without
the 'Frequently used' category and no panel contains it. It returns undefined,
the navbar renders empty, its size change wakes the `ResizeObserver`, and
`adaptNavbar()` crashes on querySelector('.o-Emoji').getBoundingClientRect()`.

This commit solves the issue by rendering the `recentEmojis` from a snapshot
taken when the picker is opened, so they are not added to the picker while the
while `emojiNavbarRepr` does not contain their category id.

partial backported PR: https://github.com/odoo/odoo/pull/281104

Task-[6204249](https://www.odoo.com/odoo/project/1519/tasks/6204249)



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

Forward-Port-Of: odoo/odoo#286551
Forward-Port-Of: odoo/odoo#284372

### Issue before this commit:
When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Currencies and activate another currency like EUR
3. Go to Journals and create a new one with bank type and curency EUR
4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal
5. Go to test bank journal and create a new bank matching
6. After the line is created click the 3 dots and go to Manage Models
7. See that the new model Tester created does not appear

### Cause of the issue:
Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. 
https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100

### Reason to introduce the fix:
The filter is not working correctly. In this case it's better to change 
it to a domain instead of a default filter.

opw-6481970

Forward-Port-Of: odoo/enterprise#129992

## Steps to reproduce:

- Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company
- Go to the PoS, select that partner
- Make a sale and ask for an invoice
- The downloaded invoice will be a pro-forma invoice

## Why the fix:

The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice.
https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204

As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do.

This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback.

We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow.

With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities.

opw-6428369

Forward-Port-Of: odoo/odoo#281420

Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types.

This results in invoice reports showing the identification number next to an incorrect label.

This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in
their respective invoice template to match the selected identification type.

Steps to reproduce:
- Install a latam localisation (Uruguay or Guatemala)
- Change company to that country's Company
- Create a partner located in said country, ensure the identification number is set to something else than the default one
- Create an invoice for the partner, confirm it, and then Send it
- In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label

opw-6087359

related to: https://github.com/odoo/odoo/pull/260159

Forward-Port-Of: odoo/enterprise#122512

Currently on creating  new helpdesk team everytime a new website menu is created.

### **Steps to Reproduce:**
1) Install website_helpdesk
2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 
3) Create 2 helpdesk team with `Website Form` option enable. 
4) Navigate to Website.

### **Observed Behavior:**
Two Help menus are created.

### **Expected Behavior:**
Multiple menus should not be created.

### **Root Cause:**
The menu creation logic relies on the following [condition](https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/website_helpdesk/models/helpdesk.py#L111-L112)
`team_count_by_website` is built from `_read_group(..., ['website_id'], ...)`,
which keys its result by the `website_id` *recordset*, not its id. Looking it
up with `team_count_by_website.get(website.id, 0)` therefore always misses and
falls back to `0`, so `team_count <= 1` is always `True` regardless of how
many teams already exist for that website. The only thing left guarding menu
creation is `any(team.website_menu_id for team in teams)`, which only looks at
the teams in the current create/write call, not every team on that website.
So saving a second team in a separate call always creates another menu.

### Fix:
Make the website menu a resource shared by every team with the website form
enabled on a given website, instead of "owned" by whichever team created it:
- Before creating a new menu, look up other teams (active or archived) that
  already point to a menu, matched through the `website_menu_id` relation
  between teams rather than a hardcoded `/helpdesk` URL, so a customized menu
  URL doesn't cause a duplicate to be created. Reuse that menu when found.
- Only delete a menu once no team (active or archived) still references it,
  checked before removing a team's own reference.

**opw-6303846**

Forward-Port-Of: odoo/enterprise#130207
Forward-Port-Of: odoo/enterprise#121120