****Behavior:****

**Current:**
When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view.
- If the selected timesheets come from only a single private project : an Access Error is raised
- If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised

The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error.

**Expected:**
Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell.

So now when printing or exporting a timesheet from a single private project, no Access Error is raised.

**Steps to reproduce:**
- Create 2 different projects
- Create a task in each
- Assign it to another user (Make sure the other user only has user access to timesheets and projects)
- Set each project's visibility setting to private
- Log in with the other user
- Go to Timesheets --> List View

Single projects:
- Select one or multiple timesheet entries from one of the private projects
- Select Print -> Timesheets
- You should see an Access Error 

Multiple projects:
- Select one or multiple timesheet entries from a combination of both private projects
- Select Print -> Timesheets
- You should not have any Errors

opw-5127526

Changing the timezone on the appointment page triggers a refresh of the available slots. In that flow, the controller computes the maximum possible capacity using `filter_resources`. When no specific resource is selected, `filter_resources` remained falsy and was passed down to `_get_max_capacity_possible`, which then attempted to call a recordset method on a boolean value.

Steps to reproduce:
1. Appointments > Dental Care
2. Select a person
3. Change the timezone
4. Observe a traceback

Current behavior:
`AttributeError: 'bool' object has no attribute '_get_filtered_possible_capacity_combinations'` because `filter_resources` is falsy (boolean) instead of a recordset.

this fix:
When `filter_resources` is falsy, compute it with
`self._get_possible_resources(appointment_type, filter_resource_ids)` before calling `_get_max_capacity_possible(...)`. This guarantees a proper recordset is used and avoids calling recordset methods on a boolean. If a resource is explicitly selected, behavior is unchanged. If not, we now use the same "possible resources" logic already employed by the rest of the route.

opw-5152162