Problem:
In a survey that allows roaming, when a user skips a question with conditional questions triggered by its answers, submits the survey and then answers the question, the triggered questions are not displayed next. The survey either gets submitted or displays the next skipped mandatory question.

Steps to reproduce:
1. Create a survey with roaming allowed and at least 2 questions.
2. Make the first question mandatory and add an answer that triggers the display of the second question.
3. Start the survey, skip the first question and submit the survey.
4. After skipping the first question and trying to submit, answer the first question with the answer that should trigger the second question.
5. Notice how the second question is not displayed and the survey is submitted or the next skipped mandatory question is displayed instead.

Cause:
When looking for the next question to display, the survey only checks for skipped mandatory questions. It doesn't check if there are any triggered questions that should be displayed before the next skipped mandatory question.

opw-5917891

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.

opw-6074833

**Steps to reproduce:**
* Install the *Purchase* module
* Create a product and set an *Reference* and
  Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*.
* Create a Purchase Order with the same vendor set as on the product.
* Add the configured product to the *Purchase Order Lines*.
* Add the same product again on a second line and save the order.
* Activate debug mode
* Go to the view:Form and add a limit to have only 1 POL per page
* Return to your PO
* Go to the second page

**Observed behavior:**
* The *product display name* in the purchase order lines is different on
  the second page compared to the first page.

**Cause:**
* On the first page, purchase order lines are fetched via a web_read on the
purchase order.
* On subsequent pages, lines are fetched via a web_read directly on the
purchase order lines.
* The client requests both name and product_id.display_name.
product field context includes partner_id, causing
product_id.display_name to be computed as the vendor name.
* As both values resolve to the vendor name, the original product
name is lost, leading to inconsistent display across pages.

**Note:**

A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36
* but its consequence it breaks the search using the vendor code/name in POL.

* That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d

**Fix:**
* This ensures the product name is propagated correctly in the form
view while preserving search by vendor code or name.

---

opw-5170924

Description of the issue/feature this PR addresses:

During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet.

But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine.

Current behavior before PR:

Logs may contain warnings such as:

- Patching res.partner.ref with company_dependent=True
- Patching product.template.sale_ok with company_dependent=True
- Patching product.product.default_code with company_dependent=True

even though there is no actual issue (ok normal behavior)

The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine.

Desired behavior after PR is merged:

Keep the same mechanism, but lower the log level from WARNING to DEBUG.
This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG.
Having the production branches green.



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

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