This commit improves the handling of a document's discoverability setting (`is_access_via_link_hidden`) when it is moved between folders.

Previously, when a document was moved, it would inherit the discoverability setting from the destination folder. This could lead to unintended changes in a document's visibility. For example, a publicly discoverable document could become private (requiring a direct link) simply by being reorganized into a different folder.

This behavior was inconsistent with a previous improvement that prevented discoverability from propagating downwards from a parent folder to its children. See PR-93697.

With this change, a document's discoverability is now treated as an intrinsic property that is fully preserved when the document is moved. It is no longer affected by the settings of its destination folder.

To ensure clarity for the user, the move confirmation dialog has been updated to reflect this new logic. It now correctly informs the user that the document's original discoverability setting will be maintained.

Task-5159832

Forward-Port-Of: odoo/enterprise#97045

*= co, ec, kr, us, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105838
Forward-Port-Of: odoo/enterprise#105262

Steps to reproduce the bug

- Create a storable product P1:
  - Tracking: Serial Number
- Log in as Marc Demo
- Create a sales order with 1 unit of P1
- Validate the delivery using serial number SN1
- Log in as Mitchell Admin
- Go to Settings:
  - Manage Users
    - Mitchell Admin
      - Sales: User: own documents only
- Go to the Serial Numbers list view:
  - Try to open SN1

**Problem:**
An access error is triggered:

```
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Mitchell Admin (id=2) doesn't have 'read' access to:
- Sales Order Line, S00025 - P1 (Deco Addict) (sale.order.line: 51)

Blame the following rules:
- Personal Order Lines
```

When clicking on SN1, the `stock.lot` form view.
it's contains the field "sale_order_count", which is a computed field that needs to access all `sale.order` records using the serial number in order to compute the count.

Since Mitchell Admin is restricted to his own sales orders only, an access error is raised during the computation.

There is also a many2many view widget that triggers an access errors. This widget can be removed since the smart button is now available. The widget has already been removed in v19.

**Solution:**
In this view, any stock user, admin or not, must be able to see how many sales orders use a given serial number, regardless of whether those sales orders belong to them or not.

opw-5400731

Forward-Port-Of: odoo/odoo#246009
Forward-Port-Of: odoo/odoo#244570

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#105102
Forward-Port-Of: odoo/enterprise#102557

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

[Task-5411760](https://www.odoo.com/odoo/project.task/5411760)
Backport of https://github.com/odoo/enterprise/pull/104885

Forward-Port-Of: odoo/enterprise#105022

Server actions that were standalone (not a child) and embedded on
a documents folder cannot be executed anymore when they are linked
to a parent action.
Before saas-18.3, the embedded child action would still be in the
documents' available_embedded_actions, and couldn't be removed,
such that a fix was necessary.

From saas-18.3 onwards, children embedded actions are no longer
visible.

As this precise case wasn't explicitly tested, we continue the
FW-port with the (adapted) test.
Furthermore, we add a garbage collection of the embedded actions
for children actions, as they cannot be executed anymore.

Initial FIX:

### ISSUE

It is possible that certain embedded actions visible in a folder
cannot be found or deleted through the interface, as they are not
displayed under the folder's server actions list when clicking on
the gear icon.

This is caused by overly broad filtering in
documents.document.get_documents_actions, which removes all child server
actions regardless of whether they were embedded in the folder.
So if a user creates two embedded actions inside a folder, then modifies
the underlying server actions so that one is the child of the other,
the embedded action associated with the child server action would
disappear from the folder's actions list but would still be embedded in
the folder making it impossible to remove it through the UI

This patch updates the logic so that only non-embedded child actions are
excluded. Embedded actions remain visible and manageable as expected.

opw-5213881

Forward-Port-Of: odoo/enterprise#105235
Forward-Port-Of: odoo/enterprise#100395

The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`.

Before this commit:
- functionally: The obvious matching was denied and the accountant had to manually make the match.

- technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word.

After this commit:
- functionally: The obvious match is made.

- technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

Forward-Port-Of: odoo/enterprise#105648

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105535
Forward-Port-Of: odoo/enterprise#102714

Problem:
- In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant.

Current behaviour:
- Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient.

Expected behaviour:
- Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided.

Solution:
- Do not set ‘state=“open”’ for payment records created from a sale involving
  the data wizard for records. Ensure they remain in “draft”.
- Confirm registrations once attendee details are present.

Advantages:
- Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner.
- Meets functional expectations for administrative control and proper recipient targeting.

Tests to reproduce the error:
- Create quote with payment entry
- Confirm SO
- Enter attendee details and confirm
- Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee.

@Tecnativa TT58160

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

Forward-Port-Of: odoo/odoo#230500

**Issue**
When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities.

**Steps to reproduce**
- Create a product with a BOM using a component with qty 6.
- Create an MO producing qty 1.
- Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed).
- Click “+1”.
- Edit the component qty from 6 to 3.
- Exit the operation.
- Re-enter the operation.
-> The component shows 3/3 instead of 3/3 and 0/3.

**Cause**
On exit, `_onExit`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489
calls `post_barcode_process()`, which triggers `split_uncompleted_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16
correctly creating a `stock.move.line` with qty 3.

However, `_truncate_overreserved_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40
then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49

This happens because the newly created move line is initialized with `reserved_uom_qty = 0`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256
leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6.

opw-5166763

Forward-Port-Of: odoo/enterprise#100314

First PR of multiple to rework the map UI / UX.

In this first PR we focus on the change from numbering the map marker 
according to the list item number to numbering the map marker by the 
number of records with the same address (previously done with badges)

Furthermore, now that the list between the task and the pin on the map
is less evident (no more numbering to link the two), we add some hover
effects: on the map marker hover we highlight the list item, and on the
list item hover, we make the map marker bigger in the map.

List of all changes:

- Side panel - Removed List title
- Side panel - Replaced the drag handle from the far right to far left of the task.
- Side panel - Removed numbering of tasks. 
- Side panel - Move and restyled "View in Google Maps" button to control panel.
- Side panel - On hover of the list item make the related map marker bigger.
- Side panel - Add some coloring change to the handle on the handle hover.
(This was done in an accounting module, and I find it a good addition to 
the mouse pointer changing on handle hover)
- Map - On hover of the marker, make the marker bigger and highlight the
related list item.
- Map - Remove badges from map marker with multiple records address.
- Map - Change numbering from representing the list item number to the
number of records with the same marker. 
- Map - On the mobile view, no more toggling of tasks.

--> We do not yet address any grouping logic.

task#5259181
documentation PR: odoo/documentation#16092

Following PR: odoo/enterprise#104812

This commit improves the handling of a document's discoverability setting (`is_access_via_link_hidden`) when it is moved between folders.

Previously, when a document was moved, it would inherit the discoverability setting from the destination folder. This could lead to unintended changes in a document's visibility. For example, a publicly discoverable document could become private (requiring a direct link) simply by being reorganized into a different folder.

This behavior was inconsistent with a previous improvement that prevented discoverability from propagating downwards from a parent folder to its children. See PR-93697.

With this change, a document's discoverability is now treated as an intrinsic property that is fully preserved when the document is moved. It is no longer affected by the settings of its destination folder.

To ensure clarity for the user, the move confirmation dialog has been updated to reflect this new logic. It now correctly informs the user that the document's original discoverability setting will be maintained.

Task-5159832

What:
Previously, actions like "Create Vendor Bill" were only embedded in the
main "Finance" folder. Now, these actions are also embedded directly into
the specific subfolders for each journal type (e.g., "Purchase", "Sales").
All relevant actions are also kept in the parent "Finance" for general
accessibility. The purchase actions are also added to the "Inbox" folder.

Why:
The previous behavior was inefficient. A user uploading a vendor bill to
the "Purchase" folder would not see the "Create Vendor Bill" action. He
would only see it when he is in the parent "Finance" folder. By embedding
it by default this streamlines the process by ensuring the necessary tools
are available exactly where the user is working.

How:
The logic is implemented within the _documents_configure_sync method of
the account.journal model. This is the ideal location because it
handles the complete setup of a journal for the Documents app. This ensures
that actions are embedded correctly both during module installation and
dynamically whenever a new journal is created by a user.

Notes:
- Tests were rewritten to check these embeddings on install. And were
refactored to be more maintainable and cover bank statements better.
- The test for importing bank statements had to be moved to a separate
testing module, as it needs the `account_bank_statement_extract` module,
which is not in the dependencies of `account_move`.
- The tests for bank statement processing errors was improved to match
the tests in later versions

Task-5410752
Related Task-5075610

Server actions that were standalone (not a child) and embedded onto a documents folder
cannot be executed anymore when they are linked to a parent action.
Before saas-18.3, the embedded child action would still be in the documents'
available_embedded_actions, and couldn't be removed, such that a fix was necessary.

From saas-18.3 onwards, children embedded actions are no longer visible.

As this precise case wasn't explicitly tested, we continue the FW-port with the (adapted) test.
Furthermore, we add a garbage collection of the embedded actions for children actions, as they cannot be
executed anymore.

Initial FIX:

### ISSUE

Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface.

This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder.

As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI.

### SOLUTION

The method has been updated to exclude only non-embedded child actions.
Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected.

opw-5213881

Forward-Port-Of: odoo/enterprise#105235
Forward-Port-Of: odoo/enterprise#100395

Steps to reproduce:
1. Install `marketing_automation`
2. Create a campaign with activity and click on `Launch a test` button
3. Clear the input field and then click outside the input area

Issue:
- The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it

Cause:
- Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>`
https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119

Solution:
- Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty

Note:
- This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed.

opw-5473320

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#100749

## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).

## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
    - *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
    - *Wages and salaries*: **649 is not mentioned**
    - *Social security charges*: **649 is not mentioned**

## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.

opw-5724559

Forward-Port-Of: odoo/enterprise#105474

Steps to reproduce:
- Choose France as the company location, and download "France - Work Entries Time Off" module.
- From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off.
- Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025.
- While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone.
- From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025.
- From the employee's profile > Time Off, try to take a Monday off.

Issue:
- The user gets a Validation error stating that the "start date" is later than the "end date".

Fix:
- In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off.
- Add a check to remove lines from calendar that are just there for display purposes.

opw-5387347

**Issue**
In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line quantities.

**Steps to reproduce**
- Create a subcontracting BOM of a final product using 1 component product
- Create a PO of the final product for a quantity of 10 and confirm it
- Modify the BOM to use 2 component products instead
- Go to the receipt of the PO and modify the quantity to 2 and validate it
- Click on the move line of the receipt -> The displayed quantity is 10 instead of 2

**Cause**
Setting the quantity triggers this line:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L78-L78 
which calls:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L107

Since the BOM has been modified, a `consumption_issues` is detected and `_update_finished_move()` won't be called:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L86-L89

And since the returned action is not used when calling `subcontracting_record_component`, `_update_finished_move()` won't be called later neither, which is the method responsible for updating the move line quantities:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L142-L146

**Solution**
Since the consumption issue actions are ignored in this case, just skipped it and avoid inconsistencies.

opw-5493577

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value.

opw-5172669