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

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

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

Steps to reproduce:
1. Create two expenses for different employees (e.g., Expense A for Employee 1, Expense B for Employee 2).
2. Upload different attachments to each (e.g., 2 files for A, 3 files for B).
3. Select both expenses and use the 'Post' action to open the posting wizard.
4. Click 'Post' in the wizard.
5. Check the generated journal entries (vendor bills).
Result: Both vendor bills contain all 5 attachments (copies of A's files and copies of B's files).

Issue:
In `_prepare_bills_vals`, `self.attachment_ids` is collected before the
`grouped('employee_id')` loop (see: https://github.com/odoo/odoo/blob/6b7fff433335edf7459f7a6eb5c274c0f4d5d1df/addons/hr_expense/models/hr_expense.py#L1572-L1578).
Since `self` refers to the full expense recordset, `self.attachment_ids` returns
the union of all attachments across every expense. This combined list is then
assigned to every bill created inside the loop, causing attachments from one
employee's expenses to leak into another employee's journal entry.

opw-6056590

Forward-Port-Of: odoo/odoo#258784
Forward-Port-Of: odoo/odoo#256031

This commit:
https://github.com/odoo/odoo/commit/ad6351c

Wrapped the invoice line table in a `<div class="table-responsive-sm">` to enable horizontal scrolling on mobile. However, Bootstrap's `table-responsive-sm` sets `overflow-x:auto` on the container, which prevents wkhtmltopdf from repeating the `<thead>` across page breaks. On pages 2+, the header row (Description, Quantity, Unit Price, Amount) renders on top of the first data row instead of appearing as a separate repeated header.

Made the `table-responsive-sm` class conditional on `report_type == 'html'` so it only applies in HTML views where mobile scrolling is needed, and is omitted for PDF rendering. This follows the same pattern already used throughout the invoice template for other responsive classes.

Steps to reproduce:
1. Create an invoice with enough lines to span multiple pages
2. Print the invoice as PDF

=> On page 2+, the table header overlaps with the first data row, making both unreadable.

Ticket [link](https://www.odoo.com/odoo/action-4043/5867972)
opw-5867972

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

This commit fixes an unexpected access rights error when users
try to add simple dynamic fields allowed by mail_allowed_qweb_expressions
to mass_mailing emails.

During the convert_inline process, the <t t-out=""/> placeholder element
has its style inlined, and attributed to its style attribute.
This style attribute was not filtered out during the safety
check process, resulting in the templating engine believing a disallowed
directive was used.

Steps to reproduce:
- On a fresh 18.0+ install with demo data, login as Marc Demo
- Access the Email Marketing app
- Create a new mailing campaign
- Set sending to Newsletter or Mailing Contact
- Type /field to add a dynamic value
- Set it to Name
- Save the mailing
- An access rights error is raised due to the user not having
    group_mail_template_editor permissions and the dynamic placeholder
    node having a style attribute

Fix:
T nodes are no longer granted a style attribute during style inlining.

Forward-Port-Of: odoo/odoo#257992
Forward-Port-Of: odoo/odoo#226111

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

Steps to reproduce:
--------------------------
1. Install Project and create a portal user.
2. Create a project and a task with tags added to it.
3. Share the project with the portal user (Edit access).
4. Log in as the portal user and open the task.
5. Click on the 'Tags' field and select 'Search More'

Issue:
----------
A traceback occurs:
```ValueError: Invalid field project.tags.display_in_project in condition ('display_in_project', '=', True)```

Cause:
----------
The [ProjectTaskRelationalModel](https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_relational_model.js#L4-L7) calls `_processSearchDomain.`
This method automatically appends a domain when 'showSubtasks' is not enabled.
https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_model_mixin.js#L5-L12

When clicking 'Search More' on the 'Tags' field, the same domain is
applied to the **project.tags** model. However, since **project.tags**
does not have the `display_in_project` field, the ORM raises a ValueError.

In portal, only `project.webclient` assets are loaded, causing
ProjectTaskRelationalModel to be used for all relational fields.
In contrast, internal users use the standard RelationalModel, so the
issue does not occur.

Solution:
-------------
Restrict the domain modification in _processSearchDomain to apply only
when the current model is `project.task` and `report.project.task.user`.


opw-5930427



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

Forward-Port-Of: odoo/odoo#258656
Forward-Port-Of: odoo/odoo#249282

[FIX] html_builder, *: hide the size of CORS-protected images
*: html_editor

Steps to reproduce:
- Add an image on the website.
- Replace it with a CORS-protected image.

-> The image options display a size, but it is incorrect.

The problem is that it is not the real size of the image but the size of
a default image (due to it, if you replace the image by another CORS
protected one, you'll see that the size of the image remains the same).
Indeed, the size of an image (in bytes) is computed from the length of
the raw b64 content of the image, on which a ratio of 3/4 is applied.
Because the image is CORS protected, we can not retrieve the raw b64 of
the image so the image size should not be displayed.
This commit hides the size of CORS protected image as it is impossible
to retrieve.

Note: example of a CORS protected image:
https://tinyjpg.com/images/social/website.jpg 

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: correctly determine image mimetype
*: html_editor

The goal of this commit is to improve the way the mimetype of an image
is determined if the information is not in the DOM. Before this commit,
the system relied on the extension of the image source to determine its
mimetype. This is not really robust and it is easily trickable. For
example, in `html_editor`, if an image in a html field comes from an
attachment, its `src` attribute will end by the attachment name. If a
user changes the attachment name extension, the next time the image is
added on the DOM, the extension is changed but the mimetype of the image
is unchanged.
To solve the problem, the mimetype of the image is determined thanks to
the headers of the http request to the `src` of the image. That way, the
information comes from the server hosting the image.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, website: enable the quality change on shaped img

This commit improves [this one] by adding a test (this commit was
created before [this one] was merged). It also improves it; the
`mimetypeBeforeConversion` is either retrieved from the dataset or from
a `loadImageInfo` if the information is not on the dataset.

[this one]: https://github.com/odoo/odoo/commit/738d5fb5ae2154e1f6993817fab5471d2d4384fa

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: hide shape option for CORS-protected images
*: website

Steps to reproduce the problem:
- Add an image on the page.
- Replace the image by a CORS protected one.
- Try to apply a shape on the image.

-> Traceback

The goal of this commit is to hide the "Shape" option if the "original
image" of an image is not retrievable. Indeed, in this case, the option
will fail to apply correctly.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: avoid displaying options that are not compatible
*: html_editor, website

Few options like filter, quality, format and cropping rely on canvas to
work. The problem is that it does not work correctly for mimetypes like
`svg` or `gif`. Indeed, if an image modification is done on such images,
it will automatically be transformed into a `png` by default. To avoid
it, this commit hides the options that rely on a canvas manipulation
when clicking on a `svg` or `gif` image. The process image function has
also been adapted to not try to transform an image if its mimetype is
not compatible with a canvas transformation. Instead, those images are
directly transformed into `b64` images without any transformation.
Thanks to it, a shape can be applied on a `svg` or a `gif`.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: apply shape on replaced svg and gif images
*: website

Steps to reproduce the problem:
- Add a "Text-Image" snippet on the page and add a shape on the image.
- Replace the image by a svg or a gif.

-> A shape is displayed on the image options but the shape is not
applied on the image.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: avoid copying options on new incompatible images
*: html_editor, website

Steps to reproduce:
- Add an image on the website.
- Add a shape on the image.
- Replace the image by a CORS-protected one.

-> The image still has the shape data attributes on its HTML element
while it should not as it does not have the prerequisites to have a
shape (it does not have an original source). The same problem exists
with the hover effect.

This commit moves the logic that transfers the shape and hover effect on
replaced images from `html_editor` to the responsible plugins in
`html_builder` and `website`. It also adds a check to verify that the
replaced image is eligible to have a particular option before
transferring its data information.

task-5405262

Forward-Port-Of: odoo/odoo#258798
Forward-Port-Of: odoo/odoo#251703

__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#258589
Forward-Port-Of: odoo/odoo#254871

# How to reproduce
- Go to the website editor
- Add a Masonry block
- Add a Form inner block in the Masonry block
- Select any fields of the form
- Set it's visibility to Hidden
- Save

# The problem
The field is still visible.

# Cause
When a field has its visibility set to hidden, it is applied the
`.s_website_form_field_hidden` CSS class which applies `display: none`.

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_website_form/001.scss#L26-L28

But that CSS rule is overriden by the masonry's
`.s_masonry_block[data-vcss='001'] .row > div` CSS class.

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_masonry_block/001.scss#L1-L3

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/scss/website.scss#L3246

# Proposed solution
We set `display: none` with `!important` to prevent it from being overidden.
We also need to add `!important` to its edit mode
counter-part so that the field is still visible in that mode.

opw-6038955

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

Forward-Port-Of: odoo/odoo#256100

[FIX] purchase: set the correct price in alternative PO
Steps to reproduce the bug:
- Enable "Purchase Alternatives" in settings
- Go to Accounting > Configuration > Taxes:
    - Configure a 15% purchase tax:
    - Advanced Options tab:
    - Included in Price: enabled

- Create a storable product "P1":
    - Tax: 15%
    - In the Purchase tab, add vendors:
        - "Azure Interior": price = $10, min qty = 1
        - "Deco Addict": price = $15, min qty = 1

- Create a purchase order for "Azure Interior":
    - Order 100 units → total price is automatically computed as $1000
- Create an alternative purchase order:
    - Vendor: "Deco Addict"
    - Copy products: enabled

Problem:
The price is $1360, instead of $1500

When the alternative purchase order is created and the product is set
on the purchase order line, the required onchange methods are not
triggered:
https://github.com/odoo/odoo/blob/ad253ef4c2cb06536b99bb919a3e01ed980d2e96/addons/purchase/models/purchase.py#L1169

As a result, both the unit price and the taxes are missing on the
purchase order line. When `_compute_price_unit_and_date_planned_and_name`
is triggered, it attempts to compute the `price_unit`.

https://github.com/odoo/odoo/blob/fb24ad03fc47a303fa8719c0795e1afa9a7eb821/addons/purchase/models/purchase_order_line.py#L345-L346

At this point, it checks whether the purchase order has a vendor.
Since "Deco Addict" is set, it calls `_fix_tax_included_price_company`
using:
- the supplier price ($15)
- the supplier tax (15%)

However, since no taxes are yet set on the purchase order line,
`_fix_tax_included_price_company` incorrectly assumes the price is
tax-included and converts it to a tax-excluded price
(~13.04 instead of 15).

https://github.com/odoo/odoo/blob/7076b4f4d0d933d93b24e8e4c7cf21ef0b0008e5/addons/account/models/account_tax.py#L571-L573

Then, a 15% tax is applied on top of this incorrect base price, leading
to the wrong total.

opw-6047004

Forward-Port-Of: odoo/odoo#258154