Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

https://github.com/odoo/odoo/pull/164316

**Current behavior:**
A picking with a move for a product with kit BOM that also has some product packaging can be un-openable in Barcode.

**Expected behavior:**
Any picking should be able to be processed in Barcode.

**Steps to reproduce:**
*Enable product packagings*

1. Create a storable product with a kit BOM and a product packaging

2. Make some picking that has a move for the new product, confirm it so the moves for the kit components are created

3. Add stock move lines for each of the moves, fill out their `qty_done` field with the required amount

4. Save the picking record, go into Barcode

5. Try to open the picking -> trace back

**Cause of the issue:**
The Barcode client tries to read the package record of the BOM product/product template but it was never fetched into the barcode cache.

**Fix:**
Ensure any packaging record that could have an attempted access is fetched by the barcode client `onWillStart()`.

opw-3895426

Forward-Port-Of: odoo/enterprise#64750
Forward-Port-Of: odoo/enterprise#64024

**Steps to reproduce:**
	- Install Rental module
	- Check gantt view in Rental > Schedule

**Current behavior before PR:**
We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted with this new behaviour.

So what is happening is that '_read_group_product_ids'
https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule.py#L20
is not called as there is a limit so https://github.com/odoo/enterprise/blob/17.0/web_gantt/models/models.py#L76 This computes to be False so https://github.com/odoo/odoo/blob/17.0/odoo/models.py#L2745:L2754 '_read_group_fill_results' will not get called to call '_read_group_product_ids'

**Desired behavior after PR is merged:**
After override 'get_gantt_data' we are now checking if all products count is more than the limit we just return the products that already have orders.

**Other solution:**
We might just remove the group_limit https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule_views.xml#L54 and just go with the '_read_group_product_ids'.

opw-3959031

Versions
--------
- 15.0+

Steps
-----
1. Sync with Google Calendar;
2. create a recurrent all day event in google calendar;
3. make sure it shows as "busy";
4. make an appointment via website on that day.

Issue
-----
You are allowed to make an appointment on slots that overlap the synced event.

Cause
-----
Recurrent day events synced via Google Calendar have their start & end date equal to each other, so the event's "end date" could be 24 hours before the actual end.

Commit ad4219876cee4f4b996a7cc72fd176b51be3a063 added an the `_slot_availability_prepare_values_meetings` method, optimized to not include conditions on `start_date` and `allday`. Instead, it filters event by date ranges.

In our scenario, an `allday` event with start & end dates set to something like `2022-02-14 00:00:00`, may get excluded from the search when this is also the value of the starting point of the search, due to `stop` not being strictly greater than the starting point.

Solution
--------
Do an inclusive range search instead of an exclusive one.

opw-3793009

Forward-Port-Of: odoo/enterprise#65023
Forward-Port-Of: odoo/enterprise#63761