Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element.

Steps to reproduce:
- Create a new email template.
- Insert a prompt by using the '/prompt' command.
- Type any prompt like 'Say Hello'.
- Save the email template.
- Click on preview.
- The prompt isn't evaluated.

The '_eval_ai_prompts' method creates a root element from the passed html content. When the passed content represents a single prompt container html element, the root will become that prompt container. The method will try to evaluate the prompt and replace the prompt container and then return the root. The returned root won't contain the evaluation of the prompt in this case because the whole root should be replaced by the evaluation given that there is no other elements.

To fix this, the html content will always be wrapped in a `<div>` to avoid the need for replacing the whole root element.

Forward-Port-Of: odoo/enterprise#111645
Forward-Port-Of: odoo/enterprise#110247

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Steps to reproduce:
1. Upload an XML invoice (e.g., UBL) containing an embedded PDF into the Documents app.
2. Select the document to open the preview panel.
3. The viewer opens but shows a grey/empty PDF viewer.

Context:
Commit odoo/odoo@5035107e introduced an updated PDF viewer.js. Subsequently, commit d3481a5e removed the `download=0` query parameter from the viewer route to prevent `new URL()` parsing errors on relative paths.

However, the backend specifically relies on the `download=0` flag to intercept the request, extract the Base64 data, and serve the raw PDF binary. Without this parameter, the backend serves the raw XML string directly to the PDF viewer, causing the parser to crash.

Fix:
Restore the `download=0` parameter by using the core `url` utility to construct a safe, absolute URL before encoding it for the viewer. This satisfies the strict `new URL()` parsing in the updated PDF viewer while ensuring the backend correctly triggers the PDF extraction.

Task-6065246

Forward-Port-Of: odoo/enterprise#112007

BEFORE:
- Before this commit, when we disable the gst e-filing feature from the
  configuration and try to access the tax return view, we are getting blocked by
  the redirect warning, which suggests enabling the gst e-filing feature from
  the configuration.
- Which is not desirable, as there might be some returns that are not related to
  gst e-filing, which should be accessible by the user.

AFTER:
- After this commit, removed the RedirectWarning when accessing the tax return
  view with gst e-filing feature disabled. So now the user can access tax returns
  without enabling gst e-filing feature.
- At the time of setting the fiscal year(generating/refreshing returns
  automatically), the GSTR returns will not be created.
- And at the time of manual GSTR return creation, we are raising UserError to
  instruct the user about enabling the gst e-filing feature.

Related Com PR: https://github.com/odoo/odoo/pull/247216

Task-5486586

Forward-Port-Of: odoo/enterprise#113741
Forward-Port-Of: odoo/enterprise#105983

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Steps to reproduce:
1. Upload an XML invoice (e.g., UBL) containing an embedded PDF into the Documents app.
2. Select the document to open the preview panel.
3. The viewer opens but shows a grey/empty PDF viewer.

Context:
Commit odoo/odoo@5035107e introduced an updated PDF viewer.js. Subsequently, commit d3481a5e removed the `download=0` query parameter from the viewer route to prevent `new URL()` parsing errors on relative paths.

However, the backend specifically relies on the `download=0` flag to intercept the request, extract the Base64 data, and serve the raw PDF binary. Without this parameter, the backend serves the raw XML string directly to the PDF viewer, causing the parser to crash.

Fix:
Restore the `download=0` parameter by using the core `url` utility to construct a safe, absolute URL before encoding it for the viewer. This satisfies the strict `new URL()` parsing in the updated PDF viewer while ensuring the backend correctly triggers the PDF extraction.

Task-6065246

BEFORE:
- Before this commit, when we disable the gst e-filing feature from the
  configuration and try to access the tax return view, we are getting blocked by
  the redirect warning, which suggests enabling the gst e-filing feature from
  the configuration.
- Which is not desirable, as there might be some returns that are not related to
  gst e-filing, which should be accessible by the user.

AFTER:
- After this commit, removed the RedirectWarning when accessing the tax return
  view with gst e-filing feature disabled. So now the user can access tax returns
  without enabling gst e-filing feature.
- At the time of setting the fiscal year(generating/refreshing returns
  automatically), the GSTR returns will not be created.
- And at the time of manual GSTR return creation, we are raising UserError to
  instruct the user about enabling the gst e-filing feature.

Related Com PR: https://github.com/odoo/odoo/pull/247216

Task-5486586

Forward-Port-Of: odoo/enterprise#105983

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element.

Steps to reproduce:
- Create a new email template.
- Insert a prompt by using the '/prompt' command.
- Type any prompt like 'Say Hello'.
- Save the email template.
- Click on preview.
- The prompt isn't evaluated.

The '_eval_ai_prompts' method creates a root element from the passed html content. When the passed content represents a single prompt container html element, the root will become that prompt container. The method will try to evaluate the prompt and replace the prompt container and then return the root. The returned root won't contain the evaluation of the prompt in this case because the whole root should be replaced by the evaluation given that there is no other elements.

To fix this, the html content will always be wrapped in a `<div>` to avoid the need for replacing the whole root element.

Forward-Port-Of: odoo/enterprise#111645
Forward-Port-Of: odoo/enterprise#110247

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

Forward-Port-Of: odoo/odoo#257776

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#257873

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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

Forward-Port-Of: odoo/odoo#257942
Forward-Port-Of: odoo/odoo#254871

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

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

Forward-Port-Of: odoo/odoo#258851
Forward-Port-Of: odoo/odoo#257012

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Forward-Port-Of: odoo/odoo#258234

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#257710
Forward-Port-Of: odoo/odoo#250160

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Since [1] (and its follow-up commits), the softphone became the "UI active element" once it opens. This was required to solve multiple keyboard navigation issues that occurred while being on the app switcher with the softphone opened. It also simply improved navigation any time the softphone is used, allowing it to close on ESC, etc. This is also consistent with what is being done at [2] where the softphone will get closer to modal behavior.

However, it came with a bug: dropdown inside and outside the softphone were not closed anymore if clicking outside the softphone. E.g.:
- Open the user dropdown menu
- Click outside => it closes
- Open the softphone
- Open the user dropdown menu
- Click outside => It does not close anymore

This commit adds a test about it. The fix lies in the dropdown closing logic in the community counter-part of this PR.

[1]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be
[2]: https://github.com/odoo/enterprise/pull/111337

task-6055692

Forward-Port-Of: odoo/enterprise#111516

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element.

Steps to reproduce:
- Create a new email template.
- Insert a prompt by using the '/prompt' command.
- Type any prompt like 'Say Hello'.
- Save the email template.
- Click on preview.
- The prompt isn't evaluated.

The '_eval_ai_prompts' method creates a root element from the passed html content. When the passed content represents a single prompt container html element, the root will become that prompt container. The method will try to evaluate the prompt and replace the prompt container and then return the root. The returned root won't contain the evaluation of the prompt in this case because the whole root should be replaced by the evaluation given that there is no other elements.

To fix this, the html content will always be wrapped in a `<div>` to avoid the need for replacing the whole root element.

Forward-Port-Of: odoo/enterprise#111645
Forward-Port-Of: odoo/enterprise#110247

**Problem:**
Currently, when 'Hide Composition' is enabled on a section containing at least one product, while the order have subscription product, the recurring lines within that section are still visible in the portal's 'preview' view, whereas they are correctly hidden in the PDF report.

**Expected behavior:**
As observed in pdf format, in preview, the hidden section should hide the components and only view the name of the section.

**Steps to reproduce:**
- Create quotation with One Goods type product
- Add section with Hide composition
- Add service type product in the section
- Preview it and section products will be hidden
- Confirm the quotation and now preview the sales order
- Now the hidden section products will be visible

**Solution:**
- We need to separate the logic of displaying lines and invoiceable lines (since _get_invoiceable_lines doesn't necessarily return the sections/subsections)
- The filtering in sale subscription module wasn't considering the `collapse_composition` boolean field, which why hidden sections content were displayed.
- We need to hide any product with a parent (section or subsection) collapsed, hide any subsection with a parent section collapsed.

opw-5868148

Forward-Port-Of: odoo/enterprise#106287

Steps to reproduce:
1. Upload an XML invoice (e.g., UBL) containing an embedded PDF into the Documents app.
2. Select the document to open the preview panel.
3. The viewer opens but shows a grey/empty PDF viewer.

Context:
Commit odoo/odoo@5035107e introduced an updated PDF viewer.js. Subsequently, commit d3481a5e removed the `download=0` query parameter from the viewer route to prevent `new URL()` parsing errors on relative paths.

However, the backend specifically relies on the `download=0` flag to intercept the request, extract the Base64 data, and serve the raw PDF binary. Without this parameter, the backend serves the raw XML string directly to the PDF viewer, causing the parser to crash.

Fix:
Restore the `download=0` parameter by using the core `url` utility to construct a safe, absolute URL before encoding it for the viewer. This satisfies the strict `new URL()` parsing in the updated PDF viewer while ensuring the backend correctly triggers the PDF extraction.

Task-6065246

Forward-Port-Of: odoo/enterprise#112007

**Problem:**
Currently, when 'Hide Composition' is enabled on a section containing at least one product, while the order have subscription product, the recurring lines within that section are still visible in the portal's 'preview' view, whereas they are correctly hidden in the PDF report.

**Expected behavior:**
As observed in pdf format, in preview, the hidden section should hide the components and only view the name of the section.

**Steps to reproduce:**
- Create quotation with One Goods type product
- Add section with Hide composition
- Add service type product in the section
- Preview it and section products will be hidden
- Confirm the quotation and now preview the sales order
- Now the hidden section products will be visible

**Solution:**
- We need to separate the logic of displaying lines and invoiceable lines (since _get_invoiceable_lines doesn't necessarily return the sections/subsections)
- The filtering in sale subscription module wasn't considering the `collapse_composition` boolean field, which why hidden sections content were displayed.
- We need to hide any product with a parent (section or subsection) collapsed, hide any subsection with a parent section collapsed.

opw-5868148

Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element.

Steps to reproduce:
- Create a new email template.
- Insert a prompt by using the '/prompt' command.
- Type any prompt like 'Say Hello'.
- Save the email template.
- Click on preview.
- The prompt isn't evaluated.

The '_eval_ai_prompts' method creates a root element from the passed html content. When the passed content represents a single prompt container html element, the root will become that prompt container. The method will try to evaluate the prompt and replace the prompt container and then return the root. The returned root won't contain the evaluation of the prompt in this case because the whole root should be replaced by the evaluation given that there is no other elements.

To fix this, the html content will always be wrapped in a `<div>` to avoid the need for replacing the whole root element.

Forward-Port-Of: odoo/enterprise#110247

Currently when creating a subscription for a service product, if the minimal period is a multiple of the time unit: eg two week, three months, etc... The discount amount ends up wrongly computed.

The reason for that is that discounts for services are computed by taking the price of the minimal period and then comparing it to other prices, however that base price is not scaled down to single units of time like the compared prices are. https://github.com/odoo/enterprise/blob/9eac36e4d981fd6062702e7119c664ac7951d613/website_sale_subscription/models/product_template.py#L130-L135 https://github.com/odoo/enterprise/blob/9eac36e4d981fd6062702e7119c664ac7951d613/website_sale_subscription/models/product_template.py#L204-L205

**Steps to reproduce:**

- Create a service subscription product
- In Recurring Prices, select or create a recurring plan that is a multiple of a unit of time, ex 2 Months
- Create two entries, one with the created plan and one with a plan that spans a longer period, ex 1 Year
- Set the prices, ex 100 and 600
- Click 'Go to Website' and you'll observe that both are 50% off

opw-6107509

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.

Traceback:
```py
  File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
    if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```

Solution:
We first perform the existence check and then compare the types.

[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d

sentry-7376866293

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404

Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.

Steps to Reproduce on Runbot:

1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location. 
5. Create a new route.
6. Create new rules on this new route with the following configurations:
   1. Rule 1
      1. Action: Pull
      2. Source location: WH/Stock
      3. Destination location: Partners/Customers
      4. Operation type: The new pick operation type
   2. Rule 2
      1. Action: Push
      2. Source location: New pack location
      3. Destination location: WH/Output
      4. Operation type: Pack
   3. Rule 3
      1. Action: Push
      2. Source location: WH/Output
      3. Destination location: Partners/Customers
      4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it. 


opw-6026918

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834