Pre-requisite:
---------------------------------------
1. Install the Time Off module
2. Create a new company (e.g, Test Company)
3. Create New Timeoff Type: 
    * Ensure a default company is set (e.g, YourCompany)
4. Duplicate the created Time off type: 
    * Remove (Copy) from the name so both records share the same name
    * Clear the Company field on the duplicated record

Steps to reproduce:
---------------------------------------
1. Go to Time Off type which has no Company
2. Allocation Smart button > New
3. Set allocation for some days (e. g, 10 Days) > Approve allocation
4. Now, click on Employee > Time Off smart button
5.  On the Dashboard, you can see allocated leaves
6. Click on any day to create a Time Off Request

Observation:
---------------------------------------
The allocated Time Off Type is not available in the request wizard, even though allocation exists.

Issue:
---------------------------------------
When natively computing allocation statistics for the UI, the `_compute_leaves` loops through a pre-fetched `data_days` structure and incorrectly extracts the calculation metrics by matching the `holiday_status.name` string via a list comprehension lookup index (`item[0]`).
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294

If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list comprehension evaluates sequentially and forcefully maps the dictionary of whichever version structurally sits first in the memory sequence directly onto both overlapping identifiers simultaneously!

Solution:
---------------------------------------
Directly match records using their unique ID.
This ensures that each database record always retrieves its own correct data, preventing any mix-up or accidental sharing of values between records that may have the same name.

opw-6105759

Issue:
When creating a payment with an early payment discount, on an invoice using a cash rounding with a strategy of “Modify tax amount”, the early payment discount lines on the payment journal entry will be far off from the correct amount

Steps to reproduce:
1. Create a sales tax for 8.1%
2. Create a cash rounding record for 0.05 as the rounding precision, “Modify tax amount” as the rounding strategy, and “Nearest” as the rounding method
3. Create a payment term with early payment discount of 2% if paid within 18 days. And reduced tax on early payment. With a due term of 100% 30 days after the invoice date
4. Create an invoice on 1/1 with a subtotal of 339.60 and the tax of 8.1% and add the cash rounding method and payment term created earlier
5. Create a payment for it 9 days later on 1/10 for the full amount after the early payment discount is applied

Cause:
tax_amounts is grabbing the amount for a certain tax from the last line on the invoice with the same tax_repartition_line_id. Usually there is only one tax line representing a certain tax on an invoice. However, when a cash rounding is applied to the invoice with a strategy of “Modify tax amount”, the cash rounding line that is created will also have the same tax_repartition_line_id. In that case, it will grab the amount on the cash rounding line instead of adding the first tax amount with the cash rounding line amount

Solution:
In tax_amounts, add to the accumulating value if a tax repartition line id already exists as a key otherwise, insert it into tax_amounts

opw-5998497

__

## Short functional explanation of the error
When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they come from.

## Reproduction Steps
1. Go to settings. Under Inventory, in the Operations section, enable Packages.
2. Go to Sales and create a new quotation. Select a customer and add a kit product. Click on confirm.
3. Click on the Delivery smart button. Click on Put in Pack and Validate.
4. Click on the small cog > Print > Delivery Slip.

### Expected behavior
The kit from which the components belong should be indicated somewhere on the slip.

### Unexpected behavior
The kit isn't indicated.

## Origin of the issue
When we print a delivery slip without putting in pack, we can see on the slip that the first line, in bold, corresponds to the kit name. However, after putting in pack, the first line, in bold, indicates the Package id:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L116 Thus, the lines after will correspond to the components, of which we retrieve the details with:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L125 However, in `_get_aggregated_product_quantities`, we set the description of the components to an empty string under that case: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/mrp/models/stock_move.py#L180-L181 leaving us with no description for the components, and therefore not indicating the kit to which they belong.

__
opw-6006514

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#260566

When applying a cash rounding with 'biggest tax' strategy, it happens
that we end up with a MissingError when the invoice's partner is not
defined as commercial_partner_id.

Steps:

- Install membership module
- Create a cash rounding with the 'biggest tax' strategy and 0.05
  rounding
- Enable customer addresses and create a partner P with an invoice
  address I
- Create an invoice, select I as customer (P will be assigned as
  delivery address but this is not relevant)
- Add an invoice line for 100.03 and any tax and apply the cash rounding
- Confirm
-> MissingError: record has been deleted

Cause:

- When creating the cash rounding lines, we set the `partner_id` from the
invoice's partner (in our case partner I, which has P as
`commercial_partner_id`).
- When posting the invoice we look for lines that have partner id
  different than the invoice's commercial partner id and we call the
  write method to set the commercial partner id instead
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239
- In some cases, for example in the `membership` module, the override of
  the write method calls the super() before using `self`.
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49
  But the super triggers the `_sync_tax_lines` mechanism, during which
  the rounding line in deleted
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114
  Therefore `self` doesn't exist anymore
  when comming back in the override

Fix:

Setting the commercial partner on the rounding line to avoid calling the write method

opw-6128868