*: pos_online_payment_self_order

Before this commit:
===============
- When paying with a QR code, the screen kept showing the QR code even after
the payment was completed.
- Closing the QR popup manually and performing another action resulted in
a `Finalize order` error.
- This happened because the WebSocket handler flow were not updating
the order state properly.

After this commit:
===============
- Ensure the frontend refreshes payment status directly from the server
when the current order is updated.
- Remove unnecessary synchronization calls to prevent stale state.
- The order is now correctly marked as paid, and no finalize error occurs
after closing the QR popup.

Issue:
===============
- The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION`
was fetching the full `pos.order` unnecessarily, because the order state is
already updated by another WebSocket flow.
- `notify_synchronisation` in the self order flow was redundant, as updates
are already handled in the `pos_self_order` module’s `pos.order` file.

Task - 5107009

Forward-Port-Of: odoo/odoo#229847

**Steps to reproduce:**
- Set your database in a language with a "," as a decimal separator, such as French
- Make a purchase, chose a payment method
- Before paying, click any +10/20/50 button
- The price will be multiplied by 100, then add the desired amount

**Why the fix:**
There were two places where the decimal separator was causing issues.

First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers.

Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number.

We now convert the numbers and the strings using the correct decimal separator.

opw-5126224

Forward-Port-Of: odoo/odoo#229735

Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if local part detection was enabled in the alias settings. This was due to the fact that partner detection was changed in 18.2 and now looked for exact email to alias matches. Ban emails were passed to the _find_or_create_from_emails and then directly matched to the emails in the list of recipient emails. When a match was not found for emails that did not have an exact matching alias_full_name, we would then look for or create a partner for that email. This caused erroneous followers to be added.

Changing the functionality to also look for matching local parts in order to skip partner finding and creation reverts this functionality to how it previously worked where extra recipients with matching local parts when local part detection was enabled would not add those partners as followers.

opw-4896074

Forward-Port-Of: odoo/odoo#230004
Forward-Port-Of: odoo/odoo#216737

Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product.

> Setup of the Loyalty Program (Discount & Loyalty):
Program Type : Loyalty Card
Rule : minimum 5 items => 10 Loyalty Points per $
Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points

Steps to reproduce:
-------------------
* Open the pos Shop
* Select a customer with loyalty points
* Add a Simple Pen
* Click on * Reward > Free Product - Loyalty Program

> Observation:
Customer shouldn't 'win' points here
New Total is mathematically correct but not logic

Why the fix:
------------
We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points.

opw-4914774

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

Forward-Port-Of: odoo/odoo#231056
Forward-Port-Of: odoo/odoo#221570

### Issue:
The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option

### Steps to reproduce:
- Accounting > Configuration > Accounting Reports > General Ledger
- Change the Load more limit in the options to a small number, i.e. 4
- Open the General Ledger and unfold an account with more than 10 lines
- There is no Initial Balance line, it appears when clicking "Load more"

### Cause:
The General Ledger query have this line `ORDER BY 2, move_name, 1`. Here 2 refers to the date and 1to the `account_move_line.id`. But the initial balance line has these columns equal to `NULL` so this ORDER BY will place it at the end of the results. When the limit is smaller than the total number of lines, the initial balance is not fetched by the query.

**Additional issue**
The limit is incremented several times. In our case, we set the option at 4. It gets incremented [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_report.py#L7172) because the load more option is triggered, and also [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L239) for no apparent reason (it is not needed "for the Initial balance"). So the query is called with `limit=6`, six lines are retrieved when clicking on "Load more". Considering a scenario where there are 10 lines for the account (with the initial balance) and "Load more limit" set to 4:
- The first query gets the lines 1-6 but only 1-4 are displayed.
- Clicking "Load more", the offset is 4, the query gets the lines 5-10. 10 being the initial balance, it is put in first position by [this piece of code](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L79-L91). So the lines displayed are 10, 5, 6, 7
- Last click on "Load more", offset is 8, query gets 9 and 10, displays 10, 9. In the end, one line is not displayed, and the initial balance is displayed twice.

### Solution:
Add `NULLS FIRST` in `ORDER BY` to always have the Initial Balance as the first line returned by the query.

Also remove the unnecessary `limit+1`.

opw-5105652

**Issue:**
Multiple errors occur when processing payroll for "Fully Flexible" employees
and overlapping leave scenarios:

1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation
   when sick leave overlaps with public holiday

**Steps to Reproduce:**
1. Go to the **Employees** app and create a new employee.
   * Set the working hours to **empty (fully flexible)**.
2. Go to **Contracts** and create a new contract.
   * Set the **Work Entry Source** to *Attendance*.
   * Save and make the contract **Running**.
3. Go to **Time Off** → **New**, and create a sick time off for the employee.
   * Example: from **25th to 29th**.
   * Approve the time off.
4. Go to **Configuration** → **Public Holidays**, and create a new public holiday.
   * Example: **27th**, which overlaps with the sick time off.
   * Work Entry Type = **Paid Time Off**.
5. Go to **Payroll** → **Work Entries**.
   * A **traceback** occurs.

**Root Causes:**
- In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types.

**Fix:**
- Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types

This resolves payroll blocking issue for deployments using the
Fully Flexible employee feature, where employees may have
overlapping leave types and no assigned working calendar.

Test : [PR](https://github.com/odoo/enterprise/pull/93902)

opw-4979974

Forward-Port-Of: odoo/odoo#223448

****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

Forward-Port-Of: odoo/odoo#231188

**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

Forward-Port-Of: odoo/odoo#224714
Forward-Port-Of: odoo/odoo#222093

**[FIX] iap_extract: fix crash when clicking on another column of x2many**

When a x2many field is filled using the rectangular selection tool, a crash could occur when the component is busy filling the values for a field and the user clicks on another column.

This happened because the `getNewRecordValues` function was using the current value of `this.activeBoxType` to get the value for the new record. This is incorrect as `this.activeBoxType` can change when the user clicks on another column of the x2many.

---

**[FIX] iap_extract: fix line matching in manual correction component**

In the logic that handles the matching of selected boxes with existing lines, it was assumed that the existing lines were sorted from top to bottom, but that wasn't guaranteed.
When it's not sorted, the out-of-order existing lines couldn't be match to the selected boxes.

---

**[FIX] iap_extract: fix loss of focus when clicking on image viewer**

When the attachment showed by the viewer is an image and the selected field is a date, a click on the image (to start a rectangular selection or to click a box) would cause a loss of focus on the field which caused the boxes to disappear, making it unusable.

This happened because the date fields are displaying a calendar popup which listens on the `pointerdown` event to hide itself when the click occurs outside of it. This causes the loss of focus of the field which hides the boxes.

On top of this, we also need to prevent the propagation of the click event when it occurs on the box layers, as it also causes the loss of focus on x2many fields (there is a global click event listener that exits the edit mode when the click occurs on another element).

These issues weren't noticed before as they only occur on image attachments. On PDFs, the viewer is embedded in an iframe that prevents the `pointerdown` and `click` events to be visible to the main document.

---

**[FIX] iap_extract: fix rectangular selection on scrollable images**

The rectangular selection needs to be adjusted when the user scrolls while selecting boxes. This was already properly handled for PDFs, but not for image attachments.

**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

Forward-Port-Of: odoo/enterprise#93442
Forward-Port-Of: odoo/enterprise#91825

Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if local part detection was enabled in the alias settings. This was due to the fact that partner detection was changed in 18.2 and now looked for exact email to alias matches. Ban emails were passed to the _find_or_create_from_emails and then directly matched to the emails in the list of recipient emails. When a match was not found for emails that did not have an exact matching alias_full_name, we would then look for or create a partner for that email. This caused erroneous followers to be added.

Changing the functionality to also look for matching local parts in order to skip partner finding and creation reverts this functionality to how it previously worked where extra recipients with matching local parts when local part detection was enabled would not add those partners as followers.

opw-4896074

Forward-Port-Of: odoo/odoo#230004
Forward-Port-Of: odoo/odoo#216737

Steps to Reproduce:

- Create a list in the editor.
- Apply a text color to an item.
- Change the font type of the text inside the list (e.g., to H1–H6).
- Apply a gradient color to text inside a list item.
- Move the cursor outside the list by pressing Enter twice and start typing in the new container.

Current behavior before PR:

- When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent.
- This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`.

Desired behavior after PR is merged:

- All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element.
- Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice.

task-5039499

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

Forward-Port-Of: odoo/odoo#231390
Forward-Port-Of: odoo/odoo#224262

Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product.

> Setup of the Loyalty Program (Discount & Loyalty):
Program Type : Loyalty Card
Rule : minimum 5 items => 10 Loyalty Points per $
Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points

Steps to reproduce:
-------------------
* Open the pos Shop
* Select a customer with loyalty points
* Add a Simple Pen
* Click on * Reward > Free Product - Loyalty Program

> Observation:
Customer shouldn't 'win' points here
New Total is mathematically correct but not logic

Why the fix:
------------
We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points.

opw-4914774

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

Forward-Port-Of: odoo/odoo#231056
Forward-Port-Of: odoo/odoo#221570

*: pos_online_payment_self_order

Before this commit:
===============
- When paying with a QR code, the screen kept showing the QR code even after
the payment was completed.
- Closing the QR popup manually and performing another action resulted in
a `Finalize order` error.
- This happened because the WebSocket handler flow were not updating
the order state properly.

After this commit:
===============
- Ensure the frontend refreshes payment status directly from the server
when the current order is updated.
- Remove unnecessary synchronization calls to prevent stale state.
- The order is now correctly marked as paid, and no finalize error occurs
after closing the QR popup.

Issue:
===============
- The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION`
was fetching the full `pos.order` unnecessarily, because the order state is
already updated by another WebSocket flow.
- `notify_synchronisation` in the self order flow was redundant, as updates
are already handled in the `pos_self_order` module’s `pos.order` file.

Task - 5107009

Forward-Port-Of: odoo/odoo#231444
Forward-Port-Of: odoo/odoo#229847

****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

Forward-Port-Of: odoo/odoo#231188

Description of the issue/feature this PR addresses:
When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. 

<img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" />

Each reconnect attempt causes a log entry: 
```
2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 
2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Lead/Opportunity, Modern Open Space (crm.lead: 25)

Blame the following rules:
- Personal Leads

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. 

```



Current behavior before PR:
Reconnect loop.

Desired behavior after PR is merged:
Do not add channels without sufficient rights.


Related to: https://www.odoo.com/de_DE/my/tasks/5026412

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

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

**Issue:**

Single-day time off requests appear as multi-day events in the Calendar app when using certain tim>

**Cause:**

The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

**After fix:**

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

**Steps to Reproduce:**

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817

Forward-Port-Of: odoo/odoo#224298

Issue Before This Commit:
=======================
When a user updates `qty_producing` in a subcontracting MO, it creates new move lines with empty lots or serials, even though the required quantity is already available in existing `reserved move lines`. This requires the user to manually reassign lots/serials; otherwise, validating the picking raises a UserError of `missing Lot/Serial numbers`.

Steps to Reproduce:
=======================
- Install the `mrp_subcontracting` and `Purchase` module.
- Create product1 with Vendor1. Create product2 with lot tracking and set it `Resupply  Subcontractor on order` in Inventory.
- Create a BOM for product1, with product2 as a component (quantity 10) and subcontractor Vendor1.
- Create and confirm a purchase order for product1 (quantity 10) with Vendor1.
- Go to Resupply → Supply Product2, deliver 100 units of Product2 to Vendor1 using lot-01, then validate the picking.
- Go to the source PO → Receipt → Record Component. Observe that the move line is created with 100 units from lot-01
- Set qty_producing to 2 → the current component line updates to 20 quantity.
- Increase qty_producing by 1 → a new line is created with empty lot, even though the existing line already has 100 quantity of the same lot.

Cause of the issue:
=======================
When `qty_producing` is updated in the subcontracting MO wizard, the `_set_quantity_done_prepare_vals` method recalculates quantities based on the already modified move line quantity instead of referencing its original `reserved quantity`.This causes incorrect comparisons on subsequent updates, leading to the creation of new move lines with empty lots even when sufficient quantity already exists in the existing move line.

With This Commit:
=======================
`_set_quantity_done_prepare_vals` method now uses `ml._origin.quantity or ml.quantity`. ` _origin.quantity` ensures the reserved quantity of existing move lines is counted, while `ml.quantity` handles newly created lines without an origin. This prevents unnecessary move lines with empty lots when sufficient quantity already exists in existing reserved lines, eliminating manual reassignment and avoiding UserError on picking validation.

opw-5116273

Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.

When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.

This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```

From the above error, it's clear that Twitter only accepts specific MIME types.

This fix ensures the image has the correct MIME type so it can be uploaded without issues.

-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======

Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.

Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.

After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.

[1]  https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852


Task-4845385

****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