**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 produce:
---
- Install `Accounting` module.
- Create a new customer.
- From the gear icon, `grant Portal Access` to the customer.
- Create an invoice for this customer.
- Log in using the customer’s portal account.
- Navigate to `My Invoices`.

Issue:
---
```
You are not allowed to access 'Payment' (account.payment) records.

```

Root cause:
---
- After the [commit], the system attempts to compute the next payment values for display in the portal.
- This computation is triggered via `_get_invoice_portal_extra_values()`, which calls `_get_invoice_next_payment_values()`.
- During this process, the method iterates over `reconciled_payment_ids`. Accessing this field triggers its computation (`_compute_reconciled_payment_ids`), which depends on `matched_payment_ids`.
- Both `reconciled_payment_ids` and `matched_payment_ids` are relational fields pointing to `account.payment` records.
- Since portal users do not have read access to the `account.payment` model, attempting to access these fields results in an AccessError

[commit]: https://github.com/odoo/odoo/commit/b76836680540eb7687021f48b3532e8a495e771a

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

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

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#258207
Forward-Port-Of: odoo/odoo#255780

This forward port merges [PR1](https://github.com/odoo/odoo/pull/255043) (original PR from this forward port) 
and forward port of [PR2](https://github.com/odoo/odoo/pull/256383) which is improving the fix.

**Problems:**
1) cogs don't adapt to partially consigned quantities
2) no cogs at all if product partially delivered

**Steps to reproduce:**
Problem 1)
- enable 'consignment' setting
- create a tracked product with perpetual category
(bug happens with avco, fifo and standard price category)
- set a cost of 10 
- add a quantity of 1 without owner and a quantity of 
1 with an owner
- create a sale order for a quantity of 2 of your produce
- confirm, validate picking and confirm invoice

-> the cogs is 20
-> the cogs should be 10 because the consigned 
quantity shouldn't be taken into account in the cogs

Problem 2) 
- set the warehouse as 2 steps delivery
- create a tracked product avco perpetual
- set a cost of 10$ and a positive quantity
- create and confirm a SO for 1 quantity
- validate only the first picking
- create and confirm the invoice

-> there is no cogs lines in the invoice
-> there should be cogs line for a cost of 10$

**Cause of the issue:**
Problem 1) 
to compute the cogs line amount, we multiply the quantity 
of the line (2 in our case) by the price unit of the cogs.
To compute the price_unit we call _get_cogs_value()
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move.py#L122-L123 
In our case the price_unit (so the 'price per cogs unit') should 
be 5 because we have 2 units, 1 valued at 10 and 1 valued 
at 0 (the consigned one).
But the value returned by _get_cogs_value() is 10.

The reason for this is that _get_cogs_value uses the return 
value of _get_cogs_price_unit() because the delivery is validated.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move_line.py#L67-L68

Inside get_cogs_price_unit, we use _get_valued_qty() to 
sum the valued quantity of each move. 
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251
But inside get_valued_qty() for our second move, when 
calling get_out_move_lines(), no lines will be returned 
because should_exclude_for_valuation() will return True 
as the owner of the line is not the user.
So total qty will be 1.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L529

If the product is fifo, we return the total value of the moves (10 + 0) 
divided by total quantity (1). 
If the product is standard or avco we return the standard price. 
In both cases the return value is 10.
But in both cases it should be 5.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251-L255

Problem 2)
Inside _get_cogs_value(), because there is done moves, 
we use _get_cogs_price_unit()
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move_line.py#L67-L68
But because there is no valued quantity (because the done 
moves are internal), the return value will be 0.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253
So the cogs will have an amount of 0 and no line will be created
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L125-L126

**fix**
Prob 1) The first thing to change is to not use the standard price when 
some quantities are consigned. 
The other thing is to add the quantities that would have been 
used if they weren't consigned because in this case we need them 
in the computation. 
Indeed these quantities are included in the invoice line quantity. 
At the end we are multiplying the unit price by the invoice line quantity
which includes consigned quantity, so we need to take them into 
account also when computing the price per cogs quantity.

Prob 2) If there is no quantity to value (consigned + not consigned) 
we fallback on the standard price (just as if there is no move).
This solves the issue of partially delivered order because no moves
are valued moves in this use case.
If there is a quantity to value (and we're in a case where we want
the average move value), we use the average move value (which 
will be 0 if all the moves are consigned, so the consigned use case
is also ok)

opw-6030161
opw-6001694

Forward-Port-Of: odoo/odoo#256231
Forward-Port-Of: odoo/odoo#255043

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

### Steps to reproduce:

- Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`)
- Create + confirm a purchase order for 1 unit of the kit product at 60
- Validate the delivery

#### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10

There are two issues with purchased kit valuation addressed in this PR:

### Issue 1:

Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38

This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented  as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share:
https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48

### Fix of this issue:

We set the digits to `False` for stability reason as the columns have 
been initiallised as "numeric" values and needs to stay numeric:
https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650

Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end:
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76
https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227

In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`.

### Issue 2:

While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30

Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit).

### Fix of this issue:

We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore).

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

Forward-Port-Of: odoo/odoo#257411
Forward-Port-Of: odoo/odoo#252034

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 Ent PR: https://github.com/odoo/enterprise/pull/105983

Task-5486586

Forward-Port-Of: odoo/odoo#259029
Forward-Port-Of: odoo/odoo#247216

# 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

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

# 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

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops propagation of the composer `focusin` event so the Offcanvas focus trap does not steal focus from the composer.

Thread focus state can also depend on `focusin` bubbling from the composer to the thread component. Since that bubbling is now stopped, the shared thread focus state is tracked through the JS models instead:

- composer focus updates the related thread through `composer.thread`
- thread component focus updates the thread model directly.

This keeps the composer accessible while preserving thread focus behavior.

Related: https://github.com/odoo/enterprise/pull/113763
Task-5954657

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

Forward-Port-Of: odoo/odoo#258713
Forward-Port-Of: odoo/odoo#250294

## Purpose

When `_create_missing_folders()` runs on an archived project (e.g. a template project referenced by a service product's `project_template_id`), it creates a document folder that serves no purpose — archived/template projects are never accessed directly.

If that folder later gets trashed (manually or otherwise), SO confirmation fails with:

> UserError: You cannot duplicate document(s) in the Trash.

This happens because `documents_project`'s `copy()` override tries to duplicate the template's `documents_folder_id`, and `documents.document.copy()` rejects trashed documents. The entire SO confirmation transaction rolls back — no project is created.

## Specification

Filter out archived projects in `_create_missing_folders()` so folders are only created for active projects that will actually use them.

New projects created from a template still get their own folder: after `copy()` returns, the project gets written to (name, analytic account, etc.), and `write()` calls `_create_missing_folders()` on the **new active project**, creating a fresh folder under the company's default project folder.

## Technical

One-line change: `for project in self:` → `for project in self.filtered('active'):`

The fix is in `_create_missing_folders()` rather than `copy()` because:
- `copy()` already has a guard (`if old_project.documents_folder_id`) — it's `_create_missing_folders()` that keeps recreating the folder on archived templates
- Even if the folder is cleared or unarchived via migration, `_create_missing_folders()` recreates it on the next `write()` to the template project, restarting the cycle

opw-6071771

Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts.

Steps to reproduce:
- Create an early payment term.
- Create a Vendor Bill with EPD and post it.
- Register a payment for this bill (no outstanding account set on journal => no move created).
- Create a bank transaction fully paying the bill.
- Reconcile the transaction with the bill.

Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'.

Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically:
- The payment amount does not match the bill total due to the EPD.
- The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills.

This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment.

opw-5881976

Backport of https://github.com/odoo/odoo/commit/4d84b961cdabd283e1acef6b487b2648bc543a5a

Concurrent processing of emails with the same `Message-Id` can create duplicate records.

### Steps to reproduce

1. Configure multiple mail aliases (e.g., two helpdesk teams).
2. Send one email with both aliases as recipient.

The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions.

We expect one record per alias/team, but duplicates may be created.

### Cause

This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation.

Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions.

When two concurrent transactions process the same email:

1. Both enter `message_process` and take their snapshot.
2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing.
3. Both create records.

Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates.

### Fix

After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal.

opw-5116492

Forward-Port-Of: odoo/odoo#250027

**Steps to reproduce**

Install modules l10n_ar and l10n_latam_invoice_document.
Go to Accounting > Configuration > Journals and enable \"Lock Posted Entries with Hash\" on a Purchase journal that uses LATAM documents.
Create and post a vendor bill with a high document number (e.g., '00001-00009999').
Create another vendor bill with a lower document number (e.g., '00001-00000100') and try to post it.

**Issue**

Posting the second vendor bill fails with a UserError: \"This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it.\"

This happens because core Odoo hashing logic enforces a strict, continuous sequential numbering per journal and prefix.

The _get_chain_info method identifies moves to be secured by searching for entries with a sequence number strictly greater than the last hashed move in that chain:
https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4091-L4145

When a vendor bill is entered with a lower number than an already hashed one, it is excluded from the search, triggering the no_document warning:
https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4140

And the subsequent UserError in _get_chains_to_hash:
https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4180-L4184

Similarly, jumps in vendor numbering trigger a gap warning:
https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4130

Causing the error at:
https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4185-L4188

Since vendor bills are issued by third parties, we do not control their sequence, and forcing them into a single continuous chain is functionally incorrect.

opw-6076673

**Steps to reproduce**

Install modules l10n_ar and l10n_latam_invoice_document. Go to Accounting > Configuration > Journals and enable \"Lock Posted Entries with Hash\" on a Purchase journal that uses LATAM documents. Create and post a vendor bill with a high document number (e.g., '00001-00009999'). Create another vendor bill with a lower document number (e.g., '00001-00000100') and try to post it.

**Issue**

Posting the second vendor bill fails with a UserError: \"This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it.\"

This happens because core Odoo hashing logic enforces a strict, continuous sequential numbering per journal and prefix.

The _get_chain_info method identifies moves to be secured by searching for entries with a sequence number strictly greater than the last hashed move in that chain: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4091-L4145

When a vendor bill is entered with a lower number than an already hashed one, it is excluded from the search, triggering the no_document warning: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4140

And the subsequent UserError in _get_chains_to_hash: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4180-L4184

Similarly, jumps in vendor numbering trigger a gap warning: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4130

Causing the error at:
https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4185-L4188

Since vendor bills are issued by third parties, we do not control their sequence, and forcing them into a single continuous chain is functionally incorrect.

opw-6076673

**Description of the issue/feature this PR addresses:**

As soon as new Odoo versions are released, deploy iotbox-latest.zip could be unreliable and lead to crash the IoT integration. And right now, the upgrade wasn't even working as the new image name convention doesn't match the 'iotboxv' string.

**Current behavior before PR:**

- When we upgrade the Odoo server to which the IoTs are connected, they automatically get the new code for that server, so drivers are aligned to that version but the image is still the former one.
- If we hit update in the IoT to have a proper image up to date with the current server version:

<img width="584" height="172" alt="image" src="https://github.com/user-attachments/assets/0881a8cc-e69c-4fc1-be31-71de42abcae9" />


```
2026-03-31 06:55:33,007 892 ERROR ? odoo.http: Exception during request handling. 
Traceback (most recent call last):
  File "/home/pi/odoo/odoo/http.py", line 2592, in __call__
    response = request._serve_nodb()
               ^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/odoo/odoo/http.py", line 2064, in _serve_nodb
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/odoo/odoo/http.py", line 2297, in dispatch
    return endpoint(**self.request.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/odoo/addons/hw_posbox_homepage/controllers/homepage.py", line 208, in get_version_info
    'imageIsUpToDate': not bool(helpers.check_image()),
                                ^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 242, in check_image
    return {'major': version[0], 'minor': version[1]}
                                          ~~~~~~~^^^
IndexError: list index out of range
```

This code here can't simply match with the new naming convention, but we don't to break the compatibility anyway:

https://github.com/odoo/odoo/blob/38734e4bc7d841a30524a2bc17fc94c9a83b5aa0/addons/hw_drivers/tools/helpers.py#L225-L242


<img width="546" height="150" alt="image" src="https://github.com/user-attachments/assets/cb2c59f9-46ce-48c7-ad5a-cf5f1cbee062" />



**Desired behavior after PR is merged:**

We can update at least to last supported version for the connected server

(I've been conservative about the image version as the IoT code is so binded to the connected server code... Maybe a higher one is safe?)

cc @moduon MT-11428

opw-6084090

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

**Purpose:**
Since a stock.quant is a combination of the stock move lines of a product
and a location, it should be restricted by the product's company.

**Before this commit:**
In a multi-company environment. If a purchase order with product from
company 1 is being confirmed, received, and validated when company 2 is
being selected as the primary active company while company 1 is also
checked. It will create a stock.quant that is searchable for company 2.
However, it will raise an error when company 2 is trying to access it.

**After this commit:**
Even if the stock.quant is created when company 2 is the primary active
company, it will not be searchable for company 2 since the product's
company is company 1.

**Steps to Reproduce on Runbot:**

- Create a storable product exclusive to Company A
- Create & validate a receipt for that product in Company A.
- Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible.

opw-6082330

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