**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

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

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122030

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d00e4b62c5 [REL] 18.3.54 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/722416eaf1 [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5c888b116c [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Description of the issue/feature this PR addresses:
The rating module does not correctly extend the mail modules onClick for NotificationItem

Current behavior before PR:
* mail NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread, message)`
* rating NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread)`
  * causing the [if in onClickThread](https://github.com/odoo/odoo/blob/18.0/addons/mail/static/src/core/public_web/messaging_menu.js#L39C17-L39C24) to be missed and falling backup to opening the thread
     ```javascript
            if (message?.needaction && message.message_type === "user_notification") {
                this.store.inbox.highlightMessage = message;
                this.openDiscussion(this.store.inbox);
                return;
            }
            this.openDiscussion(thread);
            return;
     ```

Desired behavior after PR is merged:
* rating should not change the fallback behaviour for messages without a rating_id and still allow opening the user_notification in inbox instead of switching to the thread

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

Info @wt-io-it

Forward-Port-Of: odoo/odoo#244521

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Forward-Port-Of: odoo/enterprise#120566

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

**Steps to Reproduce:**
- Install the Accounting and Contacts modules.
- Enable Quick Encoding for Customer Invoices and Vendor Bills in the company 
  settings.
- Create a new customer: Assign a salesperson.
- Ensure:
  - The salesperson is not a login user.
  - The customer language, salesperson's language, and Login user's language 
    are different. Example:
     - Customer language: English
     - Salesperson language: French
     - Login user language: French
- Create a customer invoice using the Upload Document functionality.
- Select the customer created above.
- Use Quick Edit mode and enter an amount and Click Confirm.

**Issue:**
- When the invoice notification is rendered in a language different from the one
  used during the write operation, the notification rendering flow calls 
  _notify_by_email_prepare_rendering_context().
- During rendering, the code executes:
```
self.tax_totals.get('total_amount_currency', 0)
```
- Since tax_totals is protected, the ORM returns False instead of the expected
  dictionary, leading to:
```
AttributeError: 'bool' object has no attribute 'get'
```

**Root Cause:**
- This issue occurs in Quick Edit mode because tax_totals is [not read-only](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/views/account_move_views.xml#L1359) 
  in Quick Edit mode and is included in [the values](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/web/static/src/model/relational_model/record.js#L708) sent by the web client during write().
- During create()/write(), _get_protected_vals() marks tax_totals as protected.
- Since tax_totals is a [@api.depends_context('lang')](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L975) computed field, it 
  maintains a separate cache per language. [During write()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3955), the [field becomes 
  protected](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3863) by [env.protecting()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/odoo/orm/fields.py#L1738). While the protection is still active, the mail 
  notification flow renders the email using the recipient's language. If the 
  corresponding language-specific cache entry for tax_totals is not available, 
  the ORM cannot recompute the protected field and returns False instead 
  of the expected dictionary.

- The rendering code assumes tax_totals is always a dictionary and directly 
  calls  .get(), leading to the crash.

**Solution:**
- Exclude tax_totals from _get_protected_vals().
- tax_totals is already handled explicitly after create()/write(), so protecting 
  it is unnecessary. This allows the field to be recomputed during notification 
  rendering when required.

**Result:**
- Invoice notifications render correctly in all languages.
- No RPC crash occurs when rendering notifications after Quick Edit.

**Runbot reproduction: [video](https://github.com/user-attachments/assets/5f045efb-37de-40aa-b135-1368b1601d61)**

**opw-6209647**

Forward-Port-Of: odoo/odoo#266335

**Step To reproduce :**

1. Create a survey with `Scoring` set to `Scoring with answers after each page`
2. Add at least 2 pages, each with 1+ scorable question
3. As a public user, open the survey and start answering
4. Fill in the first page and click Continue
5. Correct answers are displayed with green/red highlights, submit button is replaced by Next
6. Click Next
7. Redirected to the homepage instead of the second page

**Issue:**

When survey scoring type is 'scoring_with_answers_after_page', after submitting a page the correct answers are displayed along with a "Next" button. Clicking "Next" redirects the user to the homepage because the answer_token is lost.

**Reason:**

The `<button id="next_page">` has no explicit `type` attribute, so it defaults to `type="submit"` per HTML spec. When clicked, the browser's default form submission fires a POST to `/survey/<survey_token>` (the answer_token is never in the URL path — only in the cookie). On the last page, `_nextScreen()` deletes the survey cookie to clean up after completion. The concurrent form POST then  arrives at the server with answer_token=None → `token_required` → `redirect("/")`.

Additionally, jQuery's event delegation matches `button[type="submit"]` against the `type` property (which is `"submit"` by default for bare `<button>` elements), triggering `_onSubmit` which makes a second stale RPC call, compounding the issue.

**Solution:**

Added `event.preventDefault()` in the Next button's click handler within `_showCorrectAnswers` to stop the browser's default form submission behavior at the event level. This prevents the unintended POST request regardless of the button's type attribute, ensuring only the JS-driven `_nextScreen` transition executes.

opw-6268296

Forward-Port-Of: odoo/odoo#269476

When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback.

Steps to reproduce the error:
- Install ``hr_recruitment`` module with demo data
- Go to Recruitment > Applications > Talent Pools > Create a new pool
- Go to Recruitment > Applications > All Applications > Create a new application with valid email >
  Click Add to Pool > Select the Talent Pool > Add to Pool
- Duplicate the created talent record
- Create another application with the same email > save > click Talent Pools

Traceback:
```py
ValueError: Expected singleton: hr.applicant(2, 1)
```

https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859
Here, the talent is searched using matching applicant information.
When a matching talent has been duplicated, the search returns multiple records.
Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error.

Solution:
Restrict the duplication of talent.

sentry-7556261128

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

Forward-Port-Of: odoo/odoo#270827

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729