Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.

This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.

Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.

This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.

⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.

Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:

|                       | Before  | After  | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time  | 400ms   | 160ms  | 2.5x        |
| Frontend process time | 3.3s    | 220ms  | **15x**     |
| Total (LCP) time      | 3.7s    | 380ms  | 9.7x        |
| Response Payload size | ~800KiB | ~33KiB | **24x**     |

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

Forward-Port-Of: odoo/odoo#232354

Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.

This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.

Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.

This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.

⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.

Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:

|                       | Before  | After  | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time  | 400ms   | 160ms  | 2.5x        |
| Frontend process time | 3.3s    | 220ms  | **15x**     |
| Total (LCP) time      | 3.7s    | 380ms  | 9.7x        |
| Response Payload size | ~800KiB | ~33KiB | **24x**     |

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

Forward-Port-Of: odoo/odoo#232354

Purpose:
--------
When chatting with an agent one can now upload files (or attach documents
if documents is installed) that will be processed by the LLM to generate
the answers

Technical Changes:
------------------
To support this feature, files needs to be inside their related messages.
Previously they were simply appended to the list of inputs that were sent
to the LLMs, but that does not work inside a chatter because one sends the
history of messages. So if a user uploads a file in its first message, then
another one in the second message, one can't append them both to the list
of inputs otherwise the LLM would consider the first one as a new upload,
instead of an attachment from the previous message.

The `request_llm` method of the llm api service has been refactored to be
able to achieve this, and simplify the addition of attachment in any
message.
Instead of having 3 parameters "user_prompts", "inputs" and "files", there
is now only one parameter "messages".
Messages should always be either a string (considered as user prompt),
either a dict containing the role and the message parts:
```py
{'role': 'user', 'parts': [
    {'type': 'text', 'content': 'hello'},,
    {'type': 'image/png', 'content': 'aW1hZ2UgY29udGVudA=='},
    {'type': 'application/pdf', 'content': 'cGRmIGNvbnRlbnQ='},
]}
```
These messages will be converted to the format expected by the different
providers before the loop calling the llm so that the llm answers can be
appended to this message list.
The tools are now also converted before the loop (there is no real need
to convert them in every loop iteration.

Task-5031785

[IMP] account_accountant: css backport

To have a consistent css across all version of the new bank rec widget, we
decided to backport few changes.

backport of:
https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a
https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb
https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667
https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a
https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e

[FIX] account_accountant: restrict some account in the set_account

Before this commit, we could select the liquidity account or bank suspense
account which could create a reco model for it that would do nothing.

[FIX] account_accountant: partner_name

Before this commit, when a transaction had no partner_name and some lines with
the same partner. When unfolded, we had the info of the partner on the statement
line and on the line itself which was a duplicate of information.

This commit will change when the line is unfolded so that the partner is visible
on the statement line only when there is a partner_name

[FIX] account_accountant: payable and receivable button

Before this commit, the payable and receivable buttons where on the top line
only when the reconcile button was not there anymore. Now We decided to always
have them present in secondary next to the reconcile button.

no task-id

Forward-Port-Of: odoo/enterprise#98458
Forward-Port-Of: odoo/enterprise#96852

The commit:
1. use static property to configure a builder option
2. introduce the concept of dependencies to access the plugin's shared
   in builder option
3. make a plugin context the same for Plugin, BuilderOption and
   BuilderAction to have the same API in each class.

Before this commit, to define an option, we had to define a javascript
object that would contain the information of the option within the
`builder_options` resource.

```js
class MyPlugin extends Plugin {
    resources: {
        builder_options: [
        {
            selector: "div.selector",
            template: "my.owlTemplate",
            cleanForSave() {}
            // ... other option props
        }
        ]
    }
}

// For a custom component
class MyPlugin extends Plugin {
    resources: {
        builder_options: [
        {
            selector: "div.selector",
            template: MyCustomComponent,
            cleanForSave() {}
            // ... other option props
        }
        ]
    }
}

class MyCustomComponent extends BaseOptionComponent {
    // ...
}
```

When building anything for the builder, there is 3 classes that are
important: `Plugin`, `BaseOptionComponent`, `BuilderAction`.

In practice, the option object defined in builder_options feels
strange. On the other hand, making the configuration of the option as
a static property of the component somehow feels simpler as everything
related to that option is defined in the same class.

```js
class MyPlugin extends Plugin {
  resources: {
    builder_options: [MyCustomComponent]
  }
}

class MyCustomComponent extends BaseOptionComponent {
  static template = "my.owlTemplate";
  static selector = "div.selector";
  static cleanForSave(context) {}
  // ...
}
```

To have the same mental context in the 3 important class, they all
share the same API (`dependencies`, `dispatchTo`, `getResource`, ...)
(see `Editor.getPluginContext`)

To access a plugin shared method, it's now the same for `Plugin`,
`BuliderAction` and `BaseOptionComponent`:

```js
class MyCustomComponent extends BaseOptionComponent {
    static selector = "mySelector";
    static dependency = "myPlugin";
    myMethod() {
        this.dependencies.myPlugin.pluginMethod();
    }
}
```

To access a resource, dispatch, ...:

```js
class MyCustomComponent extends BaseOptionComponent {
    static selector = "mySelector";
    myMethod() {
        const resource = this.getResource('myResource');
    }
}
```

Forward-Port-Of: odoo/enterprise#96515
Forward-Port-Of: odoo/enterprise#94102

Description
-----------
The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`.

To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM.

This leads to a few more queries, but each is fast and trivial to process.

Benchmark
---------
On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took:

| Before | After | Speed-up |
|--------|-------|----------|
| 13.3s  | 80ms  | 162x     |

Forward-Port-Of: odoo/enterprise#98098

Description
-----------
The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`.

To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM.

This leads to a few more queries, but each is fast and trivial to process.

Benchmark
---------
On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took:

| Before | After | Speed-up |
|--------|-------|----------|
| 13.3s  | 80ms  | 162x     |


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

Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues.

The reconciliation logic worked as follows:

1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`.
2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`.
3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`.

The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`.

---

To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced.

- Reconciliation now starts by iterating only over the relevant `in_moves`.
- If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`.
- This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited.

**Implementation details:**

- An `OrderedSet` is used for the inverse mapping to preserve the original query order.
- Benefits of `OrderedSet`:
  - **O(1)** removal (assuming no collisions)
  - Maintains insertion order, ensuring the same order as the query result.

---

| Metric        | Before PR | After PR |
|---------------|-----------|----------|
| Execution Time| ~90 sec   | ~10 sec  |

The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`.

opw-4951469