Before this commit:
-------------------------
- In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the final product move showed an Incorrect destination location.
- Instead of showing the selected failure location, the system displayed another location as the move destination after completing the repair process.

Steps to reproduce:
-------------------------
1. Install the Repair and Quality modules.
2. In Quality, create a Control Point with:
   - Type = Pass-Fail
   - Control Per = Product
   - Set at least 1 Failure Location
3. Create a Repair Order for any product and start the repair process.
4. Perform a quality check, set it to Fail, and select a failure location.
5. Open the product moves, the destination location is incorrect (not the selected failure location).

Cause of the issue
-------------------------
The failure location was not correctly assigned when the quality check failed during the repair process because the logic relied on stock pickings to determine the destination location. However, in repairs, quality checks are performed independently of stock pickings.

After this commit:
-----------------------
- When a quality check fails in a repair order, the product’s destination location is correctly set to the failure location selected by the user.
- This ensures accurate traceability of failed products and simplifies stock adjustments across locations.

Task ID: 5254334

**Steps to reproduce**

1.Install Accounting, Contacts, and l10n_cz.
2.Create an invoice with a future `invoice date` and confirm it. 
3.Go to Contacts → open the company (res.partner). 
4.Modify any address field (street, zip, etc.) and save. 
5.Return to the invoice → in the chatter, the `date` field has change unexpectedly

> Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction.

**Issue**
- The confirmed invoice `date` changes when updating the company partner’s address.

**Cause**

https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24


- When creating an invoice, the `date` field is correctly set based on the 
`taxable_supply_date` while the invoice is in the draft state. After 
confirming (posting) the invoice, it moves to the `posted` state.

- However, when updating the partner address, the `_compute_date` method 
is triggered again, which calls `super()` and recomputes the `date` field 
using the standard logic. Since the invoice is already in the `posted` 
state, the CZ-specific condition is not satisfied, and the `date` gets 
updated incorrectly.

 **Solution**

- Update `_compute_date` to only call super() for invoices in draft state.
- This prevents unwanted recomputation of the `date` on post invoices.

opw - 5086961

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

Forward-Port-Of: odoo/odoo#238045
Forward-Port-Of: odoo/odoo#229513

When the address step is skipped during checkout or a partner has no country set, the PayPal address formatting would include falsey values (False/None) for country_code, which caused PayPal API requests to fail with 'Country: False' errors.

This fix:
1. Adds null checks for state_id and country_code to prevent accessing attributes on missing relationships
2. Ensures only truthy values are included in the address dictionary
3. Adds fallback country code selection (company currency 'US') for public partners to guarantee a valid country code is always sent

Fixes #237360

Description of the issue/feature this PR addresses:

When checking for missing country codes during PayPal checkout, the system would include falsey values (False/None) in the address dictionary, causing API validation errors.

Current behavior before PR:

PayPal API requests fail with 'Country: False' or similar errors when address country or state information is missing or the address step is skipped during checkout.

Desired behavior after PR is merged:

The PayPal address formatter should gracefully handle missing address information by filtering out falsey values and providing fallback country codes, ensuring all API requests have valid address data.

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

purpose: fix the issue when a user who is `hr_holiday_responsible` creates a multi timeoff request, where an access right error appears because they don't have access on Employee.

Steps to reproduce:
- login as someone who has `group_hr_holidays_responsible`
- create group leaves for employees you are responsible for
- create conflicting leaves
- you get access right error because you can't read field `private_name`

Current behavior:
- fixed access right error on creating group leaves for `group_hr_holidays_responsible`
- added `test_create_conflicting_group_leave_without_hr_right` for creating conflicting group leave with `group_hr_holidays_responsible` access right
- added `test_create_group_leave_form_allocation_mode_without_hr_right` for creating group leave directly from allocation mode (without choosing specific employees) with `group_hr_holidays_responsible` access right
- added `test_create_differnt_calendars_group_leave_without_hr_right` for creating group leaves for employees with different calendars with `group_hr_holidays_responsible` access right

task-id: 5051859

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

Writing in indexeddb can throw a QuotaExceededError (or a DOMError with QuotaExceededError message in firefox). Before this commit, this error was basically ignored, so it wasn't shown to the user, but from that point, all writes in idb would fail with that same error, until a database schema change or an hard reload.

This commit handles the error quite radically: when it is thrown, we delete the rpc database to start over. More elaborated strategies could be considered, like removing oldest entries, but we decided to go for the simplest solution. In master, we may introduce a more complex garbage collect strategy as for the offline mode, it might be interesting to keep some entries alive. In 19.0 though, the caches are only used to speed up the webclient, so it's not an issue to clear them completely and start over.

We also want to avoid Odoo to use an unreasonable disk space. However, the storage capacity depends on the browser (e.g. 10Gb on firefox, up to 60% of disk space on chrome). To prevent Odoo from taking tens or hundreds of gigabytes on the user's disks, we limit the storage to 2Gb.

Task~5217456

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

**PROBLEM**
Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg).

**STEP TO REPRODUCE**
1. create a product.
2. create a bom with:
 - a component tracked by lot, with kg as product uom, but g as the bom uom.
 - create a step, during which 50g of the component is consumed.
3. create two lots of the component, with 1kg each.
4. create a MO for the product with the bom.
5. in the shop floor, try consuming the component and select one of the lot as a source.
6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove).
7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g).

**CAUSE**
1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant.
2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g.
3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter).

opw-5136050

Forward-Port-Of: odoo/enterprise#97005