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

Example of steps:
- Install todo module
- Create a todo task (it will be created without project_id)
- Go to project -> my task
- You can see your previously created todo task (with project set as)
- This todo task is marked as Private (since no project)
- Refresh page
- There is now an error because project is now required and you cannot save the current task

This problem is caused by `addFieldDependencies` from `relational_model/utils` Let's simplify the case with this view for example:

```xml
<form>
    <field name="foo" widget="my_widget"/>
    <field name="name" />
    <field name="child_ids">
        <list editable="top">
            <field name="foo" widget="my_widget"/>
            <field name="name" required="1"/>
        </list>
    </field>
</form>
```
my_widget is defined with these fieldDependencies:
```js
[
    {
        name: "name",
        type: "char",
    }
]
```
We have twice the same group of fields (name + foo with my_widget), one in the form view and the other one in the subview list (child_ids).

Currently, we firstly process subviews in `addFieldDependencies`. As "name" field is used in dependencies of `my_widget` and name is already use in the same view (subview list) with required="1" we will change `my_widget` dependencies to be required too by mutating `widget.fieldDependencies`.

And after, we will do the same with the main form view, but as fieldDependencies object from fieldInfo is the same for every instances of the widget everywhere (from form arch parser), we should not alter it because we might accidentally add attributes to certain fields (for example, in our case, making the “name” field in the main view required when it shouldn't be).

This commit fix this case by using a spread operator to shallow copy fieldDependencies items.

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

Forward-Port-Of: odoo/odoo#258654

**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").

**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears

**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.

**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.

**Cause of the issue:**
  The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
  https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.

**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.

opw-5398620

Forward-Port-Of: odoo/odoo#251619
Forward-Port-Of: odoo/odoo#247170

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

[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

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

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

### Issue before this commit:
A manager without the Time Off Officer access rights was unable to approve, validate, or refuse a leave request from the Time Off Gantt. Attempting to perform these actions raised an access error on the leave_id field of the hr.leave.report.calendar model.

### Steps to reproduce the issue:
1. In employee app create a manager, go to settings tab and create also a user for the manager as Related User
2. Create also an employee setting in the Work Information tab the manager as Time Off
3. Go to Users and for the manager deselect rights for Time Off and Payroll
4. Set a contract for the created employee and allocate some Paid days to him
5. Create a Time Off request for the employee.
6. Switch to manager account
7. Go to Time Off -> Overview -> Gantt View and try to approve the request.
8. Error: _You do not have enough rights to access the fields "leave_id" on Time Off Calendar (hr.leave.report.calendar). Please contact your system administrator._

### Cause of the issue:
The action_approve, action_validate, and action_refuse methods on the hr.leave.report.calendar model relied on accessing the leave_id field, which is restricted to users belonging to the
hr_holidays.group_hr_holidays_user group. As a result, managers without this group could not read the field, triggering an AccessError even though they were legitimately allowed to approve leaves as managers. Backporting this PR: https://github.com/odoo/odoo/pull/207675

### Reason to introduce the fix:
Allow managers to perform leave approval, validation, and refusal actions without granting them broader Time Off access rights.
This fix extends the permission logic to ensure that the employee’s designated leave manager can execute these actions when the validation type allows it, while preserving the standard access restrictions for other users.

opw-6023628

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

Forward-Port-Of: odoo/odoo#257211

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

When sending an invoice by email template, the generated PDF attachment does not use the configured Printed Report Name. Instead, it falls back to a default naming pattern (e.g. report action name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send wizard. In the invoice flow,
_get_placeholder_mail_template_dynamic_attachments_data uses the invoice report context instead of the actual dynamic report.

To fix this, the send flow is updated so
_get_placeholder_mail_template_dynamic_attachments_data computes the filename from extra_mail_template.

Additionally, _get_invoice_report_filename needs to be extended in 17.0 to optionally accept a report and use its print_report_name like in the newer versions while preserving fallback behavior. 

The safe_eval is taken from code used in the future version's code, and is needed as the field accepts python expressions.

This naming issue occurs from 17.0 to current master, and the fix will ensure extra dynamic reports follow their configured printed name. 

Steps to reproduce:
Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). Go to Settings > Technical > Email > Templates and open “Invoice: Send my email”. Add the duplicated report under Dynamic Reports.
Create a customer invoice and confirm it.
Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716