Make Knowledge feel a little bit more responsive by deferring the loading of some fields.
For both the PermissionPanel and the options panel we remove as much as possible the usage of separate RPC calls. This change made us rely more on the record Object populated by the DB values.

Tests were also implemented for each Component to test their behavior and ensure stability and robustness for the future.

There's also been some minor improvements to the behavior done.

#### PermissionPanel
* no more check that "based on" articles are accessible by the user (more coherent with the topbar "hierarchy").
* when the owner of a private article leaves the article, the article is sent to the trash instead of archiving it (as suggested by the confirmation dialog).
* portal users with permission "none" are not hidden anymore.
* the permission selectors are now dropdowns (more flexible than selectors and has a style that is consistent with the app).
* the "remove member" button has been replaced by an option in the permission dropdown.

#### Member rights escalation
* Allow a member to remove itself from an article if its member permission is the same as the inherited_permission.
i.e. a read access member on a readonly article can remove itself:
  - this allows an action symmetry (a user can join a readonly article and also remove itself as a member to see/hide it in the sidebar)

#### OptionsDropdown
* The bootstrap dropdown has been replaced by a separate Component that uses the Dropdown class provided by the framework.
* The bus system for toggling each panel has been replaced by a reactive object in the environment provided by the Controller. This doesn't rely on d-none class on the parent any more to hide/show each panel.

Task-4273102

**Year to date computation improvements**

-   Some inputs on the YTD can go to multiple rules. Therefore,
    we add manual recomputation of the inputs for payslips.
    It uses opening balances to compute the total payslip YTD
    values.
-   A major update is the addition of Income Stream types to
    Year to Date values. This allows for grouping payslips with
    income stream type for employees that may have multiple income
    stream through a single fiscal year. STP requires reporting
    the year to date values for each income stream type separately.

**Single Touch Payroll Improvements**

-   Adds income stream types to the STP report. This
    allows for users with multiple income streams in
    a single fiscal year to be repored without finalisation.

-   Fixes Termination payments for genuine and
    non-genuine redundancy payments and how taxes are
    reported for taxible and non-taxible components.

-   Fixing Full file replacement for STP. This adds
    constrains for FFR, allows old payments to auto reconcile
    on a changed payslip after resubmission.

-   Adds support for missed reporting of payslips.
    If a user forgets to report a pay period and continues
    with the next pay period, They have 2 options:
        1.  Create a back dated submit event with the old
            year to date values.
        2.  Create an update event that amends the year to date
            values at todays date.
    In odoo we go for option 2. For a missed report, we create an Update
    event that updates all the ytd values up til today's date.

-   Fixes zeroing of YTD on Single touch payroll.

-   Adds a correction input type for Basic salary corrections
    without having to make any changes to past payslips. This helps
    cover under or over-payments

-   Improve validation for Single touch payroll. With better
    testing and file generation. This adds better error
    handling before running the xml validation step. This
    lowers the possibility of errors after file generation.

-  Improve performance for YTD computation to allow batching and
   caching of the values using computes on the payslips. Relies fully 
  on the ORM using search_fetch to optimize queries for the YTD 
  computation. 
    
**AU Payroll Payment reconciliation**

-   Allows old payments to auto reconcile on a changed
    payslip after resubmission.

**Standard Fixes**
-   Allow auto install of hr_payroll_account if accounting and Payroll
    app are installed. This also subsequently installs localised versions.

-   Payment register wizard fails to compute the amount, journal, etc
    since the `_compute_from_lines` is not triggered. This is because
    partner_id is the only field in the view to trigger that compute before
    create. And when a default value is passed for the partner, there is no
    need for the compute to trigger on a new record before save.

-   Salary attachments with the same code inputs always
    used the last input in the sequence for all attachments.
    This commit changes the behavior to allow multiple
    attachments with the same code inputs.
    
    
-   Salary rules generate multiple payslip lines for
    multi rule lines, but the result_rules in the
    local_dict are not updated. This commit fixes that
    and sums up the totals and amounts for all the lines
    in that rule.
    
    Task# 4201469

Forward-Port-Of: odoo/enterprise#83173
Forward-Port-Of: odoo/enterprise#75695

…mesheet

**Issue**
In a subscription, the qty delivered of a SOL with "Prepaid" invoicing policy
wasn't updated when timesheets were added.

**Steps to reproduce**
1. Have a service subscription product with an invoicing policy "Prepaid/Fixed
price" and creating a task on order.
2. Create a monthly subscription with a start date 15 days in the past
3. Add some timesheet hours on the task.
4. Run the "Subscription: generate recurring invoices" cron.
- Actual: quantity delivered on the SOL stays at 0.
- Expected: timesheet hours falling during the subscription period are added
to the delivered quantity of the line.

**Cause**
Commit https://github.com/odoo/enterprise/commit/a6420bdacab3b9c9f440f48db3b442e6b6c7b655 added a new module overwriting
the computation of the delivered quantitiy for recurring lines based on
timesheets, for products with an invoicing policy `delivered_timesheet`.
However, the computation is overriden for all timesheet lines selected by
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L11-L12

A second filtering is applied later
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L21
Which exluces products with an invoicing policy different than
`delivered_timesheet`

**Solution**
For products with a "prepaid" invoicing policy, compute the delivered
quantities the same way: the timesheets delivered during the subscription
period.
Note that as explained in a comment, `Side effect: It won't work for the
first period if the invoice cron never run. (the next invoice date has never
been incremented)`

opw-4509495

Forward-Port-Of: odoo/enterprise#82917
Forward-Port-Of: odoo/enterprise#82806

### Steps to reproduce:

- In the settings enable by products.
- Create two products FP and SN where SN is tracked by serial numbers
- Create and confirm an MO for FP where SN is a by product
- Open the shopfloor > Register By-Product > generate serial numbers
  > input SN0012 > Generate > Save
#### > your input was not taken into account, not lot was created.

### Cause of the issue:

Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_dialog`. Clicking on Generate will then call the `_onGenerate` method and an rpc call of the
`action_generate_lot_line_vals` will be made:
https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/lots_dialog.xml#L12 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/generate_serial.js#L34 However, if you triggered these actions from the shopfloor, you never provided a `default_picking_type_id` in the context so that the lot will never be created by any mean:
https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L919-L927 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L945-L948

opw-4544734

Forward-Port-Of: odoo/enterprise#83356
Forward-Port-Of: odoo/enterprise#82355

As this savepoint was initiated in a loop, it could lead to many subtransactions (one savepoint per document to upload) being active at the same time, causing performance issues (more info at [1]).

The main goal of that savepoint was to be able to recover from a SQL serialization failure that could occur when the document to upload was modified concurrently.

This was mostly useful in version 16.0 where the upload of the documents to the OCR server was performed asynchronously through a cron. This greatly increased the likelihood of serialization errors.

In version 17.0, we went back to synchronous uploads (commit 9df91d8), these should be much less frequent.
Considering this, it seems reasonable to remove the savepoint, although it implies that if such error occurs, the SQL transaction will be rollbacked and some OCR credits might be lost in the process.

[1]: https://www.postgresql.org/docs/current/subxacts.html, in particular the last sentence:
> The more subtransactions each transaction keeps open (not rolled back
> or released), the greater the transaction management overhead. Up to
> 64 open subxids are cached in shared memory for each backend; after
> that point, the storage I/O overhead increases significantly due to
> additional lookups of subxid entries in pg_subtrans.

Forward-Port-Of: odoo/enterprise#83248

*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi

1. fix the summary of account.move.send.batch.wizard

The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened).

We also always put email as a fallback, even if no email is set, since it can be added through the wizard.

2. fix batch send of Peppol invoices when no format set

In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent.

[1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad

3. Remove 'skipped' state of Peppol moves

This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error.

task-no (review with TSB and PMAX)

**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
 Traceback (most recent call last):
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
    return _compute_field_value.origin(self, field)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
    partner_tickets.fetch(['stage_id'])  # prevent over-fetching fields, leading to potential out-of-memory error
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
    self.check_access('read')
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
    if not self.env.su and (result := self._check_access(operation)):
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
    if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
    data = record.mapped(key)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
    recs = recs._fields[name].mapped(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
    self.__get__(first(remaining))
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
    return super().__get__(records, owner)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
    recs._fetch_field(self)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
    self.fetch(fnames)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
   File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
    return [] if self.cr.description is None else self.cr.fetchall()
 MemoryError
 ```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`

Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance

upg-2707381
opw-4653413

### Step to reproduce:

- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
    - 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units

### Cause of the issue:

When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case  there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.

opw-4562965

Forward-Port-Of: odoo/enterprise#82958
Forward-Port-Of: odoo/enterprise#81818

### Issue:

It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point.

### Step to reproduce:

- Set up Sendcloud, for a belgian company
- Select bpost and dpd for delivery and returns while loading products
- On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method.
- With an employee confirm the delivery order that was created
#### > A problem occured in the generation of the return label

### Cause of the issue:

The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here:
https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point.

#### Note:

Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels.

opw-4562040

Forward-Port-Of: odoo/enterprise#83436
Forward-Port-Of: odoo/enterprise#83357