## Steps to reproduce:

- Configure event registration with only free-text fields (no selection field).
- Open the POS, add an event ticket product, and fill in the registration form.
- Click Payment and validate the order.

## Issue:

- Registration answers were only sent to the backend when at least one selection-type question was filled.
- When no selection field was present, free-text answers were not synced at all.

## Reason:

- The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85

- This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75

## Fix:

- Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`.


task-5438565

Forward-Port-Of: odoo/odoo#250106
Forward-Port-Of: odoo/odoo#242465

### Steps to reproduce:
- Download Planning app
- From the top bar 'Employees' > 'Employees', create a new employee
- From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB)
- Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated

> If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError**

### Cause of issue:
https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. 
https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17

### Fix:
Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`.

opw-5953671

Forward-Port-Of: odoo/enterprise#109823

Note about v19.1:
Since the bug isn't present in this version, we'll only merge the test.

**Description of the issue this PR addresses:**
Thread unread counters should reflect the actual backend state 
as soon as Inbox messages are loaded, not only after a new bus 
notification is received.

**Steps to Reproduce:**
- Log in as User A and User B.
- Ensure User A preferences set to Handle in Odoo.
- From User B, mention User A in the chatter of a record.
- From User A, Open the messaging menu, counter for that related thread 
is correct.
- Refresh the page.
- Open the messaging menu again, the thread now shows a grey badge 
instead of the expected unread counter.

**Current behavior before PR:**
- When loading Inbox messages, related `mail.thread` records 
(such as project.task) did not include unread counters in the store payload. 
As a result, threads that already had unread messages appeared as (grey badge) 
after a refresh, leading to an incorrect counter state.

- Additionally, frontend-only counter adjustments could sometimes lead to 
inconsistent or even negative unread values due to missing initial sync.

**Desired behavior after PR is merged:**
- Threads with existing unread messages now receive the correct counter state, 
when Inbox messages are fetched.
- This also prevents inconsistent or negative counter values caused by 
frontend-only updates.

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

Before/After (**on refresh**):
<img width="461" height="55" alt="image" src="https://github.com/user-attachments/assets/2fc57aba-049c-4129-95b1-1d2b2770ac66" />

<img width="469" height="57" alt="image" src="https://github.com/user-attachments/assets/111d10bb-2aec-4711-8f5a-af7f332021d8" />



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

Forward-Port-Of: odoo/odoo#247569

Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` 
is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report.

**Steps to reproduce:**
- Install the `l10n_be` module and switch to the `BE company CoA`.
- Navigate to `Invoicing > Configuration > Taxes` and open any tax (e.g., 6%).
- Replace the `Tax Grid` with `61` on the second line under `Distribution for Invoices`, then `save`.
- Navigate to `Customers > Invoices` and create and confirm an invoice using this `tax`.
- Navigate to `Reporting > Tax Report` and select the current month.

**Observation:**
- The report shows a warning: `The report contains negative amounts. This is normally not allowed and could cause the tax authorities to reject it.`
- Case `61` under `Taxes > IV Due` displays a `negative` value.

**Root Cause:**
At [1], all formulas under `IV Due` use a negative sign (-XX) except for case `61`, 
which uses `61` instead of `-61`. Since the concept of `inverted tax tags` was 
removed in v19 in PR [2], case `61` must follow the same sign convention 
as the other `IV Due` cases to ensure correct reporting behavior.

**Fix:**
This commit updates the formula of case `61` to `-61`, aligning it with the 
other `IV Due` lines. As a result, the VAT report no longer displays an incorrect 
negative amount for case `61` and prevents the related `warning` from appearing.

[1]:
https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/l10n_be/data/account_tax_report_data.xml#L497-L596

[2]:
https://github.com/odoo/odoo/pull/225252

opw-5866225

Forward-Port-Of: odoo/odoo#248961

*google_address_autocomplete,partner_autocomplete

This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component.

Those widgets rely on the `useInputField` hook, because they basically render an input (spiced with the autocomplete feature), so they must handle "manual" updates (listen to `input`, `change`, `keydown` events), like regular input fields.

However, the input also acts as a "search bar" for the autocomplete. As a consequence, it might happend that the `useInputField` hook internals weren't correctly reflecting the actual state of the field.

Here's a faulty scenario to highlight the issue, involving any of the two widgets:
 - open a form view with the field set to value "XYZ"
 - type in the input "ABC" and select a suggestion from the autocomplete dropdown => say the value is now "Value ABC"
 - manually erase the content of the input and type "XYZ" as before
 - save => the value sent to the server was actually "Value ABC"

The reason is that the hook still believes that the field is dirty after the value has been picked from the dropdown, and set (in the model) to "Value ABC", so `lastSetValue` isn't correctly updated to "Value ABC" (it's still "XYZ"). Later on, after the manual update to go back to the value "XYZ", we compare this value with `lastSetValue`, and as they are the same, we do nothing, so the value in the model remains "Value ABC".

Those widgets need to use the hook, because the logic encapsulated inside it is really tricky and we don't want to duplicate it. But the hooks internals aren't exposed, and we don't want to expose them to keep it under control. So we did the fix inside the hook itself: in `useEffect`, so after a patch, if the value in the model is the same than the value in the input, it means that the field isn't dirty anymore, so we force-reset the flag to `false`. This scenario only makes sense for inputs that are handled both internally by the hook and externally (e.g. by the autocomplete).

Task~6018655

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#252829

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/0f82c2f2af [REL] 19.1.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e05cd0e473 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572)
https://github.com/odoo/o-spreadsheet/commit/64b3655ed5 [FIX] spreadsheet: fix zoomable chart cursor [Task: 5012198](https://www.odoo.com/odoo/2328/tasks/5012198)
https://github.com/odoo/o-spreadsheet/commit/056b5c51bc [IMP] functions: Add `ISFORMULA` function [Task: 6013888](https://www.odoo.com/odoo/2328/tasks/6013888)
https://github.com/odoo/o-spreadsheet/commit/61f0761fd5 [FIX] charts: remove zoom slicer for scatter plot [Task: 5388389](https://www.odoo.com/odoo/2328/tasks/5388389)

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>