To reproduce:
=============
- Activate the "Attendances" app.
- Go to Attendances > Overview.
- Switch to list view.
- Group by Employee.

Issue:
======
The current domain fetches all employees matching the filter, regardless of whether they have attendance entries in the grouped model. https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/addons/hr_attendance/models/hr_attendance.py#L677

Fix:
====
Restrict the employee list to only those linked to a resource that
appears in the grouped data
https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/odoo/models.py#L2360-L2361
The problem is the behavior of gantt view will change it's behavior
So we have to applied only to the list.
there's something unique when we call it from the gantt which is
`gantt_start_date` property that we will use it so we can differentiate
between list and gantt view

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

### Problem:
Previously, clicking the "Review Contract & Sign" button triggered an RPC call that attempted to retrieve an access token by filtering on the employee role. If the contract did not include this role, the search returned no results, causing the redirection to fail with a 404 error due to the missing token.

### Description about the solution:
This commit updates the search domain to look for a record that matches the current user's email address instead. This ensures the correct access token is retrieved, regardless of role assignment.

https://github.com/user-attachments/assets/6c8cd892-2d85-4da7-b756-8b3cbf987b60

### Steps to reproduce the issue:
1) In the Sign application, create a PDF template with a new role and an HR responsible role.
2) In the Recruitment application, create a new contract template and select the PDF template created above.
3) In the contract role field, select the employee as the signatory for the line having newly created role.
4) For any job position, generate an offer for an applicant. 
5) Select the contract template created in step 2. 
6) Click the "Send By Email" button to send the contract. 
7) Open the URL and complete the personal application form. 
8) Click the "Review Contract & Sign" button.
9) The system attempts to open the sign document but ends up on a 404 error page.

https://drive.google.com/file/d/1aIWJvDlFtd40T5istjKhDvnWFae9wxIM/view

opw-4886526

## Issue:
When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check
The wizard is automatically opened but when you click on the Pass button, the wizard was closed without sending the print action

## Cause:
The action wasn't return by the wizard function 'action_generate_next_window()' making the only action to be a 'act_window_close'

## Note:
The state wasn't correctly set to done for all products when you validate pickings both with and without QCs in them at the same time, it should now be fix
Enabling Delivery Slip for the Receipts will make the SN to not be print even after disabling the option

## Steps to reproduce:
- Toggle the Lot/SN Labels option in the Hardware Tab for the Operation Type Receipts
- Create a Product tracked by Unique Serial Number
- Add a Quality Check for the Receipts operation
- Create a New Receipt for the product
- Mark as Done and Add the Serial Number
- Validate the receipt and Pass the check
- Before the fix, no document was downloaded

opw-4790427

**Issue:**
When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers

**Cause:**
The `partner_latitude` and `partner_longitude` fields were not reset for child contacts when the parent’s address changed

**Fix:**
We added a `partner_latitude` and `partner_longitude` reset when changing address in write
We added `partner_latitude` and `partner_longitude` in the _address_fields to update the value each time it can be required, like on address change or contact creation
The extension in the _address_fields is there to detect the changes on children synchronization, because it only replace the value that where present in vals for the fields in that list
In that way, it will detect more address changes and trigger the write for the children with the corresponding parent `partner_latitude` and `partner_longitude`
We also make sure that those extra _address_fields will not be displayed in the formatted address by removing them from `_formatting_address_fields`

**Limitations:**
One issue remains during import: the parent-child address synchronization is disabled on contact creation
This means children may be created with addresses different from the parent’s and have mismatch positions on Map
This can be corrected by updating or re-importing the parent to trigger synchronization

**Steps to reproduce:**
With Form:
- Add a parent contact company with a valid address
- Add a child contact related to company, with a valid address
- Open the Map View, both address must appear on Map
- Modify the parent address to remove street (make it invalid)
- Check that the child address match the parent one
- Check the Map View, before the fix the child should remain with a wrong position

With import:
Create an import file (an example is in on the ticket)
- Add a sheet for the Parent contact with an valid address
- Add a sheet to add the Child contact with a parent_Id, with a valid address
- Add a sheet to break the address on the parent, removing the street
- Open the contacts app
- Import the valid Parent and Child sheets (you need to select Related Company / External ID)
- Add a filter to get your created contacts
- Check the Map View (You should see both parent and child)
- Import the Break parent sheet
- Check that the child address match the parent one in the Form
- Check the Map View, before the fix the child should remain with a wrong position

A file can be found on the ticket with pre-made data

**Technical notes:**
The reset logic is duplicated from the `base_geolocalize` module, because this module is optional and may not be installed in all cases
Since `base_geolocalize` is not always present, its `write` override will not be triggered consistently

On the other hand, `web_map` is automatically installed with the Enterprise version of Odoo
Therefore, it is necessary to implement this fix in at least one of the two modules to ensure the behavior is active when Enterprise is used

We chose to keep the override in both `base_geolocalize` and `web_map` to cover both Community and Enterprise cases reliably

An alternative approach would be to move the reset logic directly into `res.partner` in the `base` module, making it always available regardless of installed addons and avoiding the duplication

opw-4842910

Forward-Port-Of: odoo/enterprise#90392