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

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

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

### **Overview**
The employee form view has become increasingly cluttered with benefit-related fields that are often irrelevant to specific company configurations. This PR introduces a dynamic mechanism to "lighten" the UI by linking views directly to specific benefits.

Key Change: Benefit-related views and salary rules are now conditional. If a benefit is deactivated, its corresponding fields and view elements will no longer appear on the employee form.

### **Technical Changes**
Several models and calculations have been moved:

`hr.contract.salary.benefit`: Moved from hr_contract_salary to hr_payroll.

Yearly Cost Calculation: Logic has been migrated to hr_payroll.

Payroll Properties : Activation is now based on the active field of the salary rule 

Signature & Configurator: The logic specifically tied to the salary configurator and document signing remains in hr_contract_salary.

### **2. Dynamic View Management**
view_ids Field: Added to hr.contract.salary.benefit.

Benefit-specific UI components are now defined in separate views, which are activated/deactivated based on the benefit's active field.

### 3. Module Consolidation & Cleanup
hr_contract_salary_payroll: Merged into hr_contract_salary to reduce module overhead.

hr_contract_salary_holidays: Removed. This module contained significant dead code and is no longer required.

Data Migration: Localized benefit data has been moved from l10n_be_hr_contract_salary to l10n_be_hr_payroll

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

**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`.
* Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.

task: 5408192

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

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