**Problem:**
When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF.

**Steps to reproduce:**
1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر )
2. Create an invoice with that product
3. Print the invoice PDF in English
4. Observe the brackets are misplaced in the description column

**Current behavior:**
Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text.

**Expected behavior:**
Parentheses correctly wrap the enclosed Arabic text.

**Cause of the issue:**
Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them.

**Fix:**
Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets.

opw-5884712

Forward-Port-Of: odoo/odoo#259039
Forward-Port-Of: odoo/odoo#251190

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button 
=> Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

Forward-Port-Of: odoo/odoo#258938

Before this commit, when message actions are displayed from right-click, triggering a right-click on the message again would keep displaying the message actions.

Right-click on message to show the actions is useful in many cases, but sometimes the user wants to trigger the browser context menu.

Currently browser context menu is shown on links and when there are some text selection, but there might be some other potential cases where seeing the browser context menu is desirable. In practice users could trigger it through SHIFT + right-click but they are not necessarily aware of it.

This commit let double right-click on same message open the browser context menu, so that if users really want to have the browser context menu then doing it twice will show it.

Before
![before](https://github.com/user-attachments/assets/23c6ba1d-a8a1-4999-9ac0-308282f2f617)

After
![after](https://github.com/user-attachments/assets/fae4ff2e-13bf-4eb6-8f0d-c2d4858fd470)

Forward-Port-Of: odoo/odoo#258699

In German location with Fiskaly setup.
POS users hit an AccessError on read when closing the session from the frontend,
then had to finish closing in the backend with admin (base.group_erp_manager) rights.

Steps to reproduce:
-------------------
* Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly
* Use a user with POS rights only (no Access Rights)
* Open POS, sell, then close the session from the POS UI

> Observation:
A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read).

Why the fix:
------------
The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is
already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials.
Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required;
this change fixes unnecessary reads of protected fields in the tax helper,
not the security model of the credentials themselves.

opw-6074960

Forward-Port-Of: odoo/enterprise#113714
Forward-Port-Of: odoo/enterprise#112618

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

Forward-Port-Of: odoo/enterprise#113966