Currently, an error occurs when user sets the resource on a resource leave.

**Steps to Reproduce:**

 - Install `hr_contract` with demo data.
 - Go to `Resource Time Off`.
 - Create a new record and remove the `start date` value.
 - Select the `Anita Oliver` resource `(employee record with running contract)`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause:**
This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error.

Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract.

**Fix:**
This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly.

[1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17

[2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29

**No Task ID**


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

Forward-Port-Of: odoo/odoo#244372
Forward-Port-Of: odoo/odoo#241638

The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under 
`Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`.

**Steps to reproduce:**
- Install `sale_pdf_quote_builder` module.
- Run `test_wrong_pdf` (Make sure `PyPDF==5.4.0` is installed).
- Observe `PyPDF` warnings in the logs.

**Warnings:**
```
WARNING	server	pypdf._reader:435 invalid pdf header: b'test' 
WARNING	server	pypdf._reader:435 EOF marker not found 
WARNING	server	pypdf._reader:435 EOF marker not found
```

**Root cause:**
Odoo officially supports the PyPDF version defined in requirements.txt [1]. 
The test passes with `PyPDF2`, but `PyPDF` is stricter and emits warnings when 
parsing arbitrary byte content. Because the test uses raw bytes instead of a 
structurally valid (but unsupported or encrypted) PDF, PyPDF logs warnings.

**Fix:**
This commit updates the test to use a real encrypted PDF instead of raw bytes, similar to [2].

This commit fixes test failures caused by [3].

**Note:**
Refer to [4] for generating the encrypted file.

[1]:
https://github.com/odoo/odoo/blob/a6af7df429f9cd3bfb60347e9b30cc48fb5bfaff/requirements.txt#L63-L65

[2]:
https://github.com/odoo/odoo/blob/0499dbd8944b4002883afab5d3ed76d8e55dab9c/addons/mail/tests/discuss/test_discuss_attachment_controller.py#L63-L75

[3]:
https://github.com/odoo/odoo/pull/230712

[4]:
https://colab.research.google.com/drive/1UfWSKDluObEkKxCg6eX-nHoe04_FGrEq#scrollTo=A5hO11Eh1qvV

runbot-238399

Forward-Port-Of: odoo/odoo#246034

Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing.

This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets.

Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?).

To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered.

Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget

opw-5491343

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#244538

In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location

Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})

Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119

opw-5268989

Forward-Port-Of: odoo/enterprise#102902

**Steps to produce:**
- Install `sale_management` module.
- `Create a SO > Click on Preview > Sign and Pay`.
- Remove all text from the Full Name`.

**Issue:**
- The `Accept & Sign` button remains enabled even when the Full Name field is empty.

**Root cause:**
- At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided
- Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled.

**Solution:**
- If the cleaned name is empty or contains only spaces, do not generate image.
- Instead, immediately clear the signature pad so the button remains disabled.

[1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109

**Before:**
<img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" />

**After:**
<img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" />


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

Forward-Port-Of: odoo/odoo#238638

When adding a product with never variant, their name and values are not translated in the language of the partner.

### Steps to reproduce:

* Activate the setting Variants and Variant Grid Entry.
* Create a product , add a translation for its name.
* Create a attribute  and a translation for its name, with variant creation set to never.
* Create values for the attribute and add translation for their name.
* Add the attribute and it's values to the product .
* Create a contact and change it's language to the language of the translation.
* Create a purchase order set the contact as the vendor
* Add the product, and set the grid number to 1
-> the attribute and attribute value is not translated.

### Observation:

When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288
But in case of never attribute, the name it retrieved after and we don't set the context:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174
-> we retrieve the information but in the wrong language

opw-5396058

Forward-Port-Of: odoo/odoo#242692

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a MTO product with a vendor
- Create a final product
- Create a MO for final product
- Confirm MO
- Open catalog
- Add 0.5 of the MTO product
- Open the linked purchase

> Quantity on the PO is 1

Cause
-----
The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement).

Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves.

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497

In our case, all of the conditions are met:
- the quantity update is negative
- the move is MTO
- `move_orig_ids` is empty, so the `all()` is also true

This means the move gets skipped for procurement, although that was not the goal of the commit.

Even if we were to fix this last condition, there is also a problem with

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507

that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0.

This again does not match the goal of the original commit.

-----
Ticket:
opw-5440296

Forward-Port-Of: odoo/odoo#245865

### Issue:
Stripe payment is failing in some special currencies (e.g. ISK, UGX).

### Steps to reproduce:
1- Configure Stripe
2- Enable ISK currency
3- Create a SO with ISK currency and generate a payment.
4- Pay using Stripe.

The payment will fail due to the amount mismatch.

### Cause:
Commit https://github.com/odoo/odoo/commit/9493475273a40320228b92940be15ad8cb0643cb added support for special currency but did not adapt amount validation method in fw.

In stripe payload, we are using `const.CURRENCY_DECIMALS` as `arbitrary_decimal_number` to convert the amount to minor currency unit:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L161-L166

However, we are not using the same constant in conversion back to major currency unit in `compare_notification_data`:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L393-L395

opw-5871420

Forward-Port-Of: odoo/odoo#245911
Forward-Port-Of: odoo/odoo#245689

**Behavior:**
Behavior:
When logged in as a user with group_user access (member), trying to generate the next few serial numbers for a tracked product from receipts will cause an access error.

This happens because there is a write operation on the ir.sequence linked to the serial number at the end of the process that happens only when the 'New' button was previously pressed.
And since access rights to ir.sequence are dependant on the base group of the user, changing the user Inventory rights to admin will not resolve the issue.

A test has been created to ensure no access error is created when generating sequence numbers as a lower access user, this test would pass without the fix since it is focused on the python function.

**Steps to reproduce:**
- Create a product that is tracked by serial number
- Log in as a user with group_user access (member role)
- Go to Inventory -> Operations -> Receipts
- Create a new picking and add the product
- After clicking on Mark as Todo you'll see Details pop up in the product line
- After clicking Details, select Generate Serial/Lots
- Click New, then Generate, and you'll get an access error for ir.Sequence

opw-5368553

Forward-Port-Of: odoo/odoo#240368

*= co, ec, kr, tw, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105262

The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under 
`Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`.

**Steps to reproduce:**
- Install `sale_pdf_quote_builder` module.
- Run `test_wrong_pdf` (Make sure `PyPDF==5.4.0` is installed).
- Observe `PyPDF` warnings in the logs.

**Warnings:**
```
WARNING	server	pypdf._reader:435 invalid pdf header: b'test' 
WARNING	server	pypdf._reader:435 EOF marker not found 
WARNING	server	pypdf._reader:435 EOF marker not found
```

**Root cause:**
Odoo officially supports the PyPDF version defined in requirements.txt [1]. 
The test passes with `PyPDF2`, but `PyPDF` is stricter and emits warnings when 
parsing arbitrary byte content. Because the test uses raw bytes instead of a 
structurally valid (but unsupported or encrypted) PDF, PyPDF logs warnings.

**Fix:**
This commit updates the test to use a real encrypted PDF instead of raw bytes, similar to [2].

This commit fixes test failures caused by [3].

**Note:**
Refer to [4] for generating the encrypted file.

[1]:
https://github.com/odoo/odoo/blob/a6af7df429f9cd3bfb60347e9b30cc48fb5bfaff/requirements.txt#L63-L65

[2]:
https://github.com/odoo/odoo/blob/0499dbd8944b4002883afab5d3ed76d8e55dab9c/addons/mail/tests/discuss/test_discuss_attachment_controller.py#L63-L75

[3]:
https://github.com/odoo/odoo/pull/230712

[4]:
https://colab.research.google.com/drive/1UfWSKDluObEkKxCg6eX-nHoe04_FGrEq#scrollTo=A5hO11Eh1qvV

runbot-238399

Forward-Port-Of: odoo/odoo#246034

Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing.

This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets.

Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?).

To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered.

Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget

opw-5491343

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#244538

In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and [_get_additionnal_combination_info](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_template.py#L490), the target_currency is passed but it is unused parameter.

The product_pricelist price computation logic relies on the [currency](https://github.com/odoo/odoo/blob/saas-18.2/addons/product/models/product_pricelist.py#L162)  and target_currency is not used anywhere in the pricing flow. As a result, passing target_currency adds confusion without affecting the outcome.

The target_currency parameter was unused in the method call flow and, due to this, it was always being passed as NULL. This made the parameter ineffective and confusing, while the actual logic expects a valid currency value.

This commit replaces target_currency with currency to avoid unused / misleading parameter.

Traceback
```py
2026-01-22 12:50:48,564 48232 ERROR currency_19 odoo.addons.website_sale.tests.test_website_sale_product_template: ERROR: TestWebsiteSaleProductTemplate.test_markup_data_uses_taxes_included_price_when_configured_on_website
Traceback (most recent call last):
  File "/home/odoo/odoo/odoo/addons/website_sale/tests/test_website_sale_product_template.py", line 81, in test_markup_data_uses_taxes_included_price_when_configured_on_website
    markup_data = self.product._to_markup_data(self.website)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/odoo/addons/website_sale/models/product_product.py", line 162, in _to_markup_data
    product_price = request.pricelist._get_product_price(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 121, in _get_product_price
    return self._compute_price_rule(product, *args, **kwargs)[product.id][0]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 220, in _compute_price_rule
    price = suitable_rule._compute_price(
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ProductPricelistItem._compute_price() got an unexpected keyword argument 'target_currency'
 
```
Before fix, 
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = None
uom = None
date = False
compute_price = True
kwargs = {'target_currency': res.currency(20,)}

> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
(Pdb) 
```
After fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = res.currency(20,)
uom = None
date = False
compute_price = True
kwargs = {}

> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
res.currency(20,)
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
```

- opw - [5447980](https://www.odoo.com/odoo/project/70/tasks/5447980)
- upg - [3782135](https://upgrade.odoo.com/odoo/upgrade.request/3782135)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#242998

**Steps to produce:**
- Install `sale_management` module.
- `Create a SO > Click on Preview > Sign and Pay`.
- Remove all text from the Full Name`.

**Issue:**
- The `Accept & Sign` button remains enabled even when the Full Name field is empty.

**Root cause:**
- At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided
- Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled.

**Solution:**
- If the cleaned name is empty or contains only spaces, do not generate image.
- Instead, immediately clear the signature pad so the button remains disabled.

[1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109

**Before:**
<img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" />

**After:**
<img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" />


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

Forward-Port-Of: odoo/odoo#238638

The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`.

Before this commit:
- functionally: The obvious matching was denied and the accountant had to manually make the match.

- technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word.

After this commit:
- functionally: The obvious match is made.

- technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

When adding a product with never variant, their name and values are not translated in the language of the partner.

### Steps to reproduce:

* Activate the setting Variants and Variant Grid Entry.
* Create a product , add a translation for its name.
* Create a attribute  and a translation for its name, with variant creation set to never.
* Create values for the attribute and add translation for their name.
* Add the attribute and it's values to the product .
* Create a contact and change it's language to the language of the translation.
* Create a purchase order set the contact as the vendor
* Add the product, and set the grid number to 1
-> the attribute and attribute value is not translated.

### Observation:

When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288
But in case of never attribute, the name it retrieved after and we don't set the context:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174
-> we retrieve the information but in the wrong language

opw-5396058

Forward-Port-Of: odoo/odoo#242692

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a MTO product with a vendor
- Create a final product
- Create a MO for final product
- Confirm MO
- Open catalog
- Add 0.5 of the MTO product
- Open the linked purchase

> Quantity on the PO is 1

Cause
-----
The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement).

Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves.

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497

In our case, all of the conditions are met:
- the quantity update is negative
- the move is MTO
- `move_orig_ids` is empty, so the `all()` is also true

This means the move gets skipped for procurement, although that was not the goal of the commit.

Even if we were to fix this last condition, there is also a problem with

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507

that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0.

This again does not match the goal of the original commit.

-----
Ticket:
opw-5440296

Forward-Port-Of: odoo/odoo#245865

Issue:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

This PR replaces #240808 

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#244428

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#102714

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records (Just for safety).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.
- Removed the form view.
- Added the field `active` to the list view and made it editable.

PR for stable(18.0): https://github.com/odoo/enterprise/pull/103944

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location

Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})

Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119

opw-5268989

Forward-Port-Of: odoo/enterprise#102902

*= co, ec, kr, us, tw, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105262

Currently, an error occurs when a user creates a 'Model Page', which is referring to a non-stored model and trying to access it through website view.

Steps to Reproduce:
- Install stock, website and web_studio modules.
- Open Inventory and turn on studio mode.
- Navigate to model pages.
- Create a new model page with the exposed model as 'Stock Quantity Report'.
- Save and click on the Website smart button and you will get the error.

Error:
`ValueError: Invalid field 'create_date' on model 'report.stock.quantity'`

Root Cause:
Odoo Studio allows creating website pages for any model, including non-stored models (`_auto = False`) such as `report.stock.quantity`. When a user creates a `Model Page` with such a model, Odoo attempts to fetch records from the database and sort them by `create_date` as shown at [1]. Since these models do not have a database table, the `create_date` field does not exist, causing the error.

Fix:
Exclude non-stored models from the model selection for Model Pages.

[1]: https://github.com/odoo/odoo/blob/ce2d134d3e8e5c0d96529c1d0490f1e0c5e28294/addons/website/controllers/model_page.py#L77

Related Community PR: https://github.com/odoo/odoo/pull/226774

sentry-6842596566

Registering for an event while the mail scheduler cron was running could lead to a PostgreSQL serialization failure, leading to a 500 error and the failure of the registration.

### Reproduction Steps

1. Configure an Event with a "Mail Scheduler" set to trigger "After each registration" with an interval of "Immediately".
2. Ensure the "Event: Mail Scheduler" cron job is active and running.
3. As a public user or portal user, attempting to register for this event will intermittently fail with an HTTP 500 error.
4. The server logs will show `psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update`, followed by `psycopg2.errors.InFailedSqlTransaction`.
5. The registration is not created.

### Cause

When a user registers for an event, the system immediately attempts to process any "on-registration" emails. The method used (`_execute_attendee_based`) forces a database `commit()`.

When this `commit()` is executed, the Postgres database attempts to finalize the user's transaction. However, if the concurrent background cron job has modified the same event/mail records while the user's request was processing, Postgres detects a serialization conflict.

Consequently, the commit itself fails and raises `SerializationFailure`. Because the commit failed, the user's transaction is rolled back, and the registration record is never persisted to the database (explaining the missing attendees).

Critically, the exception handling logic in `_update_mail_schedulers` catches this `SerializationFailure` (preventing odoo from retrying the transaction) but then attempts to perform further database operations (to log the error). Since the transaction is already in an aborted state due to the failed commit, this triggers a secondary `InFailedSqlTransaction` error. This secondary error is not recognized as a concurrency error by Odoo's automatic retry mechanism (`odoo.service.model.retrying`), resulting in a hard crash instead of a retry.

### Fix

The logic now checks the execution context using `event_mail_registration_ids`. If triggered by a user registration (indicated by the presence of specific registration IDs in the context), the explicit `commit()` is skipped.

opw-5355116

Description of the issue/feature this PR addresses:
Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts.

Current behavior before PR:
- Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock).
- Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user.
- No validation is enforced, leading to potential security issues.

Desired behavior after PR is merged:
- Adding a subscription for a non-existent or unavailable product raises a ValidationError.
- Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first.
- Backend validation prevents misuse of registered user emails and improves security.




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

**Behaviour:**
When accessing the Planning by Production/Workcenter views from the menu, a server action checks if the work order dependencies setting is enabled, and if yes, it will change the ref of the default gantt view to another view which handles dependencies. However, when reloading the page, the server action is not accessed anymore which will result in the default view being loaded and the dependencies not being represented.

This behaviour is fixed starting from 18.2 with this commit ( https://github.com/odoo/odoo/commit/b663a6e3dbda6eda84e4a6b051acfc8511476cd3 ) that ensures that if a page is reloaded the current action's state is restored as it was.

Applying this commit to previous versions would not comply with stable policy, the current solution is to override the get_views method to make sure the presence of the setting is checked and the correct view is applied whenever that page is loaded.

**Steps to reproduce:**
- Check Work Orders->Work Order Dependencies in the Manufacturing settings
- Create a Product
- Create a Bill of materials with two components
- Check Operation Dependencies in the Miscellaneous tab
- Create two operations, and make one of them blocked by the other
- Create a Manufacturing order for the product then click confirm then Plan
- In the Planning dropdown menu, select Planning by Production (workcenter works aswell)
- You will see the two operations with an arrow linking them.
- Refresh the page
- The arrow will have disapeared

opw-5477803

## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).

## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
    - *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
    - *Wages and salaries*: **649 is not mentioned**
    - *Social security charges*: **649 is not mentioned**

## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.

opw-5724559